The Clean Coder : Estimation


Developers have to estimate the amount of time required to complete their features. This is at the same time a simple and a frightening task because the business depends on them. There is no ultimate way to make correct estimation every time but it is possible to aim for a good evaluation.

But first, what is an estimate in the software development environment ?

In some cases it is a commitment, you must achieve it ! You have to be absolutely certain (100%) to commit yourself into a deadline. Other people will make plan based on your commitments so you definitely don’t want to miss them. Otherwise you will look as a dishonest person and you are doing harm (see Professionalism chapter).

In other cases an estimate is… an estimate ! It is a guess, you do not promise anything and you do not commit yourself. If you already had to quantify the time a development task will take you certainly know how difficult it is. Most of the time there are too many variables in play to make a proper estimation. And most of all an estimate is not a number, it is a probability distribution ! The concept is explains with the following figure (fig. 1).

Probability distribution example
Probability distribution example (fig. 1)

In this example the task has 50% chance to take 3 days but it can also take 4-5 days or even 10 days (the Murphy’s law is never far away). With a distribution the business has data to rely on for their work and the development team does not have an inconsistent deadline. It is also important not to commit yourself without willing to do, especially if you use the verb “try” (see chapter 2).

Program Evaluation and Review Technique (PERT) offers an effective way to convert estimates into probability distributions suitable for the business team and for the managers. When estimating a task 3 numbers must be provided, it is a trivariate analysis :

O : Optimistic Estimate. Everything goes as planned, nothing as come into the way. In the chart example, O = 2.

N : Nominal Estimate. The value with the highest probability, in our example, N = 3.

P : Pessimistic Estimate. Everything goes wrong, very low percentage of chance to append. P = 10.

With these 3 values it’s possible to describe the probability distribution of the task with the following formula :

µ = (O + 4N + P) / 6

µ (mu) gives us the expected duration of the task. For the example this value is equal to 4 days. But this is just an average based on some coefficients and cannot be used as a deadline, it is a hint. Moreover the pessimistic estimate high value increase this average.

σ = (P – O) / 6

In this second formula, σ (sigma) represents the standard deviation of the task. It is a measure to specify how uncertain the task is, it is equal to 1.33 days with our sample data. The higher this value is the higher the risk is.

With the PERT technique the estimate for the task is the combination of the two values : 4 | 1.33. You cannot take one without the other.

Agile methodologies have given us several techniques to estimate tasks within a small development team. You can try a method called Wideband Delphi for example or the Planning poker approach or even the Affinity Estimating technique. All of them are based on agreement to provide meaningful estimates and you can combine them with PERT. To ease the process of estimating it is advisable to transform larger task into several atomic tasks, this way the team can be more accurate.

Professionals developers provide practical estimates, do not make promise they can’t keep and commitments that can’t be meet. An estimate is a probability and not a deadline !

See you next time for Pressure !

The Clean Coder : Time Management


Programmers should spend most of their time writing code for their projects, this is their job. But on a 8 hours work day how much time do you actually spend doing this ? In some organization meetings can take a huge amount of your time and you also have to control the amount of focus you have for the day.

Unless you work alone you certainly have to deal with meetings within your company, especially if your team uses an Agile approach for software development. But be careful not to spend your days in meetings, it can kill your daily productivity.

Attending meetings is important in order to follow the life cycle of your project but you are not required in every one of them. In this case you can politely decline the invitation if your presence is not mandatory. It’s no better to be present and play with your smart-phone because you’re bored or because you’re not involved.

There are also some cases where you can leave a meeting. I know it might look rude to do so but it can happen that a meeting goes not as planned and take much more time that you have anticipated. In a situation like this you can politely ask if your presence is still needed and negotiate your exit. There is nothing worst than a meeting without an agenda and/or without a goal, there is no better way to waste time and energy.

