Testing is for Supper

Testing is for Supper.

What does it mean? Well, most books state, although this is theoretical and not very precise, that in order to complete an  average project there is 10% Requirements, 25% Design, 40% Development, 20% Test, 5% Deployment. A third chunk of the pie is analyzing, creating a design and documenting. That is the breakfast. The most important meal of your life. Without breakfast, where will your rest of your energy come from? More than a third chunk of the pie is development. Notice that development is almost the same time you create those designs. And last but not least, a quarter of the pie goes to testing and deploying your source code to live production.

Okay, so we got the gist of that. They have been written in books for a reason. To be followed. I have seen so many upper management broken this rule several times due to impatience and are only result oriented. The same drive where the big bubble in 2000 happened due to the people orientation of only short term than long term pursuits, it still exists today keeping many companies stagnant and frozen without being able to move up the ladder. It is more like they see an illusion they are moving up with the ladder but in reality all they do is running circles because they cannot think the long term value of the company.

The first thing that surprises me a lot is the amount of testing that have been done. Many managers think testing on projects that require maintenance should take more than 50% of the time (So how much really? Around 70-80% of the time). That will only happen if the previous parts failed horribly. What I like about Americans is how fool they are always. If it works, we say just patch it, instead of fixing the source of the issue. Why would we not fix the main issue? The reason is simple. It would take a lot amount of time. Nobody can stand up with time. So if a patch is 10 times faster than fixing the main issue, who cannot be tempted to get the same results for 90% the price off? Little do they know they will have to do 50 fix patches in the next 10 years that they will never notice. The return of investment for a fixing the main issue is 5 times cheaper, yet people prefer to pay interest 5 times the original for faster results, because for now it almost feels like they are almost getting it for free. It is so tempting like a slice of ice cream chocolate cake if you have ever eaten one. Doing this once in a while is fine or if you have many resources then its not an issue either. But for middle companies or companies that do often, that is definitely a red flag.

Okay, so let us go in more detail to this.

How do testing become 70-80%?

They do Design 1-5%. Seriously, some can even have 0-1%.
Then since the design is so simple, the implementation is so easy. Design does not have case scenarios of what else could go wrong if this code is added. Design does not have literally all the info the client wants because it was not looked thoroughly. Since the design is not so complicated and not full comprehensive, it is hard to check if your code really works to say in fact it is implemented well. So then the time it takes to implement is very fast , let us say 15%. Then testing comes and it becomes 70-80% because of the poor design.

Now a proper project will be like this.

They do Design 25-30%. It is full comprehensive and all or most of the scenarios are pin pointed out. Note that the design can come in any other phases of the development life cycle, such as implementation , especially in the alignment of the implementation with the design requirements. New requirements can come from it and more time allocated to design and implementation will be required. After design is complete, you have 40% implementation. Sometimes it can be 50% if the requirements are too long or 30% if the requirements are small. In any case, within the implementation you also do code review with the requirements. For some people, they call this "testing", but in fact is still implementation. There is a practice that many do not follow the code review and only implement without looking the requirements, which can create the opportunity of fixing bugs and issues and a more robust and comprehensive implemented design. If they trim that part within the implementation and make the implementation be 15-20%, then of course testing will be 40% but not likely numbers large as 70%. If all is done correctly, testing will be 20%. When is testing done? Testing is done only when you have a fresh mind, a fresh perspective. You cannot on the same day fix issues of your program you are too familiar and attached that you cannot be objective with it. Testing comes when a user finds an issue that does not require new features to be added. That will be your 2nd or 3rd revision of your code and you will spend 20% of your time fixing those bugs and making your code more comprehensible and clean. Some people think that immediately after implementation, there is testing. For me, I cannot think testing can be done without a pair of fresh eyes. For testing to be the most productive, it should bring results. As long there is not a lot of bugs in your program, it is okay to fix only the issues the user finds and do some special revisions as long it takes 20% of the time of your overall project. If it starts to take more than 20% of your time, it is time to redesign and restructure your program with a better design. Do not worry about it if that takes a long of time unless you think that the issue you just fixed will not come up again next time.

So what bad is it if 70-80% of the time is testing? The reason is simple. Many say it is 70-80% of the time. But most people say it takes forever. If it is forever, how much time is it compared to developing a normal project with proper design , implementation and testing? I assure you it will be 5 times less over the span of 10 years. It is very hard to notice for managers that have low temper and get tempted to instant gratification of results. If projects are of small scale then this will not be problem. Usually though, most projects have been of big scale, either because bartering with clients and customers are not done correctly, creating a surplus of requirements that may not be need it, or in fact the project is of big scale and its structure cannot be simplified without documenting and design and breaking it up in small pieces. Many people are in denial of their project of being in big scale and have wrong expectations.

Good managers for projects
-Will be very good at negotiating with clients about what the real requirements are and able to articulate them well. They will focus more about bringing more long term results to the customer than just short term satisfaction. Their priority will be more about the life of the program instead of how much they can monetize through its current assets.
-Will gain satisfaction from the long term effects from the company than the short term effects from the company. Will require patience, low temper and be able to have the vision and insight to act in the manner of scolding for people who bring short term results that are positive, but negative in the long term and praising the long term results that are positive, but can be negative in the short term.

So design is for breakfast, Implementation is for lunch, Testing is for supper.

Agile Development, Waterfall development, and other development methods, yes, they all have some differences. But in the end, they all are the same, just done in different amounts, done either simultaneously or linear, but the proportion ratio of each phase usually does not change by much.