Use Development for Discovery

Before you begin to build a house
and break ground on the foundation you better have a blueprint and know exactly
what you’re going to build. In physical construction, we really need to plan
things out ahead of time to ensure that we have the right materials at hand and
that things come together as we want them to.

This is a fundamental constraint of
physical construction and it forces us to think about and construct physical
things in certain ways. Virtual things do not have the same limitations and so
in many cases we can find more effective and efficient ways of constructing
virtual things then if we were to just follow a similar plan that we would for
constructing a physical thing.

Virtual things don’t have the same
limitations as physical things and Agile attempts to leverage this fact when we
construct software. Instead of designing a system up front, we can design it as
we go and if we do this correctly, it can be more straightforward and yield a
far better product that if we were to plan it out all upfront.

I did not believe this at first and
so I was reluctant to try Agile in the early 2000’s as a successful Waterfall
developer. How can I start coding when I don’t know what it is that I’m coding?
That’s what I thought but at the time I didn’t realize that I actually knew a
lot about what I needed to build, I just didn’t know everything, and I didn’t
need to.

In my experience, we rarely know
everything about a project before we start and operating under the false
assumption that we think we know everything can cause problems. Also trying to
figure everything out upfront in the planning stage is like trying to visualize
the future. There are so many variables and we as visualizers are so imperfect,
we often wind up getting the wrong impressions and missing key concepts that we
don’t recognize until were in the midst of it and it costs a fortune to change.

Writing software is the process of
working through problems and so when we get requirements that ask us to address
these problems and ask us to estimate how long it will take to resolve these
problems, we are at a significant disadvantage. It’s like asking a scientist to
give them the results of an experiment that they haven’t yet designed.

Managers are constantly asking
developers how long it will take them to accomplish a task and the truth is that
most of the time developers really don’t know. Developers are asked for
estimates and when they give a date their estimate there taken as commitments.
The word “estimate” and the word “commitment” are different, and they imply
different things but I find almost universally that a programmers estimate is
immediately turned into a commitment to finish a piece of work on a certain
date, whether they’re aware of it or not.

In my experience, software
developers are very well intended and many times optimistic about how much they
can get done in a short period of time. They shouldn’t be faulted or penalized
for their optimism.

I think the whole estimation
process is often a waste of valuable time and resources. I’m a big proponent of
the #NoEstimates movement. No estimates doesn’t mean never, ever do estimation
but rather do it appropriately, as needed, but also recognize much of the work
that one has to do to build a component is involved in doing the estimation
except at the end of the process you get a number instead of a working feature,
which is not nearly as valuable.

If you were really hungry and went
to a restaurant to ordered dinner and the waiter gave you a number instead of
your meal then you’d probably be very upset but somehow in the software
industry is okay for us to expend enormous amounts of time and effort to
deliver just a single number, which is often wrong anyway.

A single number is fallacious
because estimation is a probability and probabilities are not expressed as a
number but as a range of numbers. Rarely do I see managers ask for a range of
numbers when doing estimation, but having a range of probabilities can inspire
the right kinds of conversations about the work to be done, such as adding an additional
feature that pushes out a delivery date by X number of days and reduces the
probability that this release will be ready at a specific date by a specific
amount. Now we can engage in a conversation about if it’s worth it or what’s
our backup plan is or any number of productive things.

When managers ask developers how
long it will take to finish a feature they are giving their power away, they’re
playing victim. Developers don’t want this responsibility. Instead, what if management
said, “Look, we have this much money, which means that we can have you work for
this amount of time with this size of a team. Build as much as you can of the
most important features within those limitations.”

If you trust that the team is doing
the best that they can and that you have a good software development process, then
you will always get the best results that you could with the resources that you
have, so what need is there for estimates? It’ll get done when it gets done.
Estimates don’t change that, and they just take time to generate so they’re not
always worth it.

Of course, there’re planning and
release cycles and other issues that do need delivery dates but remember, in these
scenario management is coming to the developers and saying that want to release
on a specific date and asking how much they can deliver by then. Taking this
approach can often lead to a better product and a more effective software development
process.

Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Product Owners.