“Do you have an estimate on how long writing the new software will take?”
To the questioner, it’s a completely reasonable question. New software is required and many other decisions hinge on the timeline and cost.
For the software developer, however, it’s often the equivalent of asking, “when will the world end and how?” We’re sure there is a way to figure that out, but it’s going to take time and effort to dig into the problem before giving an answer.
This then, starts the invariable cycle of frustration. “Well, when will you know how long it will take?” “You’re now asking me to estimate a duration for the estimation of a duration?”
In trying to measure the unknown, the software industry has embraced various approaches over the years, including Lines of Code (LoC) throughput rates, Function Point Analysis (FPA), and the Story Points estimation of the Agile world.
Any method that is based on resulting quantities of code artifacts, in my view, is inherently flawed. We as developers do not strive to solve problems with the most lines of code, nor the most complex algorithms. Our best work results in the fewest lines of code.
That’s one of the reasons I really like the story points concept. Story points are not required to be a specific measure of anything concrete. They reflect how the development team understands the problem to be solved, relative to previous problems solved.
Many developers struggle with this as they first encounter Agile. “But what ARE they? Hours? Days? Functions? WHAT?” It’s very hard to embrace a measurement system of something intangible.
As I’ve struggled myself to explain answer this question, one line of thinking came in handy: What is the real output of software development?
It’s not the “lines of code,” for reasons I noted above.
It’s not measurable in “programs,” “screens,” “reports” or “object classes” or anything else whose boundaries and quantity are completely arbitrary, based on the individual developers involved (and may not reflect good decisions).
What we sell, in this business, is “thought.” Code is simply the final delivery vehicle. It’s the effort to break down the complexity of a problem, a challenge, a requirement, and use the tools available to craft a solution.
We might solve the actual problem while using a whiteboard, or scribbling on a bar napkin, or writing a document, or prototyping, or feeding the ducks. The point is that the,actual keying in of code, compiling, building, etc., is only part of what we do. When we focus our estimating on those activities, of course it’s going to be incomplete. The actual valuable work is what goes on between our ears in getting to that point.
Story points allow for that. Story points allow us to quantify, by relative comparison, the time it takes to solve similar problems. Not just “write code,” but “solve problems.” Problem solving is thought. We can’t predict the exact amount of thought it will take to think through a problem. The best we can do is draw a comparison to similar exercises in the past, which is where velocity comes in to play.
Understandably, this will be a hard perspective to embrace, for both developers and their customers. Our stakeholders, in particular, may reject this explanation as a stall tactic, or a deflection.
Here is one possible path to get them on board. Get a book of mixed puzzles. It might contain Sudoku, crosswords, logic puzzles, story problems, etc. Now ask each stakeholder to estimate how long it would take to complete all the puzzles in the book.
Some might outright reject the request. Some might boldly offer a ballpark estimate, already planning a game of “schedule chicken” should they be held to their word. Some might request more time to analyze the book. How many Sudokus? How many pattern matching? How many that I’ve never seen before? Some may venture to assign ranges to each type of puzzle, based on their own personal experiences.
Most will concede that, even if past timing data was available for each puzzle type, there will still be variability and unpredictable errors, snags and retries. Almost no one would think that, since every Soduku requires 81 digits filled in, an estimate can be based on some per-digit number times 81.
Of course, this doesn’t satisfy those stakeholders who must commit to rigid limits of time and money. It does, however, provide a mechanism to illustrate the variability inherent in software development, and make a compelling case against selling to-be developed software at fixed bid budget and delivery dates.
I’ve been reading about Agile methodologies and the SCRUM approach to software development recently, as I prepare to institutionalize the practice throughout my organization.
One of the methods highly espoused by some Agile aficionados is “pair programming.” In this method, two developers literally share a single computer and take turns on the keyboard. The “observing” developer provides immediate feedback to the typist should anything appear fuzzy in the logic being written, while also considering the bigger picture solution. After 30 minutes or so, the roles switch, and the keyboard gets handed over.
In theory, some amount of logical errors (bugs) are avoided when the program survives the scrutiny of two independent minds. Pairs may be changed around regularly to avoid developers getting into a groove and thus losing the “independent minds” benefit.
Some developers bristle at the notion of letting another developer into their brain space so intimately, while others have tried it and swear by it. Some of the studies indicate a slow-down in initial coding but a significant enough reduction in bugs and other long-term maintenance / rework to more than justify the change.
Personally, my jury is out on the whole concept until I get more experience with it – actually see it in my own teams and hear from my developers. It seems like a good mechanism for continuous sanity checks, but I know there are minds that like to solve problems in private before sharing ideas with others.
However, I did see something recently that requires no more data, no more empirical studies, for me to know it’s a bad idea: Pair Shoveling.
I had the good fortune of spending the holiday break with my family on a sunny beach in the tropics. Every couple of days, the resort would comb the beach for the mounds of seaweed that the constant, pounding waves deliver, non-stop, to the shore. The team consisted of a tractor with driver, and two men tasked with digging a pit. The tractor combed the debris and continually dumped the contents into the pit. The shovel-wielding job consisted of digging out a larger and larger hole in which to bury the debris – staying ahead of the tractor’s endless onslaught.
The men shoveling really did not work well as a team, and in fact their productivity was half of what it should be. This is because, perhaps in a failed attempt to be Agile, they were sharing a single shovel. One man shoveled while the other watched for 20 minutes, then they switched. All the while, the tractor kept on delivering more and more debris to be buried. Repeatedly, the shoveling team would realize that the pit must be expanded, which meant displacing again the sand piled up around the current borders of the pit.
I won’t pretend to understand the economics, politics or logistics that led to this job sharing arrangement, and mean no disrespect to the two men trying to do honest work with inadequate equipment. My comparison to pair programming is, of course, tongue-in-cheek. However, watching the spectacle with a SCRUM text in hand, I couldn’t help but reflect on the unorthodox approaches we try in pursuit of excellence in the software industry. The shoveling team I observed were not helping each other dig a sufficient pit, they were merely relieving each other. They didn’t stave off rework, as the pit had to be expanded at least five times while I watched. They were not improving methods or finding more innovative ways to shovel. They were just taking turns shoveling.
I’ve read that pair programming really has little benefit on repetitive, already “solved” development activities that require little innovation and limited diligence. Shoveling. The best benefits are realized when charting new courses, solving new problems, etc., when the first thought of a single developer is unlikely to be the best answer.
We can safely use a mix of pair programming and singles in many projects. Not every project is 100% ground-breaking such that some of the routine work can be done solo, probably by newer team members coming up to speed.
We can also raise the awareness within the team that when you find yourself “pair shoveling,” partnering on something that is not benefitting from collaboration, it’s time to make a change:
- Break up the pair, and power through the work individually,
- Move on to a different challenge, if the shoveling deadlines can still be met (that tractor never stops!),
- Turn some of the problem-solving energy to automating the mundane coding itself – if it’s not challenging, it should be ready to automate.
I don’t know if “Pair Shoveling” will make it into the Agile lexicon, but for me, it will serve as a reminder to use the correct tool (and correct number of tools), for the job at hand.