You Shouldn't Have To Read This

Engineers are scientists and, as such, I have always insisted that we should not meddle in politics because such an entanglement makes for bad science and worse politics.

However, as the Al Pacino character in Godfather II said, "just when I thought I was out... they pull me back in." -- "I"meaning all of us technical people and "they" meaning the Congress of the United States, or politicians.

We went through something like this with the DMCA and then with "Net Neutrality." Now SOPA (the Stop Only Privacy Act) is the soup of the day -- actually it is more like the human waste that is produced when someone ingests spoiled soup.

America is truly an amazing country. Our Congress, whenever their incompetence is most apparent -- just look at the economy for Heaven's sake! -- they tend to dabble in the most inconsequential things such as baseball or, unfortunately for us, the Internet.

In the midst of a floundering economy the sector that is most promising and actually thriving is having cold water thrown at it. This is like a drowning person deciding that drinking large amounts of seawater would be good idea on since the salt in the water is a natural source of sodium.

So what is this SOPA thing all about? If you don't mind legalese terms such as "in personam" and language so thick it puts mud to shame, you may access the full text here. For the rest of you who prefer plain English here is a brief summary.

SOPA puts the burden of protecting intellectual property on ISPS and search engines. Sounds like China's great firewall to you? I am afraid you are right.

Apart from the twin facts that China is a dictatorship (hardly the country America should be modeling its laws after) and that China's catch-all censorship has proven more annoying than effective (at least to power users), this sort of legislation will stifle technology, drain ISPS of cash via huge fines and make search engines virtually useless if not illegal. It places the burden of blocking sites that violate IP laws on the aforementioned.

Google, which had to leave China because of their anti-free speech rules, may also end up facing the same choice in the US. This is insane. Will Americans seeking unfiltered search result have to turn to China's Baidu.com?

And there is an even greater moral hazard here. SOPA's proponents claim that it's sole purpose is to protect intellectual property. Even if we were to overlook the spotty record of IP policing and prosecution in the years since DMCA (including innocent victims and companies issuing notices for material they did not in fact own the rights for), given the fluidity with which IP violations have been redefined to suit certain agendas, this law is an open invitation for fascist politicians to initiate IP violation notices against sites that espouse political views with which they disagree. Even more slyly, these rats could attack the advertising networks --yes the law does address advertising networks -- that support the sites they dislike.

In the same way in which Soviet Russia labelled dissidents "reactionaries" rogue politicians could label the bloggers they dislike "IP-violators!" If you are not alarmed yet, you are probably a bot incapable of passing a Turin test.

Let me reiterate that I do believe in protecting intellectual property rights -- online and off. The courts have been enforcing the law for the past 20 years of public Internet with existing laws. SOPA is not needed --plus it's harmful. We even had a teenager extradited to the US for 16 lines of code because IP holders felt threatened by. What more to these people want?

I hope sense prevails among legislators and that those whose will is steeled by campaign contributions will be in the minority. As the closing screen of an old public service ad once proclaimed: "God, bless America, please."

To read more and do your part in combatting this anti-technology, anti-freedon piece of drivel that passes for law, click on the links below. I urge especially to click the online petition:

• House Judiciary Committee SOPA Hearings Stacked 5 To 1 In Favor Of Censoring The Internet


• Open Letter to House Judiciary Committee


• Stop Online Piracy Act [Wikipedia Article]


• SOPA Bill Turns Competing Tech Giants into Unlikely Allies


• Infographic: Effects of the Internet Blacklist Bill (SOPA)


• ►► Online Petition◀◀

_________________________________________________________

The Day The Music Died

I am still recovering from the shock at the headline announcing the death of Steve Jobs. Beside being the face in front and the heart inside Apple for almost 30 years, Steve was a visionary the likes of which are hard to come by.

Steve Jobs was not just an innovator he was a leader in creating new paradigms, new cultures, new worlds. Its not that he invented gadgets; he showed us the way to a universe we had never seen before and made us feel a home there.

He was a great man and will sorely be missed.

Give Hydro-Engineering A Chance

As with all challenges faced by engineers, these days of record heat should help spur innovation.

The field of geo-engineering, especially because it involves lofty projects that wow visitors and investors alike, gets a lot of press these days. And, I will not belittle its usefulness.

However, the often neglected field of hydro-engineering holds a lot of promise as well as challenges that have yet to be met.

Water, although not the best heat exchanger (hardly anything beats Freon gas) is abundant cheap and safe. I think there is a lot of room for devising systems that combine water and air to cool large spaces effectively, efficiently and perhaps even more cost-effectively that is done nowadays.

In the same way that lakes and rivers help to temper environmental heat, water-based heat exchange technology could be used to boost existing climate control systems.

Another area where hydro-engineering could help improve quality of life on this planet would be through easily deployed light pipelines that would combine flood control with irrigation. It's a fortuitous coincidence and somewhat of an irony that flooded areas are often just a few hundred miles removed from drought-stricken regions.

Imagine if we could move water from the flood-prone Mississippi delta to the scorching Nevada desert, or from Monsoon drenched Bangladesh to the scorched Sahara desert. Water, young man!

The Shifting Sands Of Social Networking

As Google+ debuted with much fanfare and as it was revealed that Facebook creator Mark Zuckerberg pretty much endorsed his competition by both admitting that he had a Googled+ profile and commending the service, I realized that social networking is quite a unique field in which to operate.

Like with the MTV series The Real World where season is likely to bring a new cast and story line, Social Networking's wagons seem not very amenable to longtime commitments. Those who had hitched their wagons to MySpace can easily understand where I am coming from.

I don't think Facebook is going anywhere anytime soon, but I think there is a real possibility that it might be at least partially eclipsed by the big G.

Social networking has a lot in common with cellphones except that, not being physical and not requiring two year contracts (or money for that matter), the players fortunes are a lot less secure that one might presume.

I say this not for Zuckerberg's sake as I am sure his financial advisor's are taking care of that end, but I want to warn developers who might find their Facebook allegiance unfruitful should their target demographic decide to move on.

As I have always warned my colleagues, those who refuse to design and plan independently of platform will find their work becoming irrelevant soon enough —Foxpro developers know this all too well.

A clearly designed game or application can be conceivable ported if its features follow a platform-agnostic design. There is a difference between maximizing the strengths of a port's platform and designing around it.

It also goes without saying, that we should choose our platforms like we chose our tools: the right one for the right circumstance. It doesn't hurt to ask the hypothetical question how could we go about moving our cash cow if we needed to?

Engineers and Politics

