The pupil asked the master programmer:

    “When can I stop writing tests?”

The master answered:

    “When you stop writing code.”

The pupil asked:

    “When do I stop writing code?”

The master answered:

    “When you become a manager.”

The pupil trembled and asked:

    “When do I become a manager?”

The master answered:

    “When you stop writing tests.”

The pupil rushed to write some tests.

If the code deserves to be written, it deserves to have tests.

More great zen testing lessons can be found in The Way of Testivus by Alberto Savoia

Scott Belware is currently pondering what tomorrow’s Agile methodologies will be. A good and noble question indeed, but at this point in time I feel this question can be misleading. If the old (Waterfall) is in the East and the new (Agile) is in the West, does tomorrow’s Agile methods lie further West or more towards the East? I will try to be more clear, and here is where football comes to play.

The NFL adopted instant replay in 1999. Referees could now replay what had occurred and it was viewed as a great evolution to the game. Unfortunately, referees became much more dependent on the technology. Games became longer. Players and fans didn’t appreciate the long waits between plays. People started to hate instant replay.

In 2004, the NFL got wise and realized that a blend of both technology and human interaction was needed to “iterate” plays quicker. As a result, instant replay was available to teams in controversial situations and referees were able to make decisions that kept the game moving.

With unanswered questions such as the relationship between Agile and fixed budgets, the transition from Waterfall to Agile seems impossible to most. As a result, should we be concentrating on better Agile practices that move further West or explore back East to find a better blend? Maybe a better East-West blend doesn’t exist, but could we find processes that help bridge the transition between Waterfall and Agile, thus increasing adoption rates?

Wild estimations are a common job hazard that every developer encounters. Developers are asked to give exact estimations based on few requirements, little to no domain experience, and in a very short time. Whatever number the developer spits out of their mouth becomes written project law. How fair is that? It gets worse than unquantified estimations…

The real problem is that you, the developer, now have effectively taken all responsibility for the project budget. By giving a single point estimation the project manager is no longer in control of the situation. All responsibility of the success and failure of that project is riding on your ability to wildly guess. In other words, you have made a managerial project scapegoat of yourself.

So what can the common developer do? The answer is simple – learn to push the decision making back onto the manager. By forcing management back into making the “important” decisions, you are giving management the authority to be responsible for the project again.

For example, let’s pretend you are a consultant working for $100/hr and get asked to do an estimation for a new custom solution.

Old Way – You throw out a complete guesstimate of $50,000 (500 hours). You are now a budget scapegoat.

New Way – You think it will be about 500 hours, but you present it with this wording:

Boy, this is really hard to say. I apologize for the range, but somewhere between 500 – 1250 hours. I can 100% guarantee that 1250 hours is plenty of time, but there is only a 10% chance that the project will come in on budget with a shoestring budget of 500 hours. How many hours would YOU like to dedicate to this project.

This tactic puts the act of estimating back into reality. An estimation range is much more forgiving than a single point estimation, and it gives multiple options for your manager to consider.

Your manager might have many business reasons for wanting to reduce your estimation. Putting a probability of success associated with each dollar amount makes them answer the tough questions they may have been dodging:

• Is the client most concerned about dollars or success?
• Is the business willing to take a 50% gamble on project failure to get this bid?
• If I gamble on a 10% success rate – what will happen to ME?!?!

The equation for this is very simple linear equation. If you feel your estimation ranges could use modification, I would recommend starting large and tightening using a model like the cone of uncertainty:

Being a responsible estimator is important, but being responsible for your estimates is not. You have to build the solution, you should not also have to manage the budget. Put your estimations in ranges with probabilities and let your manager manage the costs and risks of the project.