The latest figure I have for TV stations in the US is 1773 — not including low power outfits. Even assuming average transmitter output of 10,000 watts, the impact of such consumption is considerable : well over 20 megawatts at least. This is by no means a trivial power requirement.
Now imagine if we doubled the amount — which is what we have to do to account for the fact that all commercial stations are currently broadcasting both analog and digital signals. As costly as this is, commercial television broadcasters have had plenty of time to incorporate into their budgets the dual power requirement of parallel broadcast transmissions. However, an unplanned extension of the deadline is likely to bankrupt smaller TV operators — the kind most likely to hire locally — and cause further unemployment in smaller markets. The other victims of such a delay would be the tower and transmitter service companies that were looking forward to drumming up some business around transition time.
So, in order to accommodate a lackadaisical and markedly small segment of the market we are willing to continue to weigh down on the power grid and further jeopardize an embattled industry? Come on Congress, that wouldn't be smart at all.
It is true that there appear to be some 6.5 million homes unable to receive digital television. However, we do not know with any certainty whether this deficiency is caused by poverty, disinterest or procrastination. Although the government has run out of coupons, many people have allowed their coupons to expire. I think these people would be a lot more motivated if they could not get any signal on their TV sets and found out from their friends what they need to do. As for the converter boxes, I believe their prices will drop making the coupons unnecessary.
I remember reading on an online forum that in Europe,where there was no coupon program, comparable boxes are sold for the equivalent of almost half the $40 US sticker price. Besides, if the government is so concerned about these households they could allocate some money for low interest loans to people wishing to buy the cheaper digital sets and/or converter boxes. Considering that the alternative is so costly to TV broadcasters, I think even they would welcome an alternative that would involve them pitching in to a fund to upgrade analog homes in their respective markets.
Look at cell phones. Look how we have migrated from analog to digital cellphone service without coupon programs or anything like them. To quote President Obama, "yes we can."
Monday, February 2, 2009
Superbowl Snafus
NBC regaled the nation with a few glitches in the broadcast of the Superbowl. After so many years of the roster, they were a little rusty putting on the show.
Comcast's dubious technical credentials were once again highlighted by 30 seconds of full frontal nudity it served its non-digital subscribers in parts of Arizona. This reminds me of two of my gripes with the cable giant:
My question to Comcast is, whatever happened to quality control? It is true that their digital service is slightly better than their analog feed, but not by much. I remember seeing snow in my HD feeds. Plus the hu m bars in their inDemand offerings render many of them unwatchable on a big screen.
Along the lines of Q.O.S. (Quality of Service), considering that most subscribers use the analog feed, some for their primary receivers and some for secondary units, wouldn't it make sense for Comcast to persuade them to upgrade through quality offerings.
This is a lesson satellite providers like DirectTV and Dish have learned. The reason their subscribers happily upgrade from a $29 basic package to an $80 enhanced lineup or even $400 sports pass, is that users are habituated to associated the service with high quality images and sound.
When dropped cable for DirectTV, my biggest surprise was how much more local television I was watching. The reason was that even local channels were more watchable. DirectTV manages to give me a better signal from my local stations than locally-based Comcast -- imagine that!
And Service, Comcasts continues to offer limited telephone support with some of the least cooperative operators. I hope this latest x-rated snafu causes more people to abandon their service and cause the company to shape up. My main complaint with Comcast is that, by being the largest cable operator, they give all cable providers a bad name. The truth is that there are some pretty good cable companies out there I've had positive experiences with the likes of Cox and Adelphia.
Although, I still have some bones to pick with industry effort known as CableLabs, I believe the problem with sub-par players like Comcast is their corporate culture and lack of commitment to service. Shame on you, Comcast!
Comcast's dubious technical credentials were once again highlighted by 30 seconds of full frontal nudity it served its non-digital subscribers in parts of Arizona. This reminds me of two of my gripes with the cable giant:
- Non-digital package subscribers are treated as second-class citizens.
- There is no attention paid to customer service -- even the DMV beats them in this area.
My question to Comcast is, whatever happened to quality control? It is true that their digital service is slightly better than their analog feed, but not by much. I remember seeing snow in my HD feeds. Plus the hu m bars in their inDemand offerings render many of them unwatchable on a big screen.
Along the lines of Q.O.S. (Quality of Service), considering that most subscribers use the analog feed, some for their primary receivers and some for secondary units, wouldn't it make sense for Comcast to persuade them to upgrade through quality offerings.
This is a lesson satellite providers like DirectTV and Dish have learned. The reason their subscribers happily upgrade from a $29 basic package to an $80 enhanced lineup or even $400 sports pass, is that users are habituated to associated the service with high quality images and sound.
When dropped cable for DirectTV, my biggest surprise was how much more local television I was watching. The reason was that even local channels were more watchable. DirectTV manages to give me a better signal from my local stations than locally-based Comcast -- imagine that!
And Service, Comcasts continues to offer limited telephone support with some of the least cooperative operators. I hope this latest x-rated snafu causes more people to abandon their service and cause the company to shape up. My main complaint with Comcast is that, by being the largest cable operator, they give all cable providers a bad name. The truth is that there are some pretty good cable companies out there I've had positive experiences with the likes of Cox and Adelphia.
Although, I still have some bones to pick with industry effort known as CableLabs, I believe the problem with sub-par players like Comcast is their corporate culture and lack of commitment to service. Shame on you, Comcast!
Wednesday, January 7, 2009
Watchers Vs Readers
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.
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.
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.
Subscribe to:
Posts (Atom)