Executives - Rush to Code: A graveyard for software project failures

Some traditional line managers new to software development projects feel that the yard stick for project progress is how much of the code is being written.  Nothing can be farther from truth.  Code development itself is just one of the many facets of the software project managers responsibility.  Ignoring this fact and simply rushing to churn out lines of code is a sure fire way for disaster, since all the upstream steps that are required before coding ever begins would have been compromised.  Executive awareness is the key in managing software project development.


Either you are a victim or perpetrator of this phenomenon.  So sing along...



There once was a customer,
an ignoramus we thought

He needed a piece of code,
and that's all we got

Ye'all march onwards
said the executives that could be

We got on the bandwagon
with many faces and phases

Requirements and Design,
went in the passing

Coding, oh! said they
Do start in a jiffy

We wrote and wrote
the code, that is

Test we can't
for neither a man nor a machine ready

We ain't finished
And the demo is on

The client comes and goes
the demo but start not

After all, built we to
the requirements, you see

Requirements and Design,
We left them but where?

Remember not who and when
consulted them the last

Package and try
dare deliver the piece

Beat the deadlines!
Lest our customer sue

If not for IT,
This tale you would know not!

There was a customer once whom we thought was ignorant of our ways

He needed some software and so hired us

Our executives gave us the go ahead to start the project work

We hired new people (faces) and split the project work into many phases

In our rush to finish the work, Requirements and Design phase just went by

Because everyone was so focused on the coding, as if that was everything.

Coding is only an end product of Design, no matter how much we wrote

Testing should have been done on the written code, but was constrained by lack of man and machine

Even before we were done, the demo for the client was arranged

Murphy’s law went into effect – things go wrong when you least want them to

Of course, we justified that everything was built to the clients requirements

Conveniently forgetting that nobody had kept Requirements and Design up to date

Sadly we do not even know where to find them  on the project

In any case, we need to deliver this piece of code before the deadline, or else the client may sue us (for failure, what else?)

Unfortunately, this is how some IT projects are done and now you know why these run into great challenges!



The IT industry is fairly new, a few decades at best.  In developing countries such as India, the IT revolution started only during the dot-com and Y2K era.

Being a fairly young industry, we surmise that the old age executive management may or may not be tooled in the nitty gritty of software and its development.  Being the first generation executives heading IT firms, we caution a few pitfalls that executives may have to pay attention towards.

The difficulty in understanding software and its development for anyone who has not had their feet wet (growing up in IT) is the following characteristics:

  • It is highly knowledge based and hence very intangible.  What is visible is only the tip of the iceberg.  For example, any website has a lot more going on behind it than the few web pages the user may get to interact with.  For the work done, the visible to the invisible ratio is very high.
  • It is necessarily a trial and error process.  Unless testing is done thoroughly, there is no guarantee the software works as intended.  Why?  Consider the fact that there is no such thing as an 100% completely tested software!  It is virtually impossible.  The write-test-fix cycle continues until we get it right
  • It requires a highly skilled and motivated work force that is capable of devising solutions and bringing the engineering skills to the fore

In traditional industries, such as construction, engineering or manufacturing, there is a great deal of visibility on the ground for the executives, who get a comfort feeling of what really is happening vis-à-vis their project plans.  To the executives, it is far easier to judge how much of the building construction has taken place (more tangible) than to figure out how much of the software has been completed (somewhat intangible).

As we already discussed, this is primarily due to the high tangible to intangible ratio.  This makes even a seasoned executive feel like a fish out of water, what then for a traditional executive who has moved into the modern IT industry?

To them the tangible represents the comfort factors that they can measure, even if informally though.  It is comforting to them to count the number of web pages on a website.  At the same time, the number of lines of code may not truly represent how much work has been done, considering the fact that without testing, the code is no more than spaghetti.

To rephrase:

  • The tangible to intangible ratio is very high
  • The tangible represents just the tip of the iceberg (such as webpage on a website)

So what represents the intangibles?  This is where the traditional executives need to focus the most, because these drive the tangibles and not the other way around.

