We say ‘Building Software’
Building emphasises the Physical.
But we are creating nothing physical.
‘Writing Code’ is closer to the truth.
We are inscribing Symbols in the same way humans have communicated since the invention of writing.
Our audience is machines, and more importantly, other engineers.
Thinking of the Software Engineering process as creating an Instruction Manual provides different insights…
… in to the way things can go wrong
And how Clarity is essential.
Estimates are wrong. Try not to use them. Deliver Value Instead.
Two commonly provided pieces of advice in doing estimates for software development are:
Any reasonable person would conclude that we don’t know what we are doing.
Yet compare this to construction where skyscrappers are built to schedule.
The project management triangle of Cost, Scope and Time.
Software development projects are more akin to writing a novel than construction.
Think ‘Writing Code’ rather than ‘Building Software’.
It is possible to accurately estimate software development projects…
… turn them from a creative task in to a well-defined process.
Guess what is excellent at executing well-defined processes? Computers
The act of writing the software is in itself defining the process.
Rather than trying to estimate, instead deliver value.
The more value delivered…
… the less estimates are required.
Understanding what’s really going on in a product enables us to understand both the strengths of the product, and where the limitations and rough edges are likely to be found.
Vendors are sometimes not clear to prospective purchasers on the technology underlying their product.
It can be difficult to drill down and understand how a product actually works, and what technologies are used.
There is a lot of hype, unique terms and pitching of technology products that disconnect purchasers from the underlying technology and capabilities.
Often the underlying technology capability is actually available in different forms, including open source and cloud offerings, which may be more suited to your needs.
Meeting with a vendor solution architect may not resolve this, the solution architects job is to identify how the product could meet your need, rather than explain how the product works.
The vendor does however need to hire experts in the underlying technologies they use.
Check their careers page…
… who they are hiring says a lot
Good Engineering is a guarantee of sleeping well at night.
Systems work as they should.
Known risks are managed.
Behaviour is documented.
Maintenance is performed.
Good Engineers know how to do Good Engineering.
Great Engineers know when not to.
Focus on creating a basic end-to-end implementation of a system as quickly as possible.
Software Engineering is a process of exploration.
We start with an Outcome.
Often we think we know how to get there.
But this isn’t our first rodeo…
… we know there will be surprises along the way.
→ We need to find the surprises as soon as possible.
Identify the most essential function that the system must perform.
The minimum viable pathway through the system.
Build this core functionality from start to finish.
Focus on creating something that works.
Once this basic end-to-end functionality is established you’ve found a path…
… and have discovered any surprises along the way.
From here you can:
Iterate forward from the initial implementation
Take the learnings, and figure out how the implementation could be done better.
In both cases, continue to iterate till you find a solution you are happy with and provides confidence in meeting the Outcome.
If someone is waiting on you doing something…
…then unblocking them is likely the highest value that you can provide towards achieving Outcomes.
It’s simple.
If we are working on a task…
…the maximum progress we can provide towards the outcome is the result of our efforts.
If we unblock someone else…
…then the progress we provide towards the outcome is the
sum of our efforts
+
the contribution from the unblocked
If we don’t unblock someone…
…we are basically saying that we don’t value the contribution that they would make.
If we don’t value the contribution they would make…
…why are we working with them at all?
To deliver Outcomes it’s important to
What we manage to deliver provides insight in to these two factors.
Urgent and Important
If something is Urgent and Important, then it usually gets done.
If we are unable to get all the Urgent and Important work done, then we are failing.
→ Something needs to change
Important
If something is Important this is where we drive the creation of real value.
→ Ideally we should be spending all our time here.
If we never get to the Important but not Urgent tasks, then the chance of success drops significantly.
We are not in control, we are at the whim of external factors.
→ Regain Control
Urgent but Not Important
If something is Urgent, and not Important, then we shouldn’t be doing it.
We should confirm what is Important, and focus there… if we can’t get rid of the task, maybe it was Important after all
→ Avoid the Urgency Trap.
When a software engineer is delivering code, they need two tasks:
Anything else can be handled outside of the engineers coding loop.
(Side note: Priority used to be a singular concept)