Practical Strategy Consulting

http://www.PracticalStrategyConsulting.com

Copyright © 2006 Christopher Duncan

Feature Creature

by Christopher Duncan

It was a dark and stormy night... Sorry. I'm an old Snoopy fan and just couldn't resist. Actually, the scary stuff in this particular episode happens in broad daylight. Well, broad fluorescent lighting anyway, for those of us who are inhabitants of Cubicle City. Like any good spook story, it all starts out so innocently. A few programmers get together with an idea for the next killer app, pizza is ordered, coffee consumed and before you can shake a pocket protector, version 1.0 is making waves and getting rave reviews in the marketplace. It's lean, it's mean, it performs like an Italian sports car and is as easy to use as a toaster. Better still, unlike fine automobiles driven by rock stars with more money than hand to eye coordination, it never crashes. It is a marvel to behold, and everybody wants a copy.

If we could roll the closing credits at this point it would seem more a fairy tale come true than the horror story we paid to see. Fortunately for all the ticket holders, there are thrills and chills yet to come.

The time is now 5 years after the initial release, an eternity in our time warped little business. The once proud killer app now takes half the hard drive to install, and performs like a beached whale that's consumed one too many Salmon Twinkies. The only thing less stable than the application is the mental balance of the hapless maintenance programmers who work 60 to 70 hour weeks trying to keep up with all the bugs that come in through the overloaded tech support lines. The original architects of the system have long since disappeared, lost to exciting startup ventures founded on the reputation of their initial product or whisked away into high paying consulting jobs and speaking gigs. It takes a minimum of 4 days to get a response from an email to the support department, which is only slightly more aggravating than the one hour average hold time that frustrated users must endure, all the while listening to cheery little prerecorded voices assuring them that their call is important. The company that once ruled their market with pride is now the butt of industry jokes. Stock prices plummet, cutbacks ensue, jobs are lost, and resumes are besmirched with a job history containing the name of a product now synonymous with disaster. At this point the only thing missing is a ten story tall fire breathing lizard munching on a subway train. For those whose investments or careers have just been vaporized, the lizard might be easier to deal with.

Regrettably, the story just told isn't science fiction. Even worse, it is not only reality, but the norm in the software development industry. For every crime, there must be a culprit. That is, if a suitable scapegoat can't be found. So who do we hold accountable for this mess? Leaning casually against the wall, stylishly dressed in his thousand dollar suit and designer shades, our monster almost blends into the scenery so familiar has he become. Before he fades quietly into the background (or slips out for a three martini lunch), allow me to introduce you to our leading man. Ladies and gentlemen, meet Feature Bloat.

As anyone who's been in the software business for more than 45 minutes will tell you, no product that meets with even marginal success ever stops at version 1.0. In fact, I've seen quite a few programs that should have met with an accident involving a bulk eraser out by the back dumpster that have gone on to much higher version numbers. Still, why should we stop with 1.0? To a point, a good idea can always be improved upon and everyone can benefit. Consumers get a better product, developers get another paycheck. Developers like that sort of thing. However, this cycle can, and typically does, get out of hand. While the end result may not sport green scales or have an affinity for New York City mass transportation vehicles as an after dinner snack, it will eventually grow to a problem of, dare I say, monstrous proportions.

There are many difficulties inherent in enhancing an application. You may be more familiar with some of them than you care for. Before you can add a new feature to an existing code base, it's helpful to have a firm grasp of the product architecture so that you can realize the implications of any changes that you make. As we all know too well, an innocent little line of code in one module may wreak havoc throughout the rest of the system. Unfortunately, technical documentation is almost always inadequate if in fact it ever existed in the first place. If you're lucky enough to work in a shop with a good design discipline, you may have the original design docs available for review. However, even in this case, such documentation is frequently out of date, often to the point of being either useless or dangerous. The most common reason for this scenario is due to deadlines that dismiss any work beyond coding as unimportant and leave no time in the schedule for it. As work on the new system proceeds, problems will be encountered, workarounds discovered, and many, many lines of code will change or appear in the final working version that were never accounted for in the original design. After all, the mandate is to make it work, so we do what we have to do to make it happen. At the end of the day, however, after the elation of getting the new system to market (or physical and mental breakdown, depending on how this particular release went), work almost invariably proceeds on either known bug fixes or new features.