Writing as I am on the morning after the President's State of the Union address, as much as I feel tempted to, I will still resist the temptation to comment on it. My main reason is that this is not a political blog. and the speech was a political event with mostly political implications. Some of its ramifications may affect the technology world down the road. Then would be a great time to comment on them.

However, I do want to use the momentum of the Speech to warn my fellow technologists of the pitfalls they might encounter on the road to Washington. Honestly, I think good engineers serve the nation better by developing the technologies that improve the quality of life of our fellow citizens than by going into politics.

Yet, since politics has a way of insinuating itself into every aspect of life, it might be useful to try to flesh out some principles that those of us in the world of zeroes and ones can follow in order not to support political agendas that will hurt our work.

(1)Fuzzy is as Fuzzy Does
Precision in implementation, measurements and language are staples of the engineering world. Ambiguity in technology is not just frowned upon; it has no place. In politics, however, ambiguity is often sought and frequently used.

This translates many times into politicians drafting members of the digital economy into fighting against their own interests.

So how can we protect ourselves from shooting ourselves in the proverbial foot? In the same way in which we harden our applications for use in the real world: know the environment. In other words, do your homework and fully understand the issues before committing.

Int their book, Freakonomics, Levitt and Dubner, warn us to always remember that experts have their own self-interest in mind even as they make recommendations. This applies infinitely more to politicians.

(2)Neutrality, It's Not Just Good For The Net
One of the advantages of being an engineer is that one is excused if one chooses not to take a position in political or otherwise extraneous matters.

It turns out that this is a very good idea. This course of action is especially advisable when the issues being discussed or the way in which they are being discussed are murky. Take, for example, net neutrality.

I have read and heard so many a definitions —at times conflicting, at times too imprecise— of the term "net neutrality" to render it useless for engineering purposes. The situation has gotten so bad that should Congress pass a law that says "let there be net neutrality," no one would have any idea how to implement it.

Once upon a time, net neutrality used to be defined as all data packets on the internet being given the same priority regardless of content or origination. Not one of the positions currently being debated involves this simple definition, therefore the discussion is really about something else nowadays.

In times like these, it would serve the technology world best if many of us were to remain neutral until the concepts are properly clarified. Otherwise, we might end up actively promoting policies that hurt our our principles, our livelihoods, or both.

(3)Don't Be Evil
This applies not just to large Google-like corporations with valuations in the billions of dollars. We all have some measure of power to affect how the lives of others will be governed. From voting at ballot station to serving in some advisory panel.

It is vitally important that you remember that with power comes responsibility, that good law is measured not by its intentions but by its effects, that freedom is self-correcting while coercion self-multiplying, that the moral hazards of a policy can nullify its laudable objectives. Above all impress in your mind that there is such a thing as the law of unintended consequences; it is as pervasive as Murphy's and neither may be safely ignored.

Wether you are worth a few hundred dollars or a few hundred billion, please, for the sake of the rest of us and your own, don't be evil — and do not support the causes of evil people either.

Not Another Year In Tech Blog Post

So many publications attempt to summarize the year in technology news that I think It would be better for me to focus instead on what we can gather from what happened once the dust has settled.

2010 was an interesting year on many accounts, especially on how wrong the pundits and "consultants" were.

This was supposed to be the year that the Android OS overtakes iOS (the iPhone OS) as the preferred mobile platform. Hasn't happened. In fact, I would venture to say, that despite the stellar debut of the iPad tablet, the iPhone was the star of the year.

From the debut of the iPhone 4, to the ever expanding AppStore repertoire, to rumours of a Verizon iPhone. The iPhone has been on everyone's lips and remains fixed in the publics consciousness.

I will not dispute that there might be more Android phones out there than there are iPhones. The latter's edge however is that its owners usually replace their iPhones with another and that newcomers to the smartphone market ask for it by name. The Android phones seem to be the generic alternative that people get when the can't think of what to ask for. I recall hearing a PC Magazine commentator saying that the Android platform's biggest weakness is its inconsistency and lack of uniformity.

Having written what could be interpreted as paean to the iPhone, I will refrain from committing the same mistake I rail against so-called experts for. I will not predict which platform will come out on top in 2011, but I will say that the Android is not the shoo-in that many claim it will be.

I will venture to predict though that the iPad may experience a resurgence in the next 12 months. Apple deserves credit not only for giving tablets new life but for insuating it into more areas of life thant any other company that has marketed them before.

"Honored more in the breach than in the observance," the PC must be mentioned for its near absence from techology news. I say this to point out how subtly specialized devices called computeres are being replaced by devices with similar computing power but different designations. I think 2011 will mark the continuation of that trend.

Google, Windows and Security

The Financial Times reported toward the end of last month that Google was going to stop issuing computers running a Microsoft Windows operating system to their employees, with very few exceptions.

The story has caused some furor in IT circles with many opinion columnists warning about the "consequences" of such a sweeping decision. It's hard to understand how anyone could be surprised by this move given Google's Chinese operation being
hacked due to vulnerabilities in their Windows computers.

In fact, I was surprised the search giant was still using Internet Explorer internally given the very warnings published on Googles own site. Yet, the attack did exploit vulnerabilities even Google had not documented.

It is interesting though how so many are now taking on the role of advisors to Google on their OS decision. PC World columnist Tony Bradley, for example, criticized the move while using the oft-cited platitude that Windows has more viruses because it has more users.

Mathematical modeling might suggest that the most used OS will be the one most targeted by by hackers, and the concept cannot be proven to be totally false. However, this alone is not a valid argument nor does it comport with other realities of computing.

Although most users access the Internet using a Microsoft OS, the majority of servers run a Unix-based OS. Given the greater documentation and source code available for the various *NIX operating systems, these servers should be an easier target for exploits. After all, it is much easier to get the fixed IP address of an unpatched server than the transient IP of a broadband subscriber. Yet, it is the latter that gets hit most often, but only if he or she is running a certain browser/OS combination.

Some of the arguments I have been reading from Widows advocates quote the famous yearly Pwn to Own contest as proof that OS X is insecure. However, some of these same people eschew the very same result set and quote Secunia advisories instead to prove that Linux is insecure.

Two things become clear from such truncated arguments:
1) neither result set can be used by itself as a determinant of OS security, especially given real world evidence, and
2) the tap-dancing betrays a lack of seriousness and intellectual honesty.

Moreover, from the comments by Windows users that I have read in which they explain how much better Microsoft security is, I gather they do not understand how UNIX security works.

Let's begin by admitting freely that all operating systems have vulnerabilities.

Even when there isn't an OS-borne vulnerability, plugins and applications such as Adobe Flash, Acrobat Reader or Microsoft Windows Help And Support Center may introduce one — as of today, these three are at the top of Secunia's list interestingly enough, but lets move on.