If you use an Agile methodology such as Scrum at work you certainly have to do stand-up meetings every day (mostly at the beginning of the day). Each member of the team should answer the 3 following questions :

  1. What did I do yesterday ?
  2. What am I going to do today ?
  3. What’s in my way ?

And no more, each person should be able to answer these questions in less than one minute. With this short and simple meeting you can easily know if your project is on track or no.

During an iteration planning meeting a development team select and reject backlog items for the new sprint/iteration. The estimates (our next chapter) should be done for every candidate item and if possible some of the acceptance tests. The chosen tasks should be clear and ready for the development phase (coding) and this meeting aims to allow the team to briefly discuss over the items.

Iteration retrospective meeting are designed to share what went wrong and what went right during the last iteration and to present demos to the clients/business. It should not extend 45 minutes, 20 for the retrospective and 25 for the demos which are prepared in advance.

Uncle Bob defines two truths about meetings, finding the correct mix between them for your team can be challenging :

  1. Meetings are necessary.
  2. Meetings are huge time wasters.


Writing code is an intellectual exercise that requires long periods of concentration and can be exhausting for your mind. But your focus is not infinite and can be depleted, if you are familiar with Role Playing Game (RPG) see this as an empty mana pool. Unfortunately unlike in RPGs you cannot drink a potion to recharge your concentration in a blink but you can refill it.

Sleeping is the best way to replenish your concentration, a good night of sleep (7~8 hours) can give you enough concentration for an entire day. Coffee is the developer’s best friend and can definitely help you regain a small amount of concentration for a short amount of time but don’t let this beverage send your focus in the wrong direction.

It’s also possible to partially recharge your mana batteries by taking breaks during your day, it allows you to de-focus. If the weather permits it you can go out for a walk, have a conversation with a friends, even meditate if you want. You can also practice a physical discipline, it also demands concentration but not intellectual focus : muscle focus. This type of focus can help you increase your mental focus and give you mana. Programming is a creative discipline then exposing yourself to other people’s creativity (books, comics, movies, etc…) is also helpful to boost your own creativity.


When producing code you will sometimes encounter “blind alleys”. It means that the path you’ve taken leads nowhere, in other word your algorithm does not what you want, your solution does not answer your need. It’s impossible to avoid every “blind alleys” but it’s important to realize when you are in one of them to back out.

What you definitely want to avoid are software “marshes”, “bogs” or “swamps”. Unlike “blind alleys” they don’t stop you, there is always a way forward that looks shorter than the way back but that is not. Sticking to a bad software design is a typical example of a swamp, the more you advance the harder it is to advance and at the end you end up with a colossal Technical Debt without noticing it. It kills a team’s productivity and can sometimes kills and entire project/company because maintenance has become overwhelming. If you discover that you are in a situation like this you should definitely turn back before it’s too late.


Clean Coders manage their time and their focus to keep their productivity up and running. They also know how to detect traps and know when it’s time to go back.

See you next time for Estimation !

The Clean Coder : Testing Strategies

Test Pyramid
The test automation pyramid

Professional developers test their application but not only with some unit tests and a few acceptance tests. These are components of a testing strategy.

Your company might have a Quality Assurance (QA) department or quality analysts (QAs) in each development team to track bugs before a release. As programmer our role is to let them find nothing, otherwise it means that in a way we failed somewhere during the development phase. Of course this goal is almost impossible to achieve every time but that is not an excuse for letting bugs slip through the code.

Am I saying that the developers and the QAs relationship is adversarial ? Absolutely not, they are parts of the same team. First, QAs are “specifiers”. It means that they are able to translate business requirements into test cases to let the programmers know how the system should behave (more in chapter Acceptance Testing). Secondly QAs are “characterizers”. They have the discipline to track incorrect behavior and to reproduce them in order to give proper feedback to development team and to the business.

Having a full test automation policy is a feature of professional development teams which is not only composed by unit tests and acceptance tests. The test automation pyramid figure show every test types and their proportion.