I'll spare you the obvious tirade on the concept of shipping a product with known bugs. If management knows that there are bugs, then why would these bozos let the product ship? Oops. Sorry, that one's just too obvious to ignore. In any event, development work proceeds immediately after a release, and that almost always means coding. It's a rare programmer who pops his head up and says, "Gee, shouldn't we take a little time first and get our technical documentation in line with the actual code base?" In addition to the fact that his peers will most likely throw him down a very long flight of unpadded stairs after the meeting (programmers are temperamental creatures who hate writing documentation), management will do nothing more than snort and make a mental note to give a bad performance review to this troublemaker who is obviously not a team player. Consequently, we'll observe a moment of silence for the next poor sucker that gets hired to do maintenance programming. Without adequate technical documentation, you may as well give him that bulk eraser. It will do the system about as much good as the code he's going to write having no hope of fully appreciating the impact of his changes. Furthermore, as a product matures, the code base grows ever larger and more complex, which only serves to amplify the problem. But hey, that's okay, we'll just ship with a list of known bugs and that'll make it okay, right? Wait, are those scales I see sprouting up?

So, right off the bat we're in trouble. Software products evolve, companies want to keep making money by selling upgrades, and we programmers certainly want to keep our jobs. Well, most days we do, anyway. Nonetheless, doing nothing more than enhancing the system without proper maintenance of technical documentation almost assures us that with each new release our system will become bigger, fatter and most distressingly, more unstable.

There is an even larger, though related, issue that lurks on the horizon of every software system on the market. No one ever seems to know when to say "enough". Programs, particularly the flagship product for a company, will continue to be enhanced until the company goes out of business. As we've seen, that day might well be accelerated by such unwise decisions. For some reason, there's a prevailing belief, at least in the marketing departments and executive boardrooms, that you can always add more features, more bells and more whistles to a program for as long as you like. All you have to do is tell the programmers what you want, they type some code, and it happens.

Nothing could be further from the truth, and the end result of this insipid line of reasoning is a market full of huge, slow and buggy software. There is a point of diminishing returns beyond which you are no longer enhancing but are instead damaging your software product. While I do understand that theoretically it is possible to continue adding code to a system forever, or at least until you exhaust system resources, we do not make our living in the theoretical world. We live in the real world and in this reality what we build, no matter how good we are, is a structure with weight limitations. One straw too many and it all collapses. Every time.

This poses a bit of a dilemma, for keeping our focus on the real world is a double edged sword. That second edge is money. Maybe there's a lot of altruistic folks out there who code purely for the joy of doing so with no concern for monetary compensations. I ain't one of them. I love programming passionately, but this is my livelihood and I don't work for free.

Fortunately, there is another choice but it requires both foresight and backbone on the part of the programmer community. Foresight comes into play in your initial design. Knowing that there will always be new functionality to add, design this into your system. Build hooks and programmatic interfaces that will allow you to develop a suite of complementary products, all of which can interact with each other. There are numerous methods of interprocess communications available in Windows. Rather than letting the flagship product become a huge, monolithic monster, think in terms of a fleet of complementary applications. When Marketing wants new features, rather than wedging them into a large and undocumented code base, spin off a new application. A fleet of well coordinated programs will sink a bloated Titanic any day of the week.

Here's where the backbone comes in. You're good enough to make this happen technically. That's never the problem. Like any other change to the status quo, you're going to have to fight for this idea and it's not going to be pretty. However, you probably don't realize how much power a united development team actually has when confronting management. It's much more than you may think. If they fire all of you, who's going to write the code? Them? Not likely. New hires? Good luck figuring out the system. Granted, you can't succeed based on strong arm tactics alone, and rightfully so. You have to sell the idea of a fleet of smaller, faster, tighter applications to management based on the merits. It's certainly easy enough to find examples in the market of where your product will end up if you keep stuffing enhancements into your flagship forever.

We need to change the defacto standards that exist for typical desktop applications away from the model of a single, continually enhanced program. The best way to do that is with success stories. Any time a new product hits the market and does well, everyone else follows suit and copies that model. The benefits of a software fleet will not be obvious to everyone initially. However, when your competitors are on version 4.0 and sprouting large green scales, your product will simply have added a few new ships and all will be running fast and tight. Even the flagship.

So why should we care about such things enough to risk life, limb and income to change them? Hey, who do you think has to clean up after the monster?