Over 500 years after its invention, movable type printing is about to be reinvented. The big problem is that the clarity of vision that surrounded Gutenberg's work appears at times to be diluted to the point of endangering the endeavor.
When the printing press was invented back 1539, the objective was clear and simple : make it possible to print multiple copies of printed material inexpensively and relatively fast. Done and done!
Since then al we have had to do is redefine inexpensive and fast : paper has gotten cheaper and printing technologies have gotten more and more sophisticated.
The technology that has come to be know as ePaper should, at least initially, have the simple objective of replacing its predecessor. An electronic book that is indistinguishable from a conventional book in ease of reading, portability and energy requirements should be objective number one. Unfortunately, many of the companies involved in developing the technology appear to be getting sidetracked. I think I know why.
As comedian Bill Cosby used to say, you are going to appreciate this work I am doing for you. I think objective number one in every effort is to know one's primary audience. I know, I know, sometimes a secondary audience overtakes the primary one; however, the overtaking always occurs in the context of targeting the primary audience anyway.
Some time ago I had an argument with a friend who could not fathom my enthusiasm about recent developments in electronic paper technology (slowly getting better and cheaper). He felt that it was a useless effort and could not see himself buying any device that used such a technology. Now, this friend of mine is no Luddite; he is an avid technology buyer and is usually excited about the latest offerings to come out of CES or Silicon Valley.
So why was he indifferent -- to the point of derision-- to the prospect of eight-ounce books that could store a whole bookshelf's worth of literature? Because, he belongs to the group that I have come to call "The Watchers". The other group I call "The Readers". Ebook or ePaper technologies are not for "The Watchers", they are for "The Readers." Why?
Watchers are people who, for one reason or another, never learned the joy of reading. They read very well, but they do not relish the practice; they see it as work or a poor substitute for whatever the reading material describes. These are people who rarely if ever read during a vacation. They are the ones usually watching movies on their iPods on the train or while waiting for it, and will prefer a bad movie adaptation over the drudgery of actually reading the book. Watchers complain about the number of pages in a book and see graduation from college as the end of the need to read anything cover-to-cover.
Readers, on the other hand. Use their iPods mostly for listening to music while reading a book, magazine or newspaper on the train. Readers buy and collect books. Reader's judge movie adaptations by how faithfully they adhere to the spirit of the book. Readers use vacation time as an opportunity to catch up on their reading. Readers are the people you want to target with any electronic paper or book technology because they will value it if it is as user-friendly as what it is trying to replace.
I don't think I need to mention at this point that I consider myself a reader. I look for an eBook to be as easy on my eyes and my hands as a book. Many so-called eBook readers are just stripped-down tablet PCs. Book-lovers do not really want that. Readers want something you can cuddly up with (as you would with your favorite book) but capable of holding hundreds or thousand of books.
The ideal eBook will either be powered by light (i.e. solar) or will have a an unobtrusive battery that lasts for many years. As a member of the reader class, I want my ePaper to get right everything that actual paper has gotten right. I also want ePaper to be comparably priced. We would not expect an eReader to be priced like a hardcover book, but neither do we want it to be so major a purchase that it would be unattractive to the average buyer. For example, it is ridiculous to compare the price of an eBook reader with that of a hard-bound encyclopedia because no family ever bough a separate set for each child and most single people traditionally rely on libraries or the Internet.
I think a good price point for eBook readers should be that of cell phones -- currently starting at $50 in the absence of a promotion. This initial price should include at least 4 titles chosen by the buyer with subsequent titles sold for less that their paperback editions ($5-up sounds fair to me). We are still several months (or years) away from this, but I think it is important to state the kind of objective to shoot for.
Once that first goal is achieved, then other so-called enhancements can be added. This is what makes the development of the iPod so admirable. The iPod's first goal was to replace the portable CD Player. Once this was achieved, then came video and games, wi-fi and even an attached cell phone.
In the same way, a good development path for ePaper or eBook readers should be:
First, the triumvirate of look and feel, cost, and long battery life -- with search (in lieu of an index) and bookmarking (in lieu of dog-earing) thrown in for good measure.
Second, wi-fi and/or blue tooth would be a great first addition, especially for the sake of periodicals.
Third, color and high resolution photography would really sell the new technology to art lovers and the books-with-pictures crowd.
Fourth, animation and maybe sound should be the last thing on the list and should not be implemented sparsely. In other words, it should not be another movie player; people who want portable movie players (a.k.a. Watchers) already have plenty of choices out there. Ebook/ePaper makers need to take care of their base first.
I know, I know, I have not mentioned existing products that already feature some of the characteristics I've listed. This has been on purpose.
The two most popular products out there, the Sony eBook reader (and its clones) and Amazon's Kindle are, in my opinion, modified tablet PCs or PDAs -- choose your epithet. I think it's good that they exist, but I see them as transitory devices that appeal to gadget lovers. For ePaper or eBook readers to be successful they must appeal to actual book lovers. These devices are to the new technology what the Pony Express was to the telephone -- appetite whetters.
The reality is that, even an IT person like myself (and even more so a regular civilian) would want an eBook reader that behaves more like a traditional book or magazine than like another laptop.
Plastic Logic is working on a product that is starting to look like the future of books. For one it looks more like a legal pad than a tablet PC and promises a more paper-like experience. It is still not flexible or foldable (two nice-to-have features) but I would have not trouble tucking it into the side pocket of my bag or briefcase next to the latest issue of The Economist (or, rather, in it's place).
So, my call to all current and future eBook/ePaper industry players is that they cater to their base. Make your products appeal to people who read, not gamers or movie fans. There are enough of us to give you the push you need. There will always be a place for printed matter; make sure you put down your stakes in just such a place.
Wednesday, January 7, 2009
Tuesday, January 6, 2009
A Different Tune
A couple months ago, I slammed Comcast for their dishonest ads. I don't know whether one of their attorneys read my post, but the last Comcast I listened to on the radio used the word "web" in connection with their suggestion of "unlimited access."
While I still don't recommend Comcast for anything (their digital channels are as bad as the technology will allow; and their Internet access is the worst around) I must commend them for at least adding that CYA to their ads. Now, if after hearing one of their recent radio commercials, still insist on using Comcast for your Internet access, you have only yourself to blame if your VPN or FTP or BitTorrent connections don't work as expected.
While I still don't recommend Comcast for anything (their digital channels are as bad as the technology will allow; and their Internet access is the worst around) I must commend them for at least adding that CYA to their ads. Now, if after hearing one of their recent radio commercials, still insist on using Comcast for your Internet access, you have only yourself to blame if your VPN or FTP or BitTorrent connections don't work as expected.
Thursday, December 25, 2008
Connecting to Server WhatsItsName
This being the holiday season and most of you doing your hardest not to think of work -- unless you are on call in which case nothing I write here can top whatever the pager on your hip says— I will deal with a relatively light topic but still one of relevance: server names.
In the early days of the Internet —say, in the late 80s and early 90s— when most servers were located on university campuses they were usually named after cartoon characters such as Snoopy.
Larger businesses preferred geographic names and used them in conjunction with departmental naming. Thus a server that was primarily used by accounting in Denver would be named something like denver_accounting; if they got a second server it would be named denver_accounting2 and so on.
These schemes appeared to work for a while, but increases in the number of physical servers combined with the surge in virtualization —not to mention the rise of mixed use servers or cross-department applications — has all but exhausted current naming schemes.
The best proof of this are the bizarre names popping up in current IT server farms. For example, some administrators just use the default name suggested by the OS on install. This results in names that are meaningless and difficult to remember such as GHXF13M or some such.
There are many articles out there that give all kinds of reasons why a server's name should reflect purpose. However, given the rate of change in modern organizations this would mean changing names for servers fairly often which would add to the network administrators list of tasks unnecessarily. The only time such a naming convention makes sense would be if the server in question is virtual and it has a specialized use. Servers that have mixed use are better off having memorable names that fit within a scalable scheme.
Another thing to remember is that, given the litigiousness of our society the the naming scheme needs to be neutral enough to not offend most people. An online article I read, described how administrators at a certain company would name their new servers based on how they felt after about the food served on a given day at their company cafeteria; so they ended up with names like "Squishy". Apart from the limited scalability of such a scheme, the potential for litigation is big enough to make it unsuitable.
So far we have fleshed out 3 principles for creating a server naming convention:
(1) User-friendliness or memorable names
(2) Scalability or a long enough list
(3) Reasonably non-offensive or prone to litigation
What remains now is to examine how we can implement each in practical terms.
1. User-friendly names
The most common non-human names we use on a daily basis are street names. The most easily remembered yet common street names correspond to names of individuals or places. The Washington, DC, is famous for using names of states on many of their streets. Names of insects might also fly, pun intended, except perhaps for some of the more queasiness-inducing ones.
2. Scalability
The main problem with rule number two is that it is in direct conflict with rule number 1. Obviously, the use of US state and territory names is not a good idea because there are less than 100. County names might be a good idea since they number over 3,000. However, no matter how big the name set used, it will have a finite limit and there ought to be a plan B for when the first set is exhausted. You should probably have on hand at least three sets of names to be used in turn as the preceding one becomes exhausted.
3. Reasonably non-offensive
Before I identify sources of names, I would like to suggest that such sources be documented for two reasons :
(a) as guide to your successors
(b) as a counter-argument to anyone who might deem a name as offensive
Now, lets turn to the sources of name sets. The US Census bureau has some wonderful data files that one can download from their web site and use free of charge or legal constraint . I especially recommend the Gazetteer section. A quick glance shows the following data sets with perfectly extractable names:
Counties (3,141 records)
MCDs [Minor Civil Divisions] (36,289 records)
Places (23,789 records)
Zips (29,470 records)
Online phone books are useful as long as you only use last names, and so are baby name sites, although I would recommend staying away from the more common ones. Even sites not usually associated with lists, such as Wikipedia, can be sources of lists that are long enough and have names that are easy enough to remember.
Now with all these names to administer you are going to need a good database to make sure there are no mixups. LDAP and/or Active Directory or whatever equivalent you have at your firm are good for basic management and search. However, for better navigability and even to store unassigned names for easy accessibility and quick implementation, an external database with an easy to use web interface would be best. Ideally the server management software should keep both databases (LDAP/AD an the server list database) synchronized and allow for search based on any combination of criteria.
In the end this should make the management of your server farms easier at a time when server proliferation is such that a company need not be named Google to list thousands of servers in its farm or farms.
I would go on to speak of workstation names, but they are of less concern. Besides, there is software out there that can do that almost automatically (such as the Windows 2000 Remote Installation Service). However, if you still need ideas for workstation names I would point you to the baby names sites for an easy source.
but trends that I have noticed suggest to me that we need a more comprehensive and scalable naming conventions than have previously been used
Some of the larger corporations have a way of
In the early days of the Internet —say, in the late 80s and early 90s— when most servers were located on university campuses they were usually named after cartoon characters such as Snoopy.
Larger businesses preferred geographic names and used them in conjunction with departmental naming. Thus a server that was primarily used by accounting in Denver would be named something like denver_accounting; if they got a second server it would be named denver_accounting2 and so on.
These schemes appeared to work for a while, but increases in the number of physical servers combined with the surge in virtualization —not to mention the rise of mixed use servers or cross-department applications — has all but exhausted current naming schemes.
The best proof of this are the bizarre names popping up in current IT server farms. For example, some administrators just use the default name suggested by the OS on install. This results in names that are meaningless and difficult to remember such as GHXF13M or some such.
There are many articles out there that give all kinds of reasons why a server's name should reflect purpose. However, given the rate of change in modern organizations this would mean changing names for servers fairly often which would add to the network administrators list of tasks unnecessarily. The only time such a naming convention makes sense would be if the server in question is virtual and it has a specialized use. Servers that have mixed use are better off having memorable names that fit within a scalable scheme.
Another thing to remember is that, given the litigiousness of our society the the naming scheme needs to be neutral enough to not offend most people. An online article I read, described how administrators at a certain company would name their new servers based on how they felt after about the food served on a given day at their company cafeteria; so they ended up with names like "Squishy". Apart from the limited scalability of such a scheme, the potential for litigation is big enough to make it unsuitable.
So far we have fleshed out 3 principles for creating a server naming convention:
(1) User-friendliness or memorable names
(2) Scalability or a long enough list
(3) Reasonably non-offensive or prone to litigation
What remains now is to examine how we can implement each in practical terms.
1. User-friendly names
The most common non-human names we use on a daily basis are street names. The most easily remembered yet common street names correspond to names of individuals or places. The Washington, DC, is famous for using names of states on many of their streets. Names of insects might also fly, pun intended, except perhaps for some of the more queasiness-inducing ones.
2. Scalability
The main problem with rule number two is that it is in direct conflict with rule number 1. Obviously, the use of US state and territory names is not a good idea because there are less than 100. County names might be a good idea since they number over 3,000. However, no matter how big the name set used, it will have a finite limit and there ought to be a plan B for when the first set is exhausted. You should probably have on hand at least three sets of names to be used in turn as the preceding one becomes exhausted.
3. Reasonably non-offensive
Before I identify sources of names, I would like to suggest that such sources be documented for two reasons :
(a) as guide to your successors
(b) as a counter-argument to anyone who might deem a name as offensive
Now, lets turn to the sources of name sets. The US Census bureau has some wonderful data files that one can download from their web site and use free of charge or legal constraint . I especially recommend the Gazetteer section. A quick glance shows the following data sets with perfectly extractable names:
Counties (3,141 records)
MCDs [Minor Civil Divisions] (36,289 records)
Places (23,789 records)
Zips (29,470 records)
Online phone books are useful as long as you only use last names, and so are baby name sites, although I would recommend staying away from the more common ones. Even sites not usually associated with lists, such as Wikipedia, can be sources of lists that are long enough and have names that are easy enough to remember.
Now with all these names to administer you are going to need a good database to make sure there are no mixups. LDAP and/or Active Directory or whatever equivalent you have at your firm are good for basic management and search. However, for better navigability and even to store unassigned names for easy accessibility and quick implementation, an external database with an easy to use web interface would be best. Ideally the server management software should keep both databases (LDAP/AD an the server list database) synchronized and allow for search based on any combination of criteria.
In the end this should make the management of your server farms easier at a time when server proliferation is such that a company need not be named Google to list thousands of servers in its farm or farms.
I would go on to speak of workstation names, but they are of less concern. Besides, there is software out there that can do that almost automatically (such as the Windows 2000 Remote Installation Service). However, if you still need ideas for workstation names I would point you to the baby names sites for an easy source.
but trends that I have noticed suggest to me that we need a more comprehensive and scalable naming conventions than have previously been used
Some of the larger corporations have a way of
Monday, December 8, 2008
Patterns and Other Buzzwords
Recently I was reading another blog post by way of Slashdot about MVC which reminded me of a pet peeve I think is worth bringing up.
Let me begin by saying that architectural patterns like MVC or software design patterns like Singleton are a wonderful way to encapsulate high or mid-level software structures for easy re-use or combination.
Like plays in an NFL team's playbook, they provide the software developer with prepackaged strategies or tools to tackle a particular problem. Therefore I can only recommend that developers learn all they can about as many patterns as they can and stretch their brains figuring out under what conditions each could best be utilized.
What is sickening, if not disheartening, is to see such great concepts reduced to buzzwords. Too many developers plan their projects with merely the buzzwords in mind — damned be reliability, adequacy, security, scalability or the customer/user's needs. Its all about saying that they got to use the Facade pattern combined with the Abstract Factory along with the Observer, the Visitor and the Active Object patterns and ... oh, it was all very MVC.
This is putting the cart ahead of the horse. The right way to do it is to begin by assessing what needs to be done and then choosing the right tools for the job.
In the same way that we are careful about hardware provisioning and platform, IDE, and language choice, we should plan our choice or patterns to match the desired result. This might mean that mid-project we may have to dump some patterns chosen earlier and enlist others. It may mean that we may have to increase the complexity of the project or simplify it —usually the latter. The point is the finished product should be the focus of all our efforts. The cult of buzzwords can only hurt the quality of our work.
And before I go, I should remind everyone that no amount of buzzwords can replace well-written code and proper documentation. These two cannot be emphasized enough. Many developers enjoy indulging in obfuscation without realizing that they are making it easier for the next guy to blame them even for new bugs introduced into their murky code.
So, do yourself a favor, forget the buzzwords. Choose the patterns that suit your project or invent your own if there is none that can fit — hard to imagine but the existing patterns had to be invented at some point. Refactor as much as you can — think of refactoring as preemptive debugging (if often is). Document as much as you can, either through a tool or by means of helpful comments in code; often an older you will be your most avid reader.
And finally, learn as much as you can about design patterns, especially their strengths and weaknesses. Patterns are very powerful if used judiciously, but disastrous when used carelessly. Now go change the world with your code.
Let me begin by saying that architectural patterns like MVC or software design patterns like Singleton are a wonderful way to encapsulate high or mid-level software structures for easy re-use or combination.
Like plays in an NFL team's playbook, they provide the software developer with prepackaged strategies or tools to tackle a particular problem. Therefore I can only recommend that developers learn all they can about as many patterns as they can and stretch their brains figuring out under what conditions each could best be utilized.
What is sickening, if not disheartening, is to see such great concepts reduced to buzzwords. Too many developers plan their projects with merely the buzzwords in mind — damned be reliability, adequacy, security, scalability or the customer/user's needs. Its all about saying that they got to use the Facade pattern combined with the Abstract Factory along with the Observer, the Visitor and the Active Object patterns and ... oh, it was all very MVC.
This is putting the cart ahead of the horse. The right way to do it is to begin by assessing what needs to be done and then choosing the right tools for the job.
In the same way that we are careful about hardware provisioning and platform, IDE, and language choice, we should plan our choice or patterns to match the desired result. This might mean that mid-project we may have to dump some patterns chosen earlier and enlist others. It may mean that we may have to increase the complexity of the project or simplify it —usually the latter. The point is the finished product should be the focus of all our efforts. The cult of buzzwords can only hurt the quality of our work.
And before I go, I should remind everyone that no amount of buzzwords can replace well-written code and proper documentation. These two cannot be emphasized enough. Many developers enjoy indulging in obfuscation without realizing that they are making it easier for the next guy to blame them even for new bugs introduced into their murky code.
So, do yourself a favor, forget the buzzwords. Choose the patterns that suit your project or invent your own if there is none that can fit — hard to imagine but the existing patterns had to be invented at some point. Refactor as much as you can — think of refactoring as preemptive debugging (if often is). Document as much as you can, either through a tool or by means of helpful comments in code; often an older you will be your most avid reader.
And finally, learn as much as you can about design patterns, especially their strengths and weaknesses. Patterns are very powerful if used judiciously, but disastrous when used carelessly. Now go change the world with your code.
Thursday, November 20, 2008
Misleading Figures
Many a project manager is pressed to, or concerned about, measuring developer productivity and some reach for the lowest hanging fruit : lines of code. It is unbelievable he kind of things that still go on some IT shops!
This is not only an imprecise metric in encourages code bloat and other bad programming practices while discouraging mainstays of good programming such as debugging and refactoring.
Some who agree with my points above may be devotees of another less metric that is slightly less misleading: the number of builds or check-ins. While it is true that a productive developer is likely to check in and build code often, an unproductive developer can easily game this system to appear most productive.
Yet another way of measuring productivity is by means of bug report or enhancement request tickets. This is probably the most realistic method of gathering developer productivity metrics, but it can also be misleading. In some cases the incident response system is also used for billing a client. This does not necessarily translate — as tempting as it might be.
So, how do you reliably and fairly measure developer productivity? You don't. To put it a better way, you shouldn't have to. A bug tracking/change request tool is very useful but it should be used the way sports teams used game videos — to learn from past experiences and improve performance.
Hold on to that sports analogy because that is a good place to be. A development shop is a team effort and what makes a developer valuable is how much a contribution he/she makes. Although different metrics may point to the top performers, a good project manager needs to be wise enough to know the strengths and weaknesses of each team member and position him/her for maximum impact.
The productivity measured and relied on most should be that of the team. This is not to say that we should give cover to freeloaders and underperformers; these should be dealt with as soon and as severely as possible. This means that sometimes more can be achieved as we realize that software development is more like a barn raising than a marathon.
This is not only an imprecise metric in encourages code bloat and other bad programming practices while discouraging mainstays of good programming such as debugging and refactoring.
Some who agree with my points above may be devotees of another less metric that is slightly less misleading: the number of builds or check-ins. While it is true that a productive developer is likely to check in and build code often, an unproductive developer can easily game this system to appear most productive.
Yet another way of measuring productivity is by means of bug report or enhancement request tickets. This is probably the most realistic method of gathering developer productivity metrics, but it can also be misleading. In some cases the incident response system is also used for billing a client. This does not necessarily translate — as tempting as it might be.
So, how do you reliably and fairly measure developer productivity? You don't. To put it a better way, you shouldn't have to. A bug tracking/change request tool is very useful but it should be used the way sports teams used game videos — to learn from past experiences and improve performance.
Hold on to that sports analogy because that is a good place to be. A development shop is a team effort and what makes a developer valuable is how much a contribution he/she makes. Although different metrics may point to the top performers, a good project manager needs to be wise enough to know the strengths and weaknesses of each team member and position him/her for maximum impact.
The productivity measured and relied on most should be that of the team. This is not to say that we should give cover to freeloaders and underperformers; these should be dealt with as soon and as severely as possible. This means that sometimes more can be achieved as we realize that software development is more like a barn raising than a marathon.
Saturday, October 11, 2008
Embarrassing Skills
No, this is not a post about shop-lifting or any other such antisocial skill. Besides, this is a blog about technology so expect me to refer to technical skills.
Logic would dictate that any skill remotely related to programming would be a feather in the hat of developers. After all, the more a developer knows the more valuable he/she could potentially be to a project, right? Unfortunately, many who became software developers after the birth of the web have decided that certain programming related skills are so shameful they will feign or pursue ignorance of them at all costs.
This avoidance of knowledge has let to some of the most inefficient and jumbled projects ever. But, before examining what kind of jumble can result from such attitude, let's name some names.
HTML
When presented with this acronym, many a developer will state the obvious: HTML is not a programming language. Bingo! It is not, neither is Postscript or Tex. Now it is kind of ridiculous that members of the generation that grew up making joke websites is so anti-HTML that they refuse to acknowledge the very existence of what has become the fastest growing display markup language. I am not leveraging this criticism of developers whose applications live on the desktop or on embedded systems. Such developers have their own user interface issues to worry about. If you write strictly Swing, MFC, Cocoa, or X11 applications and you do not know the first thing about HTML fine.
I am speaking of developers whose applications live on the web who cannot tell whether their applications are outputting the right kind of markup. That they would consider their ignorance (real or fake) to be a virtue, makes their attitude that more egregious. A J2EE or ASP .NET developer who does not know HTML is like a C++ developer who believes he/she is above learning about #defines or compiler switches.
JavaScript
This one is a favorite language to hate for many J2EE developers. The irony of it all is that, for better or for worse, Java is the closest relative to JavaScript. It's fair to say that JavaScript is as related to (or descended from) Java as Java is to C++. Yet, I have not met any C++ developers who disavow any knowledge or use of Java. For all of its flaws and poor structure, JavaScript is not likely to be replaceable as the web's premier scripting language in the same way that SQL will remain the premier database scripting language way into the future.
XML
This one is more an issue of prejudice since many developers don't seem to understand that, for the foreseeable future, there will always be need for heterogeneous systems to communicate over networks and that binary objects sent over multiple hops are too susceptible to corruption to be reliably transported. Also, in the case of XML, most developers that hate it just don't get it; the principle of serialization is lost on them.
Language
I mean language as in Human languages. The be more specific, written human languages. The truth about our profession is that we are creating systems that interact with humans in more complex ways. These systems will need to be more user-friendly at least and, in some cases, even human-like.
If you are a developer who thinks it is cool to not know stuff, remember that you will suffer from any technology you depend on professionally that you do not understand. Knowledge, my friend, is power — and, on rare occasions, it is also job security.
If you are a lead developer or project manager and you notice any of the above attitudes among your team, nip it in the bud because such behavior will eventually hurt your projects.
Logic would dictate that any skill remotely related to programming would be a feather in the hat of developers. After all, the more a developer knows the more valuable he/she could potentially be to a project, right? Unfortunately, many who became software developers after the birth of the web have decided that certain programming related skills are so shameful they will feign or pursue ignorance of them at all costs.
This avoidance of knowledge has let to some of the most inefficient and jumbled projects ever. But, before examining what kind of jumble can result from such attitude, let's name some names.
HTML
When presented with this acronym, many a developer will state the obvious: HTML is not a programming language. Bingo! It is not, neither is Postscript or Tex. Now it is kind of ridiculous that members of the generation that grew up making joke websites is so anti-HTML that they refuse to acknowledge the very existence of what has become the fastest growing display markup language. I am not leveraging this criticism of developers whose applications live on the desktop or on embedded systems. Such developers have their own user interface issues to worry about. If you write strictly Swing, MFC, Cocoa, or X11 applications and you do not know the first thing about HTML fine.
I am speaking of developers whose applications live on the web who cannot tell whether their applications are outputting the right kind of markup. That they would consider their ignorance (real or fake) to be a virtue, makes their attitude that more egregious. A J2EE or ASP .NET developer who does not know HTML is like a C++ developer who believes he/she is above learning about #defines or compiler switches.
JavaScript
This one is a favorite language to hate for many J2EE developers. The irony of it all is that, for better or for worse, Java is the closest relative to JavaScript. It's fair to say that JavaScript is as related to (or descended from) Java as Java is to C++. Yet, I have not met any C++ developers who disavow any knowledge or use of Java. For all of its flaws and poor structure, JavaScript is not likely to be replaceable as the web's premier scripting language in the same way that SQL will remain the premier database scripting language way into the future.
XML
This one is more an issue of prejudice since many developers don't seem to understand that, for the foreseeable future, there will always be need for heterogeneous systems to communicate over networks and that binary objects sent over multiple hops are too susceptible to corruption to be reliably transported. Also, in the case of XML, most developers that hate it just don't get it; the principle of serialization is lost on them.
Language
I mean language as in Human languages. The be more specific, written human languages. The truth about our profession is that we are creating systems that interact with humans in more complex ways. These systems will need to be more user-friendly at least and, in some cases, even human-like.
If you are a developer who thinks it is cool to not know stuff, remember that you will suffer from any technology you depend on professionally that you do not understand. Knowledge, my friend, is power — and, on rare occasions, it is also job security.
If you are a lead developer or project manager and you notice any of the above attitudes among your team, nip it in the bud because such behavior will eventually hurt your projects.
Tuesday, October 7, 2008
Be Careful of "Consultants"
As I was reading an article entitled saving energy in the data center on the InfoWorld site today, I was reminded of how IT managers can be misled by the IT Press and so-called consultants. Written by Logan G. Harbaugh, and Entitled 10 IT Power-Saving Myths Debunked, this article itself introduces at least one myth of its own. I am not alone in my assessment, as many of the readers proceeded to shred the author to pieces in their feedback comments.
Here for example is a real gem. Number two says, "It takes too long to cold-start servers to react to spikes in demand. If customers are made to wait, they'll go elsewhere." The author then proceeds to make asinine suggestions such as holding a site hostage until additional servers — which you turned off on his advice — are brought online. He supposes users will sympathize with your cause and wait around until your site is good to go.
Apart from providing some belly-holding, rolling-on-the-floor laughs, this bit of advice is not only naive, but it betrays absolute ignorance as to how data center and servers work.
First of all, Mr IT journalist guy, the users will go elsewhere — even card-carrying Green Party members seeking to buy recycled products will move on and will likely never come back — this is a lesson every e-commerce site owner learns real fast if he/she is to survive.
Secondly, have you any idea how long it takes for a server to boot up and make itself available on the network? Users expect their pages to load in 5 seconds or less.
Regardless of operating system, a data center server needs a good 5 minutes to boot up — and that is on a good day. This does not include integration into a server farm or registering with the load balancer. It is utterly impractical to even suggest that you can keep part of your server farm unplugged and bring it up in time to deal with increased traffic.
But the purpose of this post is not necessarily to beat up on Mr Harbaugh — although he does deserve the beating. Instead I want to focus on all the times and circumstances in which management listens to boneheaded advice from "consultants" or IT Journalists, as our friend Logan here, and hurt their businesses.
This happens so often that it poses a real threat to IT operations. I would include sales reps in this list, but I assume any MBA holder with half a brain is smart enough to realize that sales people will always say what their targets want to hear in order to get their respective commissions.
Consultants, consulting firms and trade publications (the poor manager's consultant) , however, are expected to be on the side of the people who come to them for advice. But it has often been the case that these people fail their trusting followers miserably.
If these failures were the product of human imperfections, I would not be so upset; but they are instead caused by other factors that should not be allowed to go unchecked, Here are a few along with — and you will love me for this — ways to recognize when you are being had.
1) Agendas and/or Causes
No matter how noble and just a cause, trade publications and consultants must reserve their first allegiance to you, their client or customer. When you go to the grocery store to buy milk, you do not expect to get pamphlet on animal cruelty instead of the gallon of the white stuff are there to pick up. You can tell preachy consultants by their lengthy speeches that have nothing to do with the task at hand. As terrible as the situation in Burma is, your server farm should be the topic of conversation in a meeting called for that purpose.
2)Unholy Alliances
Regardless of how good the products in question might be, a consultants or trade publications that take the side of vendors, are no longer what they claim to be. The have become mouthpieces and salespeople.
The job of a consultant (and, hopefully a professional journal) is to review products and services and only recommend the best of breed.
One easy way to tell these salespeople in disguise is by the way they give unqualified praise or criticism to products of a given brand, to the exclusion of all others in their class. This is especially evident when the consultant in question is ignorant of industry practices such as outsourced manufacturing and "badge engineering."
3)Impractical Advice/False Information
You normally trust consultants and IT journalists to provide you with information you do not readily have access to. It is only reasonable that you be able to trust the information they give you. A simple way to protect yourself here is to see what information you can get on facts you already know; if your consultant is wrong there, he/she is likely to be wrong in other areas as well.
Another great way to determine if you are dealing with the real McCoy is to watch out for defensiveness or unwillingness to answer questions you or your staff might have. Good consultants expect to be challenged; they welcome inquiries, are open to suggestions and listen a lot.
If your consultant is unresponsive and full of hubris, consider cutting your losses early. By the way, always protect your shop by placing clauses to deal with such things in your consulting contracts.
4)Information Hoarding and/or Secretiveness
Demand transparency from all you consultants. If a consultant is not transparent in his/her dealings, look elsewhere. Always stress the need for extensive documentation and knowledge transfer on behalf of your staff.
If a consultant insists on keeping you tethered without a really good reason — for example, you have just had a distributed supercomputer cluster deployed and its optimization will take a few months — take it as a clear sign that you should keep looking. This is not to say that you should limit your choices to open source solutions or that you should expect consultants to give away their trade secrets. Rather, what is advocated here is a reasonable delivery of a finished product with enough documentation and training to insure maximum enjoyment for the expected life of the product.
Don't allow yourself to be conned. No need to thank me. That's what I am here for.
Here for example is a real gem. Number two says, "It takes too long to cold-start servers to react to spikes in demand. If customers are made to wait, they'll go elsewhere." The author then proceeds to make asinine suggestions such as holding a site hostage until additional servers — which you turned off on his advice — are brought online. He supposes users will sympathize with your cause and wait around until your site is good to go.
Apart from providing some belly-holding, rolling-on-the-floor laughs, this bit of advice is not only naive, but it betrays absolute ignorance as to how data center and servers work.
First of all, Mr IT journalist guy, the users will go elsewhere — even card-carrying Green Party members seeking to buy recycled products will move on and will likely never come back — this is a lesson every e-commerce site owner learns real fast if he/she is to survive.
Secondly, have you any idea how long it takes for a server to boot up and make itself available on the network? Users expect their pages to load in 5 seconds or less.
Regardless of operating system, a data center server needs a good 5 minutes to boot up — and that is on a good day. This does not include integration into a server farm or registering with the load balancer. It is utterly impractical to even suggest that you can keep part of your server farm unplugged and bring it up in time to deal with increased traffic.
But the purpose of this post is not necessarily to beat up on Mr Harbaugh — although he does deserve the beating. Instead I want to focus on all the times and circumstances in which management listens to boneheaded advice from "consultants" or IT Journalists, as our friend Logan here, and hurt their businesses.
This happens so often that it poses a real threat to IT operations. I would include sales reps in this list, but I assume any MBA holder with half a brain is smart enough to realize that sales people will always say what their targets want to hear in order to get their respective commissions.
Consultants, consulting firms and trade publications (the poor manager's consultant) , however, are expected to be on the side of the people who come to them for advice. But it has often been the case that these people fail their trusting followers miserably.
If these failures were the product of human imperfections, I would not be so upset; but they are instead caused by other factors that should not be allowed to go unchecked, Here are a few along with — and you will love me for this — ways to recognize when you are being had.
1) Agendas and/or Causes
No matter how noble and just a cause, trade publications and consultants must reserve their first allegiance to you, their client or customer. When you go to the grocery store to buy milk, you do not expect to get pamphlet on animal cruelty instead of the gallon of the white stuff are there to pick up. You can tell preachy consultants by their lengthy speeches that have nothing to do with the task at hand. As terrible as the situation in Burma is, your server farm should be the topic of conversation in a meeting called for that purpose.
2)Unholy Alliances
Regardless of how good the products in question might be, a consultants or trade publications that take the side of vendors, are no longer what they claim to be. The have become mouthpieces and salespeople.
The job of a consultant (and, hopefully a professional journal) is to review products and services and only recommend the best of breed.
One easy way to tell these salespeople in disguise is by the way they give unqualified praise or criticism to products of a given brand, to the exclusion of all others in their class. This is especially evident when the consultant in question is ignorant of industry practices such as outsourced manufacturing and "badge engineering."
3)Impractical Advice/False Information
You normally trust consultants and IT journalists to provide you with information you do not readily have access to. It is only reasonable that you be able to trust the information they give you. A simple way to protect yourself here is to see what information you can get on facts you already know; if your consultant is wrong there, he/she is likely to be wrong in other areas as well.
Another great way to determine if you are dealing with the real McCoy is to watch out for defensiveness or unwillingness to answer questions you or your staff might have. Good consultants expect to be challenged; they welcome inquiries, are open to suggestions and listen a lot.
If your consultant is unresponsive and full of hubris, consider cutting your losses early. By the way, always protect your shop by placing clauses to deal with such things in your consulting contracts.
4)Information Hoarding and/or Secretiveness
Demand transparency from all you consultants. If a consultant is not transparent in his/her dealings, look elsewhere. Always stress the need for extensive documentation and knowledge transfer on behalf of your staff.
If a consultant insists on keeping you tethered without a really good reason — for example, you have just had a distributed supercomputer cluster deployed and its optimization will take a few months — take it as a clear sign that you should keep looking. This is not to say that you should limit your choices to open source solutions or that you should expect consultants to give away their trade secrets. Rather, what is advocated here is a reasonable delivery of a finished product with enough documentation and training to insure maximum enjoyment for the expected life of the product.
Don't allow yourself to be conned. No need to thank me. That's what I am here for.
Subscribe to:
Posts (Atom)