Let’s list a few of them.

  • The needs of the customer.  Other than a (tangible) requirements document, everything else in that is just the intangible needs of the customer.  This requires further processing, and that is what usually follows next
  • The analysis and design of the customers’ need takes up the next big chunk of effort.  The (tangible) design document provides a basis for building the intangible into the tangible

These steps are where the most effort typically needs to go in.  Any rushing through these steps will only compound the penalty that has to be paid later.  This is due to the cost of change curve, which becomes steeper as the project time passes.

The next step is the coding and testing of the code.  This is where typically the executives start getting a comfort in the form of created code.

And no wonder why some executives feel the need to rush to coding.  Disregarding the previous steps is a sure recipe for disaster on the project, since the question that begs an answer is – what is the code being written for if the requirements and design haven’t been studied thoroughly?

It is imperative for these go-code executives to understand that:

  • Coding and Testing is the mundane work that needs to be done after the design is completed to a logical level.  There isn’t much creativity once the design has laid out the road map to the solution, isn’t it?
  • Laying the correct roadmap as per the clients needs (both stated and implied) is the hardest job of creation!  This is what is captured in the requirements and design artifacts.  Due amount of time, effort and the best brains have to be necessarily engaged in this phase of the project

As the saying goes, pay now or pay much later, this is much more applicable in the knowledge based industry such as software development.

As for the go-code executives, we suggest Agile development methods, so that they may get to see tangible work in much shorter time intervals.


Why is Requirements and Design very important?

Requirements are mostly elicited from the clients.

  • These may contain the stated and implied needs
  • When completely satisfied, provides value to them and their goals for which the work is undertaken
  • Highly unlikely that any two customers will have the exact same requirements
  • Changes to requirements initially are less costly than later when the project is already off the ground.

The design of a system has the following characteristics

  • Solely depends on the requirements and hence unique for each project
  • There may be many ways to design a solution
  • It is highly unlikely that any two designs turn up the same
  • Designing is more of an art first, then follows the engineering aspects
  • A given requirement can have more than one solution (or design)
  • If the design is not thorough as far as possible, the downstream effects can be enormous, increasing cost and potentially destroying the project
  • Even though design patterns and templates exist, each design is unique by itself
  • Needs lots of experience and technical knowledge


Why is Coding and Testing more of a routine job?

The creative aspects of the solution are mostly captured in the design itself.


  • Is mostly converting the design as-is into a machine understandable format.  No wonder there are automatic code generators (given the design) in some application areas
  • Lots of help is available over the internet.  For example, try searching for a C# code for bubble sort.
  • Is mostly mundane and may require some amount of creativity
  • The existing knowledge base takes the burden off of the coder due to the readily available algorithms and code snippets
  • Can be reviewed with the help of others and the work verified to fix issues early on


  • Needs creativity to the extent of ensuring how to break the code base
  • Is specific to the particular project
  • The creative aspects are limited to the creation of test plans and test cases
  • The test implementation itself is mostly highly repetitive in nature, and hence an ideal candidate for automation



Traditional industry executives who have moved to the software domain need to possess a different mindset while working in the knowledge based industry.

Given the understanding that most all projects are driven by deadlines, it is imperative that the following points are strongly considered.

  • Sufficient upfront planning effort has to be necessarily spent to prevent issues from occurring later on
  • Due amount of consideration needs to be provided for the early phases such as Requirements and Design.  These need highly skilled and motivated work force, since every projects solution is unique and any errors here can have disastrous effect later
  • Coding, though important, comes only after the design is complete and frozen (as far as possible).   This task is essentially a job of converting the design solution into machine understandable format.  In some cases, automatic code generators are already available.  Hence due caution is advised before rushing into this activity.

The maxim, pay now or pay many times later is highly applicable in the software industry.  Rushing to code will almost always result in paying many times later (in the form of change-redesign-code-test cycle).  Consequently the cost curve ensures that changes at later stages are so prohibitively expensive as to impact the projects overall success itself.


Post Script:

Having been familiar with writing code (over 35K lines of C++) on a major project with poor design, I painfully realized much later that the project was going nowhere.  Today, I constantly hear from many project managers about how they are rushed into coding only to fall into the code vortex, which sucks in everything from then on.  It is better not to be anywhere near the vortex, much less in the middle of it.  The consequences for the project are not good.

Login to post comments
Go to top