Either you are a victim or perpetrator of this phenomenon. So sing along...
There once was a customer,
There was a customer once whom we thought was ignorant of our ways
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.
- 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.
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.