Unit tests are written by the programmers for the programmers to ensure that the code is working at the deepest/lowest level. They should execute in milliseconds and target a 100% code coverage (at least 90%).

Component tests are a part of the acceptance tests and check the behavior of individual component. A component encapsulate a specific set of business rules. These kind of tests should be very quick as well because they are decoupled from the other components and should cover about half the system.

Integration tests are required to check the communication between components in order to verify that the “plumbing” has been done correctly. They ensure that the architectural structure of the system is correct. About 20% of the system is covered by integration tests.

System tests are executed at the highest level of the system, from the UI to check the whole application and its construction (load tests are in this category for instance). They check about 10% of the system.

Manual/exploratory tests are done by humans to explore the application for unexpected behaviors. They need the human creativity to hunt possible hidden bugs.

An effective testing strategy is required to develop reliable applications. This comes from the relationship between QAs and programmers and from a solid automated test suite.

See you next time for Time Management !

The Clean Coder : Acceptance Testing

Check ListSoftware craftsman do not only test their code through unit testing they also have to develop an application that meets the requirements defined by the business. Even a well coded, fully tested software can be worthless if it doesn’t have the functionalities wanted by the end users. So, how do you make sure of that ? You do more tests, Acceptance Tests this time ! You write this type of test to validate a User Story. This way you are able to match the functionalities of your application with the desired features. They are formal requirements documents that specify how the system should behave from the business point of view. The audience is the business and the programmers.

For example you might have acceptance tests to check that the login feature is working correctly for each scenario (no input in form, invalid input, correct input etc…).

As acceptance tests are requirements they have to be very specific and written in a language that is understood by the business and by the developers. To do so there are several format to specify the user stories.

“As a <role>, I want <goal/desire> so that <benefit>”

This is a typical user story format. But sometimes it can be too restricted for a proper acceptance test. In that case you can use the Given-When-Then (GWT) pattern especially with the Gherkin language. This Business Readable Domain Specific Language is easy to understand and can be converted to actual tests for the programmers with a tool called Cucumber. If you are working with the Microsoft .NET framework you can use SpecFlow which brings Gherkin and Cucumber into Visual Studio.

Acceptance tests are not unit tests, they allow you to document your software behavior and to match the business requirements. They are proof that the program works technically and functionally.

See you next time for Testing Strategies !

The Clean Coder : Practicing

Martial Arts - KataProfessionals practice their art with exercises to improve their skills. A musicians spend endless hours on their instrument between performances, athletes go to training between games. This is what we expect from professionals and we should expect the exact same behavior from software developers. It can happen that your company will give you some time to sharpen you competences and it is a perfect opportunity to learn new technologies. But what if you don’t receive this extra time ? Do you practice at home ? What are the tools that can help you practice ?

You can go to the Dojo ! A Dojo (“place of the way” in Japanese) is a place where you can gather to practice martial arts such as karate, judo, jujitsu, kendo and much more. And there are also coding Dojos where you can practice Katas (“form” in Japanese). These exercises aim to train your mind and muscle your brain by writing a specific snippet of code repeatedly. You can also practice Katas by pair using TDD, Uncle Bob calls these Waza (“Art and technique”), one is writing the tests and the other the code. There are a few online Dojos allowing you to exercise on Katas :

You can also contribute to open sources project, especially now with GitHub. It features thousands of projects waiting for help in every domain you might like and in every programming language you might consider.

But remember that practicing does not mean that you have to work for your employer you can and you should practice on anything you want to do : it should be fun !

See you next time for “Acceptance Testing” !

The Clean Coder : Test Driven Development

Red Green RefactorI’m sure you have already heard of Test Driven Development or TDD since it has been introduced in the Extreme Programming (XP) methodology in the late 90’s by Kent Beck. This development process relies on a 3 parts cycle : Red – Green – Refactor. You start by writing a unit test that fails (red) because the tested code does not yet exist. After you write the code for your application that makes the test pass (green) and then you can refactor your code to remove code duplication and others code smells.