While Windows OSes are built on the NT base which is based on the old VMS model. All Linux distros and Mac OS X, are based on a UNIX architecture to one degree or another.

There are fundamental differences in how these two OS families are structured. Without judging just yet, let's examine the key differences between security models.

In the UNIX world security is based on ownership. Ownership determines access and access determines privilege. All files are owned and all objects are treated as files. There is a superuser who initially owns everything and can dole out privileges and ownership to other users.

In Windows machines the security model is access based. There are user access controls (UACs) and access control lists (ACLs). A file's owner is more of an attribute that is mapped to the an ACL. Unlike UNIX there is a "system" that owns processes and files. This "system" is not a login user (and is not subject to any UAC or ACL) but plays the role of owner of last resort, not necessarily subject to the "Admin" or most privileged login user. Such splitting of the superuser's powers is baffling to UNIXheads.

The merits of each system versus those of the other could be debated ad nauseam. In fact, I think many pubs owe their livelihood to throngs of UNIX and windows sysadmins imbibing enormous amounts of libation while deliberating on these differences.

In the real world, however, the UNIX system has consistently proven to be a lot more resistant to outside attacks. Day after day millions of windows machines get exploited and controlled the world over, while their nearby Linux and Mac counterparts (even on the same networks) are untouched.

I think the main reason for this is that, in Windows, the elusive "system" user can be easily manipulated or impersonated by a hacker. I remember a particular vulnerability I witnessed where a rogue website operator could open a command window and perform system tasks without the local user even seeing what was going on.

The worse part is that, since "System" has a higher rank than "Admin" in the Windows hierarchy, even an alert administrator can only counteract such attacks by pulling the power plug or the network cable. Is it any wonder how so many trojan horses, worms and malware can get installed so fast on so many systems?

To achieve comparable access on a UNIX-type system, a hacker would have had to steal a root or superuser password. Or the superuser would have had to have opened up too many doors to guest users. The only ways for the former to happen is for the hacker to pry the information from sysad or physically break into the data center.

Another weakness in Windows systems is the Registry, which no version of windows seems to ever check for integrity or validity before loading the values it contains. However, the Registry controls just about every aspect of the system's operations.

Many of the infections I have had to clean from Windows computers have taken advantage of various Registry hacks. The irony of this [and I faced this not long ago when dealing with a particular virus] is that, although a user can be prevented from accessing RegEdit, the Registry editing tool, the hacker's script can freely modify it because the malware runs with System privileges!

Another Windows weakness is Internet Explorer. Although Microsoft has been improving on it's flagship browser over the years, the nexus between Windows Explorer (its Window Manager) and IE provides a handy backdoor for mischief. To make matters worse, the same scripting engine used for local shell tasks is used by the browser to control web pages. ActiveX (a binary execution layer and plug-in container) and VBScript are probably the two biggest holes in IE, and JScript is not far behind.

Despite all these issues, most IT departments do not have the options that Google's has. For reasons of culture, convenience or necessity, they must support machines running one or more versions of Windows operating systems. Also, despite the proven security of competing operating systems, "social engineering" — hackers fooling users into cooperating with them— remains a big vulnerability in any shop.

The bottom line is that, having honestly assessed what the risks are — without spin, sophistry or FUD— IT departments need to proceed with caution and remain vigilant to keep their systems uncompromised. As an old US Army slogan went, "OPSEC is 24/7."

What Apple Should Not Learn From Microsoft

Mac enthusiasts have chided Apple, Inc, for not having the marketing savvy of rival Microsoft. The implication is that the Cupertino tech powerhouse should learn from the Redmond giant when it comes to the ways in which the latter grows its market share.

I cannot argue with that; in fact I think there is probably a lot of truth to it. However, it is now clear to me that there is one thing Apple has learned to do the Microsoft way a little too well: making the default browser run with too many privileges.

According to a PC World report, researchers participating in 3Com's annual Pwn2Own competition were able to hack into both the latest iPhone and Macintosh computers using the Safari web browser as attack vector.

Although it is not initially apparent to the average user how much privilege the Mac version of Safari runs with, the iPhone version is too ubiquitous and is used in too many cases on the portable device to not be seen as a base app with tentacles in many of its functions.

It seems as if the Mac's Dashboard desktop application uses the same WebKit rendering engine that Safari uses; and therein lies the weakness the browser represents. Just as with Microsoft, Apple could not resist the temptation to sacrifice security on the altar of efficiency.

What should Apple do? I was initially tempted to suggest that they take a page from Konqueror, the browser used by the KDE project. It integrates with the UI yet appears to be quite secure. I remember being warned by it when it detected a rogue website containing a VBScript exploit that would have allowed a hacker to gain command line control of a client Windows machine.

However, I am a little cautious because Konqueror would not have been vulnerable to such an attack even if it had not been detected. I am left to wonder if it would be as resilient with an attack tailored toward a language it has a runtime for.

Either way, I must at least credit the Konqueror web browser if only because its creators seemed to have been aware of the possibility of such attacks, unlike their fellow WebKIt users over at Apple.

At the end of the day, however, it all seems to boil down to privileges. If both the web browser and the UI shell — with its almost unlimited access rights — are to use the same rendering engine for HTML/XML content, then a way needs to be devised that will grant or deny privileges based on the source of invocation.

The Snow Leopard exploit granted command line access to a hacker for the computer running Safari. The iPhone OS vulnerability, for its part, allowed access to the devices SMS contact list. Although the details of the attacks have not been fully disclosed, we can safely infer that both exploits gave unauthorized local access to a remote user by using the web rendering engine or its parent process.

Maybe the rendering engine should be rewritten in a way that checks for the credentials of the invoker. Maybe, the OS should run a separate copy for local tasks. Whatever the solution, this pivotal security barrier should never be broken.

When a third party browser, such as Firefox or Opera, is run. Obviously, the incestuous relationship between browser and OS shell is to blame. Come on, Apple, you know better than to learn from the OS family with possibly the worst security record in the history of computer operating systems.

Read More About It

• Hackers take down iPhone, Safari, IE8 and Firefox in one day at Pwn2Own


• Hackers offered $100,000 for browser and phone exploits


• Safari, IPhone Hacked on First Day of Pwn2Own Contest

Interns and How To Use Them (or Not)

My last couple of posts have had to with your shops body of expertise, especially as expressed in terms of a learning organization and R&D. Although I see interns as a natural extension to such efforts, I realize the concept might take a little explaining when it comes to many.

