The Spec
The Language
The Practice
The Books

Long Division

Some problems are most efficiently solved by using an estimation-based approach. There may be a deterministic way of doing the problem, but given the limitations of a human to keep track of complexity without error and the amount of time required to do it without error, the best way to do the problem may be to employ a disciplined amount of trial-and-error.

Software appears to be most efficiently created by this kind of non-deterministic approach. It could be compared to working on long division problems without the benefit of a calculator. When you work on long division, it is usually best to estimate the next number in the solution and then multiply and subtract it out to see if it is close enough to go on. If it isn't, you need to make the next best guess and multiply and subtract again. Each cycle, you attempt to do the same thing, and each cycle you gain more knowledge. As long as you are getting closer and not farther from the solution, you know that the solution is nearer, but until you find digit in the correct range, you don't really know if you've found the right answer. You can, however, tell if you are getting closer or farther from the solution.

Software development is proving to be best done in a series of trials, much like long division. Each delivery is a trial to see if a good product or feature of a product has been properly understood and created by the programmers. Each new estimate is more accurate than the first as long as care is taken to reach a goal.

You can imagine how hard it would be to solve a long division problem if you were forced to write a project plan for it in advance. Lets just pretend that seconds are hours and you have a problem like this:

30599283740325 divided by 1241 in decimal notation without a calculator.

How long will that take? I want each number in the answer to be a milestone and you must estimate the number of seconds you will take to get the next digit in the answer. What if I added another issue. Every time you find out that the number is going to take longer to calculate than you though, you must stop and turn in a change request document explaining what happened and how much extra time you plan to spend figuring out that number.

This is kind of silly, I know, but this is really what we face on a larger scale as programmers when an organization does not understand the learning part of software development. A more appropriate way to control the process would be to make sure that the solver is getting closer to the solution and not farther from it by following a disciplined approach.

Even short division can expose a problem that is common in the software world. Try this problem:

Divide 1 by 3 without a calculator, using decimal notation not fractions or remainders and report to me immediately when you are done.

Well, the problem with this is that it will go on and on forever. In fact, there are many division problems that go on and on and cannot be completed unless the person doing the work knows when an appropriate level of detail has been reached. It is important that the programmer tell the customer when a problem like this is discovered and it is important that the customer not expect that every problem they have will have an obvious ending. It's also very important that both the person requesting the problem be solved and the one doing the problem start out with a goal. For instance, by first writing down that this problem should be solved to the 10 decimal place. It's important that the customer think through their needs and communicate them when these detailed questions are asked by the programmer.

A serious and detrimental problem can develop in an organization when this estimating approach is discouraged. Instead it should be recognized as an efficient discipline and encouraged in order to have a healthy long-division-solving or programming team.

Troy Taft is the Principal Consultant and founder of Troy Taft Consulting, a firm specializing in high value software development. He also authors a free monthly newsletter called Software Matters.

Copyright 2007 Troy Taft All rights reserved, you may print this article for your personal use.