Turnkey or Chicken

ThanksgivingNot so long ago, an acquaintance who was seeking a software development job interviewed for a role at a “market leader” in the development, implementation and support of financial services software. During the interview, it was revealed that the position is concentrated around the implementation of an Enterprise scale project for a large government organization. He was told that the implementation will be based on the companies existing flagship product (a SOA based turnkey system of some sort), which will be extended and customized according to client requirements.

Just a few days before the interview, a team of representatives from the same company met with the business executive from the government organization, at their high-rise conference room overlooking the pier. RFP’s and RFQ’s were already out of the way, and so were the product specifications. The company won the tender because they already had a base solution in the form of a customizable product, and the industry-specific expertise to go with it. It was just a matter of signing the dotted line, with fingers crossed.

What my acquaintance, and the large government organization didn’t know was that there was no such flagship product in existence, at-least in a functional form. The whole proposal was a farce, filled with enough fluff to have lasted as a year’s stock of toilet-paper. In a sense of over-estimation the company did have the technical capability to develop the solution from surface, but realistically it was impossible. The fact of the matter is, almost always — things take longer than they seem, and money lasts shorter than you plan.

Fearful, but not rare. This mechanism, how so ever unethical, is not uncommon in the Enterprise landscape. Garbage-disposal giant Waste Management is still embroiled in a $100 million legal battle with SAP over an 18-month installation of its “fake” ERP software. Waste Management claimed SAP executives participated in a fraudulent sales scheme that resulted in the massive failure. What did a $400 million upgrade to Nike’s supply chain get the world-renowned shoe and athletic gear-maker? Well, for starters, $100 million in lost sales, a 20 percent stock dip and a collection of class-action lawsuits.

The problem lies in three broad facets: people, perspective, and process.

People, at all levels in an organization (large or small) need to rationally answer a question: if I were a business owner, would I invest gazillion dollars on bloated software that takes years to implement, then years to fine-tune, by when it doesn’t solve the ever-transforming problems. Perspective, in terms of the scope and scalability of a solution. “We want to build more features than our competitor”, is a very common notion. Keeping the feature-set minimal may sound like a joke to many corporate vendors and business executives. But, minimalism really promotes iterated execution; which eventually saves money, time and efforts. And finally, process — the end-to-end software engineering approach, which I think is a big factor for so many spectacular failures and huge spending nightmares. Software engineering is relatively young, hardly a few decades old. Compare it with dwelling construction, which originated from the era of the cave man, and you’ll probably understand what I mean.

So you overheard from the cubicle next to yours, “it’s not that simple“. Well, that’s right. Complex ideas result in complex software. The bigger an object, the more energy is required to change its direction. In order to finish a project on time and on budget, without reducing the level of quality, we should ideally implement less and iterate more often. Under-do, and you will make successful software that is lean and opinionated.

Sir Charles Antony Richard Hoare (best known for developing Quicksort in 1960) said:

There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Show Comments