In “The Clean Coder” Robert Martin defines 3 laws of TDD :

  1. “You are not allowed to write any production code until you have first written a failing unit test.”
  2. “You are not allowed to write more of a unit test than is sufficient to fail – and not compiling is failing.”
  3. “You are not allowed to write more production code that is sufficient to pass the currently failing unit test.”

By following these 3 laws you are locked into a cycle that force you to test every aspect of your code and to fully follow the TDD principles.

Having a full test suite allows you to have the control over the behavior of your application and to avoid any regression after a bug fix or a refactor. The other benefit of having tests is that it provides a detailed documentation for every piece of your program. Each test gives information about the behavior and the expected result of the feature it tests in a given context.

I have to admit that, when writing these lines, I don’t use TDD. Why ? I don’t really have any excuse for not doing it. But I believe in the fact that TDD is a helpful process. I have to practice it in order to absorb it into my everyday development process.

See you next time for Practicing !

The Clean Coder : Coding

codingWe are developers and by definition we code. For some of us it’s just a job, for others it is a hobby, a craft or even an art ! We spend most of our time coding and by “coding” I don’t only mean writing code I also refer to the thinking of code. This is intellectually challenging and an exhausting activity especially when we are solving difficult problems.

You need concentration and focus to achieve the 4 main goals of coding :

  1. Your code must work !
  2. Your code must solve the problem !
  3. Your code must fit well into the existing system ! This refers to the “do not harm the structure” principle covered in the Professionalism blog entry.
  4. Your code must be readable by other programmers ! For more information you can read another Uncle Bob’s book, Clean Code.

You should not work on your code when you are tired or distracted. There is a high probability that you’ll produce waste and you’ll have to redo a huge part of what you’ve already done.

For example you might consider doing a coding night for one of your project. And why not, producing code during all night, especially if you are with some friends looks appealing. But in my own experience it rarely was. I did several coding night with these ideas in mind and it didn’t turn as expected. After 2 am I became completely useless and the code I produced during the night was garbage and the lack of sleep kept me unproductive the day after. Maybe coding nights work for you but it certainly do not for me.

You should also avoid coding when you worry, after an argument for example. Because your mind is not focus on the task you’re working on, it is focus on others issues.

In the book Uncle Bob tell us to avoid The Zone. Being in this state makes you feel highly productive, you are focused and you don’t get stuck. So what can be wrong with that ? This is a tunnel-vision state and you lose some of the big picture elements related to your tasks and then you can make decisions that have to be undone later. I must admit that I’m still figuring this out. I would say that “The Zone” is good for algorithmic work and should be avoided for heuristic work (more information here).

In a noisy work environment, the developer best friend is his headphone and his music. But playing music while coding can shift your concentration toward the song you’re listening instead of your code. I think that depends on the type of music you listen, I personally prefer going for pure music (i.e. no lyrics) or you can try some focus music based on brain waves.

When coding the last thing you want is to be interrupted, your thoughts can vanish and you lose all the thinking you were doing. You should avoid distraction, for instance your can close your email software or at least turning notifications off. You won’t miss anything critical, simply because an email cannot be critical. When something is highly important, people will come at you in person. We cannot rely on email for everything, just imagine sending an email when there is a fire. If you don’t want to be interrupted by others persons you first have to explain them why it is important you stay focused, if they don’t understand they probably will not consider it. And remember that sometimes you are the person that are interrupting others.

What if you are rested, your mind is clear, there is no distraction and the code still won’t come ? Well, this is a perfect time to find a pair-programming partner to solve problems with the power of your combined minds !

There will still be times where you will struggle with your task and you will feel like you just cannot resolve it. When this happens you should walk away and come back later, don’t try to force yourself if you are in a non creative state. You might find the solution of your problem the next morning in the shower or after a break.

Coding is our main activity and we have to understand every angles of it and know how to behave as professionals.

The next chapter will focus on Test Driven Development.