Internship programs are a little like salads; even the bad ones have something good in them. However, it is sad how many businesses miss out on the great asset a properly structured internship program can be.

The mistake an overwhelming amount of businesses make is to assume that internship programs are mere PR exercises, imposed by HR on every department on a whim from management that only translates into a lot more coffee being brewed.

As a result no effort goes into interviewing or recruiting the right kind of interns. Interns are merely tolerated into boredom, especially in IT — where we all get our own coffee, thank you— and and nobody benefits in particular from the program.

Such a routine repeats itself all too often while valuable talent and a research tool are wasted. Ironically even under such undesirable circumstances the company may gain some good will in the community and some potential new talent might get discovered. But so much more can be gained.

Here are some suggestions on how IT can insure it gets the right kind of interns and utilize them in the best possible way. These should make interns welcome additions to your IT crew.

(1) Be Selective
This is very important. You really want to make sure you get the kind of interns that will be great members of your team, even if temporarily so.

If possible, interview the prospects your department will be taking on. If this is not possible, have them write a short essay on what they expect to get or learn from an internship. The idea is you want to make sure there is some connection between what you are planning and what the interns expect to be doing.

I should be careful to point out that your best interns may not necessarily be Computer Science majors. Sometimes majors in other disciplines have the right aptitudes and attitude to be good IT interns.


(2) Plan Far Ahead
Interns are best suited to long-shot tasks that would be too time consuming for regular staff. Be careful though to make sure they lend themselves to easy ramp-up. Also, make sure you have clear goals and proper metrics in place. This not only boots intern morale but helps in determining how successful the program is.

Do not plan on improvising. Have a long list of items on the ready. Nothing encourages commitment and seriousness like a well planned to-do list.


(3) Be Flexible (and realistic)
While many managers are accustomed to getting eight or more hours out of their regular employees, such expectations are unrealistic when it comes to interns. If an intern's agreement specifies eight hours expect no more than seven and a half. Sme interns may have signed up for half a day or even less.

Be strict about quitting time. Many interns leave to go to jobs or classes and may not be bold enough to insist on being released on time. Getting penalized at their next appointment may dampen their enthusiasm.

Whether they work for a small stipend or for free, let them know they are appreciated. A small expense that goes a long way with interns (who are mostly broke college students) is food.

Keep the kitchen stocked with snacks and drinks and give them a free lunch without fail — with many interns, this might be their only real meal. You would be surprised by how much can be accomplished with such a small and relatively inexpensive gesture.


(4) Sandbox and then Sandbox Some More
I remember a certain large corporation, which shall go unnamed, that was brought to its knees for almost two days after an intern accidentally wiped out one of its key databases. This should easily lead us to rule number 1 : do not ever expose interns to production systems, clients or sensitive data.

Remember that, unlike your employees who have signed legally binding NDAs and are covered by your firms professional liability insurance and other legal mechanisms, interns are merely expected to behave themselves within reason. So, sandbox them.

Interns should never have access to customer data. They should never work on any mission-critical system or application. They should never be allowed to sign off on or access any code after it has been signed-off on. They should not participate in any release or communicate directly with clients on behalf of the company. Your legal department will be happy to fill you in on reasons; I will just summarize by saying that you will regret it very much if you don't take these precautions.

So what can interns safely and reliably do? Well here is a list types of projects that are not only sandbox-safe but are challenging and fun enough to be motivating to both interns and engineers:

Proofs of Concept

This type of project is among the favorites of programming enthusiasts and is probably one of the best ways to get quality R&D work done practically for free.

Code Libraries

This is safe way in which to get interns to contribute to the shop's products and it gives them something to take pride in.

QA and Testing

With the proper precautions and done right, testing can be fun for your interns and extremely profitable for your shop. Some of the less demanding type of testing, such UAT, is ideal for interns whose technical skills are limited.

Requirements Gathering

This is another task that many interns will enjoy and that will leave the company with a useful outcome.

Documentation

A task that is always left until "later", creating or editing help files and other documentation for software is a task very suitable for interns.

(5) Plan For the Future
As you get ready to sign the evaluation sheets for your interns, plan for the next year.

Mark the interns you would like to have back the following summer. Likewise take not of the ones you would rather not have return. But most importantly, use the experience to compile a list of the qualities that you appreciate in an intern; this will help you in recruiting your next batch.

As it with every asset at your disposal, an internship program can be another way you can gain an edge on your competition. In the spirit of carpe diem, I encourage you to seize the program this year and next.

Why You Need R&D And How To Get It For Less

If your development shop is to improve in technology and quality while outpacing the competition, you need some amount of research and development (R&D). This is especially crucial in shops seeking to expand their intellectual property portfolio.

However, the word on the street is that R&D is only for very large corporations such as IBM or Microsoft with billions to spare. I used to feel that way too, but I was pleasantly surprised to learn from the best in the business that there was a cheaper alternative.

It turns out that Google, as in so many other areas, has blazed that trail. Not by inventing the concept, but by proving that it could be done. The idea of giving developers a percentage of their bench time to pursue whatever idea they fancy had been floating around for a good long while but had been flatly rejected by others.

I recall a certain project manager who would say "we all want to have fun, but we got bills to pay." This appears to be the rationale in most development shops, especially if there are budgetary constraints. However, I would like to propose a way to get around this hurdle fairly painlessly.

The first step is to improve in the time management department. It is surprising how poorly time is managed many development shops. For example, although there are long days at crunch time, between patches and releases, time killing is pointlessly common or filled with meetings of dubious utility. Methodologies such as Agile have resolved this imbalance somewhat, but we need to go even further.

Developer bench time can be optimized painlessly if done gradually. I would suggest beginning with a 5% allocation for personal projects. This is the equivalent to two one-hour meetings in a 40-hour week, barely felt but significant enough to establish the practice and explain the principle.

The key is to make sure this is not seen by developers as a break or social time. In fact, I would suggest two rules to make sure what needs to happen, happens during this special time:
(1) No web surfing except for brief visits to coding sites
(2) Heads down coding throughout — no pressure on the quality or the amount though.

Do not expect much to happen the first couple of weeks except for some habituation. However, if this schedule is kept religiously and developers are asked to speak briefly about their "personal projects" during the warm-up for regularly scheduled meetings, expect to start seeing some incredible code being generated by week number three.

The beauty of this practice, is that you will start seeing improvement in the quality of the production code and even an increase in collaboration among the developers.

As you start reaping the benefits of this program and your team's productivity grows —by virtue of their becoming better developers and by virtue of some of their personal project code finding its way into released software— it will be easier to sell to management the idea of expanding personal project time to a healthy 20%.

