During the 1990's, Advanced Technology Solutions (ATS) was one of those companies that dabbled in several different buzzword-worthy markets: dial-up Internet service, custom system configuration, web development, to name a few. None of these were complete disasters, mind you, but none could be considered all that successful either.

While this would ordinarily spell disaster for a business, everything continued to stay afloat and chugging along nicely thanks to ATS's CEO Scott Slokum and his ability to raise capital for future projects. Although the source for Scott's capital was always the same — his wealthy elder brother who funded his ventures to keep him out of the family business — the money always came through when needed. As a result, Scott could move the firm as impulse took him, usually based on something he'd read in that week's issue of InfoWeek without much concern for profitability.

This fact played out very well for Jay O. after he was hired to migrate their flagship application (a line of office accounting and record-keeping products) from Access 2.0 to Access 97. Though Jay was hired on originally to create the yet-to-be-designed application's documentation, he figured that could try to lend a hand and gain some very valuable (and marketable) experience along the way. But there was a catch: Jay had never programmed professionally before.

With nothing to lose, Jay gave it a shot and asked Scott for the opportunity. He told him that he didn't have much programming experience outside of the classroom, but that he was eager to learn and had some decent experience with MS Office. That's all that Scott needed to hear: his eyes lit up and he agreed to let Jay have a shot at helping on the new version.

Soon after, Jay was reassigned to work with the lead programmer Dave. Meanwhile, Scott started passing out cigars to customers along with the good news that the new version of the application could be expected a full two months ahead of schedule. All thanks to the new developer rock star that he had just brought in.

The Dave Way

Dave was an old-skool hacker-type from way back. Make no doubt, he was absolutely a fine coder but some of the techniques he relied on for working with Access and a rush-to-git-r-done attitude to get through the project without any planning turned any overall design goals into nothing more than an afterthought.

Fortunately, the internal business logic didn't need a whole lot of change and did not suffer long at Dave's hands. Unfortunately, the user interface did, and Dave's approach was to handle each individual case as it came up, generally with no notice to the other coders assisting him, or even any comments explaining the changes. The resulting code was a thorny thicket of redundant functions which were subsequently copy-and-pasted across the rest of the codebase, each time repeating about 75% of the code of the previous iteration. This meant that any bug fix usually resulted in a half dozen or more ancillary fixes.

To be fair though, this wasn't entirely Dave's fault - while his freewheeling design style certainally didn't help the situation, the choice of Access to drive the data behind the application. The version of Access being used made it difficult to share code between databases and the sins committed by the now long-gone original Access developer made for a host of daily headaches. Some suggestions, like the wild notion re-writing the logic as a DLL in VB, were made to find some way to separate the common code sections and reduce the redundant work, but they were all dismissed as being impractical and costly.

As a result, everyone ended up getting caught up in Dave's bug-fix fever. Soon, everyone, all day long, was putting out fires in all directions. However, as the project loomed closer and finally sailed past the deadline, the CEO soon caught scent of the smoke and demanded that everyone freeze all development immediately and gather for an emergency meeting.

Burn, Baby, BURN!!!

It had been decided that enough was finally enough.

The development team was spending too much time fighting fires when they could have been developing new features. Everybody nodded and agreed with the big boss. The software had turned into crap before their very eyes. However, the nodding stopped abruptly when he threw them all a curve ball.

"As the creators of the software, you are focusing on the minutiae of the application rather than the BIG picture," he began, "We can't spend all of our time on problems which the customers haven't reported yet."

"If there haven't been any bug reports on something, then obviously they don't need it fixed yet! We should be focusing on getting the features ready and not fixing some little feature which the customers don't use."

After a pause, Scott added "Microsoft is always sending out beta versions to users and according to the industry press, they don't do any in-house testing until a complaint is made. Therefore, if we want to play with the big boys then we need to follow their example."

Finally, in his finest Orson Welles impression, Scott exclaimed "WE WILL TEST NO SOFTWARE BEFORE IT SHIPS!"

Upon this revelation, things were so hushed that you could have heard a pin drop. Everyone was just in shock and in awe at what they just heard. In their niche market of software, such a decision would spell certain financial doom! If this plan went through, they could lose their jobs! Was someone going to suddenly appear and shout "Gotcha!", revealing the hidden camera - surely this must have been a joke!

But it wasn't - this was par for the course.

Interestingly though, if Scott's elder brother had been a fly on the wall during the meeting he probably would have just shrugged at this news. No matter the outcome, so long as Scott kept playing like the "big boys", his business's continued stability was assured.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!