"DONE" - Thoughts on Software Estimation

When developers are asked to estimate the effort & time required for a change request, or fixing a bug, they give some numbers. And starts working on it and says its done. But actually there is more to do in it.

For example:
-------------
1. It should be tested, integrated, and pass the QA
2. The code also needs to be reviewed & refactored (if the developer/company does't follow this practice as part of their regular development)
3. Finally it should be accepted by the customers

But developers don't consider all of these and gives estimates. But the Parkinson's Law applies and the project automatically pulls the effort and time actual required from the developers.

I usually tell the developers that you have the right to give the actual time required for it. Need to shrink and give false estimates which are less. Take all of those into consideration and tell the time required for it.

Let me give an example of what DONE means. If we want to buy an Air-conditioner for our bed room, when we are done? We are done only when cool air is flowing out of the A/c and our room is getting cool.
To complete the above task, we need to take all of the following steps into consideration for estimating the cost and time required.

1. Search (online or visit a nearest store) for the needed capacity, model, brand, of the affordable budget, quality, service availability etc.
2. Go and place and order for it.
3. Get it transported to our house.
4. Get the required electrical wiring & man-power to do it.
5. Actually mount the A/c and connecting it the mains.
6. Finally the A/c need to be tested and accepted/approved and we then pay the bills

There could be few more or less steps involved in getting the room cool then only we can say it is DONE.

Write less code to produce less bugs

I often see the developers write more code which leads to more bugs. My previous post was regarding a code-smell in that I talked about unnecessary lines of code fed into the logic even it is not necessary. Those lines of code and steps were brought as part of building the initial algorithm/logic to make it work. But fail to remove/compact it by refactoring.

This leads to more code to be maintained and leads to creep more bugs. The principle is writing less code hence it will have less bugs. Writing more code, producing more bugs and spending more time in fixing them over and over are a bad practice.

Every method in the class, and every line in the method should have a strong reason to exist in there and should scream for its existence. -- You get the point.

So write less code, keep it short, simple, and produce & fix less bugs, save time!

On Giving Intention Revealing Names

As I see and reviewing more code (Written by an amateur programmer to very senior developer) I noticed why they cannot come up with good names even though they are willing to do so and be able to spend little time and effort too.

They are two things:

1. They are not well-versed with the domain terms and vocabulary. They spend very little time on understanding it. They very soon bring the technical jargon in to their mind and starts thinking in implementing with it. In the initial phase of the project where the business requirements are discussed, they spend very less time in those discussions and starts thinking about tools and technologies can be used.

They eventually jump into the development and use the names of whatever at the time they know. Latter even if they become aware of the full business domain terms they don't really dare to touch the code and change the names. Then they forget it or ignore it and come under schedule pressure to add more code.

2. In some countries (e.g. India), English is taught as second or third language. Even somebody study in full English-medium still it is seldom used in day-to-day conversation and communication. They study it just for passing the exams. The problem is again with the strong vocabulary hence it becomes very hard to come up with good names very fast or immediately while they are programming.

They don't spend time in thinking for good, short, straight-forward, condensed names and they use whatever words they know and abbreviate the names by prefixing and suffixing with numbers, or omitting vowel (e.g. for customer to cstmr).  They make lot of spelling mistakes also.