But, be patient enough to do so gradually. It is okay if it takes two years to go from 5% to 20%. The practice will yield fruits as long as it is done properly.

So there you have it: a very simple way in which your shop can benefit from R&D without breaking the bank. You are welcome.

The Learning Organization And Why You Need One

Many people in management believe a learning organization is one of those things that are "nice to have" and will be gotten around to if there is time or money available.

Worse yet, many think the phrase represents just another useless fad and want nothing to do with such a concept.

I will assume the worse and try to sell you on the idea before telling you how to get there.

If the sum total of your company's expertise is no more than than that of a single employee —even if that employee is the genius founder— then your organization doesn't have much of a future. The world becomes increasingly complex as time advances and your firm needs to keep up.

So, what are good examples of learning organizations? Google, HP, Apple, Walmart, Microsoft are just a few of the companies that in one way or another may be characterized as learning organizations. Their balance sheets and market positioning attest to the value of the knowledge based shop. But enough of the preliminaries. Lets begin by defining a learning organization.

The beginning and end of a learning organization is the realization that knowledge is valuable asset that is as worthy of safeguarding as any other capital good. In fact, it is fair to say that knowledge is probably the most important asset, and I am not just talking about intellectual property or patents, which is more of a legal construct.

Having established that the valuation of organizational knowledge is the mark of a learning organization and the secret of its success, let us examine the ways you can make your organization a learning one. After much thought I realized that five action words pretty much sum up the attitudes of knowledge shop:
1) Document
2) Train
3) Audit
4) Preserve
5) Transition

Document
I have to be careful when I say "document" because many companies bury their employees in red tape and procedural straight jackets in the name of "documentation."

No, no, no! In fact, hell, no!

Documentation does not mean filling out forms in triplicate or writing thick hundred page reports with useless details that nobody will ever read. This is is actually a productivity killer.

The documentation that works is the kind that fits easily into the workflow and is not onerous. In fact the best way to get your developers documenting their work is to give them a say in which is the best way to document their work.

A easy exercise is to have developers perform a specific task which they document the best way they can think of. Then have them pass on their notes to another developer who is supposed to replicate the task using only the written instructions supplied by the first developer. Then ask the second developer to write suggestions to the first developer as to how he/she could improve the original set of instructions he or she got.

The best thing about this exercise is that after discussing the results you can put together a documentation guide that everyone will be motivated to use because they are sold on its usefulness. After that, it will be a trivial matter to decide what software to use if none has been chosen yet.

Train
In a true learning organization, all members should either train or be trained at least once every week. This should be written into the contract or the SOP.

Of course, this requirement should be flexible in every aspect. All forms of interactive knowledge transfer should be accommodated : group sessions, learning lunch pair ups, one-on-one cubicle tutorials, conference calls, any which way as long as it allows for note taking and questions.

Although blogs, wikis, instant messages and even tweets are good, they should not be allowed to take the place of actual interactive training.

Also, some amount of learning verification or testing should be worked into the process. This need not be too formal or extensive, but there needs to be a way to gauge what forms of training work best and which don't.

Audit
This is probably one of the most important and yet complex aspects of keeping an organization ahead in the age of information. In the NFL (National Football League) they call it "studying the game film."

Every release, major patch, platform change or post-deployment emergency should be audited internally. It is not only important to have a post-mortem when things go bad; there should be one when they go well too.

Retrospective analysis needs to become part of the workflow. This not only insures improved performance and better quality products; it also helps to solidify winning practices and avoid repeat failures. Think of this as insurance.

Retrospectives will not hold back the team if they are properly planned. Also, if one of the goals of the audit is to make the next release less painful, and the promise is delivered on, the team as a whole will gladly rally behind such reviews.


Preserve
If you have a winning horse, you insure it and feed it the best purina has to offer. You need to preserve proven practices and technologies that work for your team. If these are proprietary and have obvious commercial value, your legal department will probably make sure you do.

However, anything that can help your team and others in the future or around the organization should be preserved and/or disseminated. One way to do this is through a developer intranet knowledge base or wiki.

Care must be taken, however, to provide a proper way of cataloguing or searching this information. Also, it might be a good idea to separate or differentiate preliminary notes from actual finalized data.

Another very important way to preserve knowledge is through enterprise code libraries and APIs. However, no library or API should be allowed be catalogued without proper documentation and source code — this is extremely important especially in these litigious times.

Transition
A learning organization is dynamic and forward looking. This means that it is important to be always planning for the next stage or technology. Although I don't suggest that every new technological fad be followed, I don't think it is healthy for a shop to keep old code around for so long that it becomes too difficult or impractical to support — remember all that old code that needed updating when the year 2000 rolled around?

Be cutting edge, but not bleeding edge. Whenever possible, use the latest stable version of any technology you choose and plan for transition far in advance. Most importantly, go at a pace that suits your organizational needs not, your vendor's sales schedule.

Speaking of transition, technology moves are easier when design objectives are formulated in terms of functionality needed as opposed to technology to be used.

For example, instead of having as a requirement that says "the SAX API should be used for this task ", your stated objective should read something like "a serial access XML parser that is efficient with large data streams or documents should be used." If you do mention a specific implementation, do so parenthetically (as an example).

A learning organization stays ahead because it looks ahead without forgetting the lessons learned along the way. It harnesses (documents) and multiplies (trains) its experiential knowledge. It gets better with time because it maintains a proper feedback loop (audits). It performs optimally because it knows its strengths. It keeps around and sharpens (preserves) its best tools in order to reuse them for even bigger kills. And, lastly, it knows when to change horses (transfers).

IT Spending In Hard Times

Many firms are seeing hard times as certain sectors of the economy have been shrinking over the past few months. This is, of course, not a desirable condition. However, I would like to posit that a lot of good could come from the belt-tightening measures many an IT department will have to go through.

Actually, I should probably begin by stating that there is good belt-tightening and there is bad. Companies that engage in the latter my find themselves in an even worse crisis or, worse yet, may even go out of business.

As IT people, we usually have less control over how much of the company's budget is allocated to our department than how we will allocate the funds we do end up with.

Let's examine different key items on an IT budget and see how these can be kept up to par, if not improved during lean times.

Hardware
It is often assumed that if hardware is not the absolute latest (1) performance will suffer and (2) employee morale will go down. While we should not fall so far behind as to isolate the company technologically, hardware purchases should be justifiable in relation to the job requirement of the employee in question.

For example, studies have show that developers and designers improve their performance when using dual monitors such allocation for these types of workers is justified. However, executives and administrative assistants have no use for such extra spending so IT can save by simply letting them have a single, reasonably sized monitor.

