Project lollipop

When a young child goes to see a doctor he or she usually gets a lollipop. This is not something really needed for their health, especially argued by dentists. Lollipops do not increase health. They do not make checkup easier. They simply make the whole process more pleasant for the children.

This is similar in IT projects. Stakeholders spend money on your project right from the start but see no benefit for long time. If you provide lollipop, the process may be a bit more pleasant and you can lower the risk of financing change during the project especially in ramp-up period.

Lollipop is not quick win. Quick wins are also very important and should be part of a project to make success more certain. They deliver “real” business value and help to assure all project participants that the project will deliver value in the long run as well. Stakeholders as well as other participants, typically users. Quick wins are part of the final solution in the long run, just scheduled to be delivered sooner than their logical delivery time would otherwise be. Their early schedule usually costs extra money, but it pays back on the human factor. Sometimes quick win deliveries are altered by time, sometimes they are eliminated totally by the end of the project so it may seem that their development was totally waste. But still: they are used for a period and they deliver significant business values.

Lollipops are different a bit. Lollipop is not something necessary for the goal of the project, for the “real” business. They are some features that some of the stakeholders like. Something like adding an Excell export from some database. Business people like Excell exports like children like lollipop. They do not deliver great business value, however they are cheap. Just like lollipop. And then again, some time they turn out to be of real business value: found money, be happy. (This is not really the case for lollipops.)

When you design your projects, think about the possible lollipops. They may be different for each stakeholder, but it is worth devoting the time to find them. If you did it is less likely when you explain why you overrun the budget or time they angrily ask you: where is the poop?

Advertisement

Should it be readable or should it work?

Should it be readable or should it work?

This question was given to me by a junior programmer from my team a few month ago. The person was asking it aggressive and frustrated because the project was late and there was big pressure from the management to have the software delivered.

The answer, in such a stressful situation is evident: programs should work, otherwise they are just a list of characters or bytes. When adrenaline rushes there are only two choices: hit or run. That is the way our specie survived during the million years of evolution. But after a while, when you calm down you can start thinking. You end up with a working (really working ?) bunch of code. It passed UAT thus you are still alive, not fired and the Spanish inquisition packed their dreadful tools and went back to their offices on the top floor, for a while. The sun shines again, the dark clouds vanished, as for now. But what will come next after just two weeks when the next sprint finishes?

You take a deep breath and start to run again for the next sprint. The “working” code remains without re-factoring the way it is now. We need that code executing and readability comes into place only when you want to modify the code. Code modification is not in the scope for the moment. Delivering the next functionality, however, is. Project manager is swinging the whip above your head and you slowly realize that your code you imagined to be the best ever program on earth degrades to a heap of X (X can be different things based on your current mood, education and language versatility).

Any temporary code is terminal.

When you write a few lines of code to fix a bug and you put there a //TODO this has to be changed later you should know that the probability of the change is very small. The code will remain as it is. In some cases it will be re-factored but that is even worse. Why? Let me explain!

The refactoring is usually done because a developer can not stand the spaghetti macrame the code became and devotes some “free” time to do the re-factoring or re-structuring. This is not a professional approach.

From the technology point of view it can be professional. There are unit tests and functional and integration tests and all the bells and whistles that are needed for a professional refactor. The non professional part is the financing.

If you found free lunch, better do not eat that. You never know why it was free.

It is not professional in the meaning that this is a work done for pure enthusiasm and not for the money. This work is financed by someone, who is not the consumer of the product of the work. Such a situation is never professional. There is no free lunch, and what is more: you better do want to pay for your lunch. That will ensure that you will have the quality lunch today, tomorrow and in the future so long as long you pay for it. You need the lunch, they need the money. The same holds for programming. In other words: you will get what you paid for. Low price: no meat in the soup.

Refactors are like lunches. You better pay for it if you are in the customer shoes. How much to pay? How much refactor you will really need to get the best code you can? Tricky question that is hard to answer.

Sometimes it is more important to have a code that is readable than a code that works.

The key word in this sentence is: sometimes. When the delivery is not in jeopardy. When this is the decision to do it Q&D and go for a beer (or bear if you are the hunter type) or to DIR. (Q&D stands for quick and dirty, DIR is do it right) I also feel the urge to finish something fast though not for rushing for the beer, neither the bear. First running the code I feel like Victor Frankenstein seeing his creature’s first movement. But then, if it works, why mend? I do not want to kill my creature just to have a better looking code. The feeling when I can see bugs appearing that were not present in the ten-minutes-ago ugly code. Yes, it was ugly, but it worked. Why did I started to re-factor it? And then I bang my head against the wall.

But there is a caveat: if the ugly code worked but the refined, good looking code does not, there is a good chance that the old code was faulty as well, just unseen. You just did not realized the bugs were there. Turn on the light and the small feet run to the little holes at the side of the floor. Software bug is not cockroach. If you turn on the light they can be seen. Write unit tests. Write tons of unit tests and spend time thinking how your code could look better. It will pay for it. And the long run: the customer will pay it, and on the other hand customer will also get the value. Then you will not face the question any more Should it be readable or should it work?

So long as long the next project starts…