- A lot of the ways we work comes out of manufacturing.
That make sense because some of the first projects
work with materials like wood concrete and steel.
Large companies build cars, roads, and buildings,
but when you're working with wood and concrete,
you have a completely different set of challenges
than when you're working with software.
You'd never start building a bridge
and then change direction midway through the project
but with software that's much more common.
It's easier to reprogram software
than it is to rip up steel and crack concrete,
but many projects are still governed by the ideas
that came out of manufacturing.
One of the most common
is that there's still a lot of focus
on planning out the work.
In fact, you could spend as much time planning
as you do building.
That's why it's still common to hear managers say,
plan the work, then work the plan.
That makes a lot of sense
if you're building something like a bridge, ship
or a building.
How you want to plan everything
that goes into the project before you start,
you also want to break up your project into phases.
So first you want to play on your bridge,
then finish planning,
then you want to build your bridge,
then finished building,
then you want to test your bridge,
then finish testing.
Each of these phases happens sequentially
one after the other.
It all makes sense in a world of steel and concrete,
but software is much more like science than manufacturing.
When you're developing software,
you're doing a mixture of building and learning.
As much as it's tempting to plan everything out,
it's just too difficult to predict all the moving pieces.
If you think about even a simple software product,
it might depend on an operating system
like Microsoft Windows.
Then it might rely on several different
open source projects.
The development language might change or get updated.
All these different changes are impossible to predict.
Most software products
have to deal with something called the cone of uncertainty.
The best way to think about the cone of uncertainty
is to imagine the relationship between time,
knowledge and costs.
So think of it this way,
I've spent a fair amount of time
on the east coast of Florida.
This is one of the states in the US
that has to deal with a lot of tropical storms.
It's sort of a strange experience
to be near a tropical storm.
At first, the meteorologists
only have a general idea of where the storm will land.
So they might say it'll hit landfall
anywhere along the east coast,
but as time passes,
they gain more knowledge about the storm,
so they can warn which cities to evacuate.
Then just before the storm hits,
they know exactly who will be affected.
So the corner of uncertainty
is the widest a few days before landfall.
Then the cone narrows
as the meteorologists gain more knowledge and time passes.
The problem is that the meteorologists
know the most about the storm when it's too late.
This is also one of the biggest challenges
with delivering software products.
You know the most about what it takes
to deliver the product only when you're nearly finished.
So many of the decisions
that you make at the start of your project
will be the ones that need to change.
Unfortunately, as you get closer to the end of your project,
it also gets more expensive to make changes.
So you need to find the balance between
making the minimum amount of decisions to get started,
but still give yourself enough flexibility to make changes.
This balance between making decisions
and having a flexibility to make changes
is one of the key parts of the agile mindset.
That way you can help make lasting decisions,
even when you're working within a cone of uncertainty.