By the same token, there might be other items, such as Blackberries and corporate cell phone accounts, that many developers really have no need for and just represent extra spending — exceptions must be made of course for product engineers who might need to be on call.

Software
This is indeed a great time to look into free tools and open source software. I am not advocating necessarily a wholesale conversion, just that areas of potential savings be identified.

Another, very important area to address is duplication. Many companies, for example, will spend money on site licenses for software they already have in another form. A good example which I have noticed at companies who've used my services is compression software. I have found it ridiculous that a company would spend money to deploy an operating system that has built in compression support and still spend money on a third party compression utility.

Projects
Most companies are good at killing projects that are deemed unprofitable or useless. However, many companies support parallel efforts at great expense.

Sometimes, it is just a matter of ignorance; at other times, it has to do with inter-departmental rivalry. Either way, it is wasteful for there to be duplicated development efforts within an enterprise. Any effort to curtail this kind of thing is worth the expense.

I would suggest a corporate version of SourceForge where all enterprise applications are catalogued and managers can search by keyword or description for applications that they need.

Division of Labor
There is a lot that can be said about this. I will try to be brief. Many companies, respond to crises by either laying-off developers and admins or by getting rid of contractors. While, there are good arguments to be made for either move in individual cases, as fixed policies both are horrendous ideas.

Let's first examine the basics. No matter how good times ever were, the number of full-time developers or network administrators should have been kept to a minimum. There are two reasons for this: (1) we do not want people who have so little to do they get bored and (2) software engineers are the kind of employee you want to have for a very long time as their value to the company increases exponentially as their seniority accrues.

Contractors should be hired to fill temporary gaps in personnel or to supplement the core team in large projects. The decision to hire contractors should always be based on potential saving and should be in no way connected to whether there is a lot of IT dollars to waste.

In other words, if you had to either cut contracts or lay off developers due to the recent economic downturn, you were probably doing something wrong all along,

Amenities
These tend to vary a lot and it's hard to tell a firm that they should remain constant. However, I believe that, if the amenities in question were properly analyzed or justified initially, they would be less likely to be subject to natural variations in the IT budget.

Another thing to be careful of is to mistake necessities for amenities. Office supplies, lights, proper seating and desk space are not amenities they are job requirements — ask OSHA.

Coffee machines, food concessions, free snacks, cable TV in the break room, gym memberships, etc, are actual amenities.

There is no easy way to dispense with freebies employees have grown accustomed to. This is why I always recommend that companies offer just a few choice amenities which they are likely to be able to maintain regardless of the vagaries of the economy.

Another tack would to have employees vote on what amenities they wish to keep and which they are willing to part with. This would help to keep morale high.

Efficiency
These tough economic times are the best encouragement any IT department can have to streamline its operations. If something can be achieved in less steps, reduce the number of steps.

Minimize requirements, simplify procedures, consolidate functions, look into virtualization if you haven't before, do not underestimate hardware recycling or reuse, try not to reinvent the wheel every time, cut costs wisely and where it is least felt or less likely to be seen.

This current crisis is not the first one we have faced and is not likely to be the last. It can be an opportunity to shape our organizations for a magnificent resurgence.

Why We Fight

This phrase has become very popular over the past few years in connection with the Iraq war. I however would like to turn this question on developers : why do we code? What is our job?

Before you dismiss the question as simplistic, or irrelevant, or both, think about it. What is your deliverable at the end of your project?

If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.

—Antoine de Saint-Exupery

Lack of clarity in this respect has ruined many a software engineering job. Of course, I am not trying to say that any outfit can afford to dispense with specialization or division of labor. In a large project no one person can execute every aspect of the job at ever stage of the development cycle.

But, does this mean that we can afford to disengage? Not at all. On the contrary, we should be all the more plugged into the process and and should have the goal clear in our minds.

To truly contribute to a project, developers need to be flexible and open-minded. This might mean enduring temporary discomfort to achieve the greater joy of a solid product—: and, no, I am not talking about pulling all nighters although I do not condemn the practice per se.

The engagement I recommend is a commitment to the final product which would transcend pet peeves and preferences, a willingness to learn, adapt, go around obstacles and eschew pettiness. Given the large egos we IT people have, I know this is not easy; but we will have to if we are to remain relevant.

The Beach On Which Many Come To Die

Reading through Slashdot messages recently I was reminded of the many vulnerabilities web-facing applications are prone to and how little thought is given to their security. After waging fierce battle on the server side, many applications make it to the shores of the Internet only to be shot down by hackers on speedboats.

This happens because poor practices coupled with many misconceptions translate into an incredibly porous security wall safeguarding applications.

The dangers of the web are many and are constantly evolving, so the secret in securing applications is to stick to principles rather than techniques or tricks that become obsolete in short order.

Principle 1 : Don't Give Away The Store
I am not advocating security through obscurity here — that would be very foolish. But I really think that not suppressing debugging error messages at least makes your site more tempting to a hacker — and may even make your application more vulnerable by airing too many details of your server configuration.

Principle 2 : Don't Trust Any Client To Validate or Scrub Data For You
I am a strong believer in client side validation, but I am extremely aware that clients are easily manipulated. Got that? EASILY MANIPULATED! This goes not just for form data, it also applies to cookies, AJAX requests and hidden fields [including the viewstate, for you .NET types].

Some years ago, I recall reading an interview with a famous hacker (I think it was Kevin Mitnick) who said that his favorite hacking tool was a web browser. That was several years ago. Browsers have become more sophisticated and powerful since.

In the trenches, I have had the opportunity to see first hand how much damage a skillful hacker can do using a browser. All this is to say that, the only reason to validate on the client side should be to offload server cycles and for a better user experience. There must be validation on the server side and it needs to be more rigorous.

Principle 3 : Remain Vigilant
Check your logs and raw data from time to time. Look for anomalous inputs or malware signatures. The hacker that failed to break in today is likely to try again tomorrow.

Subscribe to security bulletins. Learn about the vulnerabilities and attacks and keep an eye out for trouble. Nothing beats an early warning system.

Principle 4 : Think Ahead
Look for vulnerabilities in your own applications. It is a million times better for you to find a exploit than for a hacker to do so. Poke your code, be creative with QA scripts. Try to get white hat hackers to take a crack at it. This will pay off in the short and long run.

Principle 5 : Stay Up To Date
In as much as practicable, keep your libraries and compilers up to date. Don't overdo it so much as to be running Beta builds either. I like to say be "cutting edge" not "bleeding edge."

Use the latest stable versions of your platforms of choice, but be careful not to be faddish. Faddish shops also get hacked because they venture into using untested products whose vulnerabilities may not even be known to the manufacturers yet.


In Sum
These five principles, applied to every stage of software development and subsequent maintenance will allow you to guarantee your users a secure application with outstanding uptime.

IT Myths

The IT, world like many other environs, is full of urban legends. We sometimes call them FUD and sometimes we call them "commissioned studies". Some are older than others, but every now and then they come around to haunt us in one form or another.

Linux is Free
This myth is spread by many well-intentioned free software advocates unaware that such blatant lie only harms its chances of adoption. Like with most myths there is some truth to this one: Linux is free for individuals who wish to experiment with it, but not for enterprises.

Even if a company decides to download free binaries from the Internet, switching to Linux will have its costs. The question to ask is how much less will it cost than choosing the alternative. Linux is a fix-and-forget kind of OS solution whose cost of adoption is biggest upfront — but with reduced maintenance over the life of its deployment. This fact sometimes leads many to conclude that it's adoption is costlier when it might in fact be significantly lower than a competing deployment whose upfront costs are nominally lower.

Windows OSs Have The Highest ROI and/or Lowest TCO
This one has been expressed by a number of "consulting" firms in their "commission studies" and is the result of creative number crunching. I don't mean necessarily that Windows OS costs are the worst in the business, just that they are not the shoo-ins many suggest.

For one, it is patently dishonest to suggest that all Microsoft to Microsoft transitions are friction free and require little or no re-training — wake up and smell the Vista, man! This is also an issue with Office 2003 and Office 2007 — fortunately there is third-party software to help with that one.

Another bit of dishonesty occurs when "consultants" fail to work into the Windows OS TCO/ROI the labor costs of things like Patch Tuesday as well as the high cost of antivirus software.

Macs Are Expensive
Again, the only way one can make such an assertion is to only factor in the sticker price. However such an assertion is the equivalent of suggesting to the police department that they could save on costs by dropping the training requirement from their recruits.
Macs may have a higher sticker price, but have lower maintenance costs than PCs and have a longer useful life. This needs to be factored into any serious study.

Now That We Have Java/C#, Who Needs C/C++?
Back in the 80s there were those using this same kind of logic to predict the demise of the different flavors of Assembler. Now the the tunnel visionaries have set their sites on virtual machine code. Please, guys, stop embarrassing yourselves. Another similar claim is the prediction made almost yearly that UML will replace all computer languages — please!

Relational Databases Are On Their Way Out
I think I've been hearing this one for the past 10 years. The telling part is that those who usually say such things have never had to setup a data store. Relational databases not only reflect the way we think about things, but they also allow us some of the best ways to scale massive amounts of information.

Open Source Software Is Not Fit For The Enterprise
This is one is usually spread by some well-know very ridiculous actors. The interesting part is that one of the most important professions in the world, Civil Engineering, follows pretty much an open source model. Anyone wants to say that Civil Engineering is not fit for the enterprise?

The Bottom Line
Information Technology is supposed to be based on science. Heeding rumors leads many companies to burn large amounts of money on useless pursuits. In the business world the most successful companies make solid IT investments and the losers fumble in this area. Success means not only thinking outside the box, but listening outside the echo chamber as well.

Errata and More Musings On Open Source

In my last posting I pitted open source developers against "commercial software developers." Then, someone pointed out to me that many open source projects are commercial and their developers are no less competitive than the cube dwellers at Adobe or Microsoft. So, I apologize for using such imprecise language.

Back to coding. I don't think I emphasized enough in my last post how much eating of one's own dog food goes on in the open source world.

A shining example is the Apache Foundation. Their product is rock solid because they pound it probably more than their most demanding users — I guess their deal with IBM didn't hurt either, but they were good long before that.

Some proprietary software companies have tentatively gotten some of their developers to go into the trenches and observe their users in a natural setting and/or become users themselves.

No only do I think this is a nice "year on the farm" experience with incalculable returns in social currency, but I think it really makes developers better at what they do. Could it be that civil engineers are so good because they have to drive on their work to get to their offices?

Imagine how much insight you would gain on the quality of your POS software if you were to spend a week operating the checkout machine a local retail outlet. Such an experience is so richly textured and layered it almost defies description, except to say that it benefits all the parties involved.

Sadly, I have seen so many times cases where developers are not only not required to use the products they play a part in developing but they are almost forbidden to do so.

I am afraid we many times hurt our business through too much specialization. Not-my-department-ism is making us myopic and leading us down a path where barely have a theoretical grasp of what our software does.

In my work I have run into applications with very obvious bugs that only emerge during real-world use but are elusive to QA scripts.

Speaking of QA, we need to understand that Quality Assurance is an inexact science. As software becomes more complex and usage scenarios become more varied, the predictive nature of QA scripts becomes all the more lacking in reliability.

Real world testing, eating our own dog food, living off the land, whatever we call it is a necessary part of quality work. We need to use our products as users if we are to develop truly best-of-breed software.

Why You Should Watch Open Source Even If You Don't Care For It

Although most of the software I have written is what could be characterized as proprietary, I have followed many open source projects with interest and have come to admire not just the quality of the code but the process whereby it comes into existence.

Developers whose disdain for open source prevents them from coming into contact with it cheat themselves. This is hardly new knowledge; however, my deductions and learning from open source &0151; in as much as they reflect my unique circumstances and propinquities— may prove useful to you, so I invite you to read on.

Refactoring
People who write commercial software, even those who are the staunchest advocates of refactoring, do not give refactoring its dues. Even in the most refactoring-friendly shops, this is done as a one-off process and never acknowledged as benefitting more than the project at hand.

In the open source world however, refactoring is given more attention because, to paraphrase the famous saying, refactoring anywhere is boost to good code everywhere. My favorite example is how the Linux kernel code has been systematically rewritten even when, as a product, it has consistently outperformed its nearest competitor for a very long time.

So, why do open source developers refactor more? DaVinci-like artistic pride in their work (which is always open for the world to examine) is a prima facie motive.

However, I think there is also a realization among these developers that by improving on earlier work, they improve on their skills as developers and hence their chances of writing better code in the future.

This, I think is a philosophical stance that any development team would profit from. Granted that there are release cycles and deadlines to satisfy, developers can still plan for refactoring. This might be achieved by regularizing schedules and avoiding, in as much as possible, the extremes that make developers go from consecutive all-nighters around release date to WOW-ridden time-killing days.

I know overtime and comp time are sometimes inevitable, but they should be the exception to the rule. A good project manager or head developer should plan for professional development during bench time with as much care as he/she would budget project-earmarked time. Under such circumstances, enhanced refactoring can be worked in quite easily. Google's 20%-time rule is perhaps the most creative way to achieve this.

Code Review
In the commercial software world the very phrase code review has almost the same connotation as administrative leave except that the latter is less tedious. This is very unfortunate especially since it hurts quality and promotes more bugs than any other practice I can imagine.

Agile shops have helped to remove some of the stigma associated with the phrase, but it is the open source world that has led the way. Open source developers welcome code review the way painters prepare to display their work in a swanky gallery. Why is this?


After monitoring discussion threads for couple open source projects, I have to come to realize that the reason for this confidence might stem from the following factors I've observed :

1. bad code and its correction is viewed as a learning experience for all as opposed to an embarrassment to the originator


2. there is no shame in needing correction and a developer whose code was corrected is still allowed to or encouraged to correct the code of others if necessary


3. 
   there is a pervasive sense of ownership in and responsibility for "the application" as opposed to one's piece alone
   


4. open source developers use their continuous code-review process as a means to collaborate — not recriminate

QA and Testing

Sometimes, inevitably so, despite the best efforts to separate testers from developers, there is pressure on the QA team to certify software too quickly. Understandably, this pressure to ship or release by a certain date is due to the fact that delays cost money.

However, a better practice would be to prioritize QA reports and provide graded certifications so that a product can still ship on time with an assurance given to customers that there will be reasonable number of updates included with the original price of the software product. Besides, updates and downloadable patches are quite inexpensive to provide over the Internet.

One reason many open source products have far fewer bugs than their commercial counterparts is that, in the open source world, bugs are sought feverishly and expected as part of the process. In the commercial world, however, I am afraid bugs are seen as nuisances and departures from "the original plan."

This transparency might seem self-defeating on the surface, imagine how devastating it would be if a disgruntled ex-employee were to leak the truth to the press!

Before anyone mentions Windows Vista, let me hasten to say that I do not condone the release of incomplete products to paying customers. Buyers have a right to expect a certain finish and polish to commercial software products, but they might be more likely to accept certain limitations with the understanding that there are a few minor fixes pending — remember the "we owe" sheet you had to sign at closing when you bought your last home?

Division of Labor
Project managers for both commercial and open source software projects subscribe to the principle of labor division. However, open source projects seem to benefit more from its application. Why is this?

It appears that open source projects are a lot more flexible in how they are structured. In other words, people are willing to drop previously assigned action items and take on new ones as circumstances dictate. Egos seem to be less hypersensitive and players are more flexible.

The reason commercial shops are so inflexible has less to do with IT that with HR. It is a shameful display of incompetence on the part of IT managers that they have not realized that HR titles don't always fit an individual's true capabilities or the specific needs of a project. I would be more forgiving of IT managers if there weren't other fields in which the same issue is handled in a much better way.

In the movie industry, for example, the director may play parts in a scene which, in turn, might be directed by another person. The finished movie is more important than nominal titles and no one feels cheated by such practical reassignments. Likewise, in the software industry, we need to be able to reorganize a team as many times and in as many ways as we need to create a truly best-of-breed product — titles be damned!


Bottom Line
Regardless of whether you see open source as the enemy or as a complement to commercial software, you stand to gain from learning the secrets to the success of projects that have bested competing teams with a lot more resources. These are true code gladiators whose work bears some examining.

I encourage all developers to look at some of the code out there. Every SourceForge project has a link to the code; and the home pages of the projects listed may have links to their respective discussion boards. Failing that, a Google search or the Wikipedia entry for the application in question will do the trick.

Code on!

Geothermal Heating/Cooling

Geothermal heating/cooling systems use the earth as a heat exchanger and thereby provides better climate control at a reduced cost.

It is clear that such systems cost less to upkeep and appear to be less prone to failure that traditional climate control. However, the cost of acquisition is steep and these systems do not work in all geographic regions. Yet, these systems are worth looking at it would be well worth it if builders familiarized themselves with them.

I am however uncomfortable with a trend that has become increasingly prevalent among proponents of "green technologies." They tend to factor in Government subsidies or tax credits into the economics of their justification. This approach, while tempting, is a little like bribing your son to take his sister's best friend to the prom. The bribe invalidates all other value propositions and makes suspect the subject of promotion, be it a plain-looking prom date or a "green technology."

No matter the cost, any worthwhile technology will have first adopters. If it proves itself its use spreads and its cost goes down; this is how the market has always worked. Remember how PCs spread despite there being not subsidy or tax break for them form most of their history? Did Bluetooth or USB require subsidies to spread?

The Year of Living Digitally

2009 being the year of the digital transition, I think this might be a good time to pick a few bones with companies (mostly media firms) whose corporate culture has not kept up with the times.

HBO

HBO's issue with the 16x9 aspect ratio bothers me to no end. It's hard to imagine that America's premium cable network sends out a signal designed for people who bought their television sets before the turn of the millennium. What kind of preview monitors do these people use?

Anyone who tries to watch the HBO HD feed is in for a very amateurish viewing experience. Not only does HBO not know how to transition from programs or spots with a 4x3 aspect ratio, they seem unable to produce HD spots for HD shows.

As a result, instead of enticing me to watch whatever show they are trying to promote, I am infuriated by the ridiculous letter-boxed, pillar-boxed, jagged-edged, sub-par image displayed in the middle of a huge black background. Its a crying shame that HBO's promotional department seems unable to produce video whose quality is worse than what a teenage geek can produce in his/her parents' basement.

Maybe HBO should send their producers to intern at ESPN. They have done an excellent job with transitioning from the 4x3 to the 16x9 aspect ratio and output a consistent, high-quality HD signal.


History Channel, CNN, Fox News, and others

These other networks deserve calling out simply because they give HD and/or the 16x9 aspect ratio a bad name. The last time I checked, Fox News appears to have an issue with providing any HD or 16x9 aspect ratio programming.

CNN and the History Channel, on the other hand, think that it is okay to stretch their 4x3 images to fake 19x9 HD video. Let me begin by saying, there is nothing wrong with pillar-boxing provided it is done right. In fact, these services could use the extra screen real estate for crawlers and even ads. Whatever they do, they should stop presenting distorted video — this used to be a sign of a broken TV set.

All these cable outlets need to realize that a significant chunk of their audience is watching their signal on newly bought HD screens with a 16x9 aspect ratio and that nobody wants to watch a crappy signal after forking out large sums of money for the experience.

I doubt I am alone in my practice of reserving my 60-inch HD screen for only material that justifies the viewing experience. As a result, my viewership of these networks has decreased not in small part due to how jarring their images appear on a high quality screen.

Why The Digital Transition Must Not Be Delayed

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."