Hi this is Gary
Welcome back to Development That Pays.
In Episode 2, we talked about the importance of business objectives:
how it’s more important to satisfy real business goals than to craft beautiful code.
Then in episode 3, we talked the importance of code itself:
how we can’t know for sure that our business objectives are sound without first writing
some code.
(You’ll find links to both episodes below.
If you haven’t yet watched them, I’d encourage you to check them out.)
Unfortunately - or fortunately, depending upon your viewpoint,
we don’t have a business objectives picking machine
and we don’t have a code generating machine.
If we did, we could plug them in and watch super-profitable software pop out of the other
side.
No, we’ve going to need some people.
So let me introduce you to a couple of friends of mine
Business Bob
and Development Dave
Business Bob is the product owner.
In our walls and ladders model, Bob has responsibility for picking walls.
Development Dave is the Lead Developer.
Dave has responsibility for
stacking boxes...
building ladders...
and building staircases.
Roughly speaking, Bob decides what to build…
And Dave (together with his dev team) builds it.
The quality - and profitability - of the software that Bob and Dave produce...
depends on how well they do their individual jobs.
It also depends - to a surprisingly large extent - on how well they work TOGETHER.
It’s been my experience that the Bobs and Daves of this world
don’t work well together, at least not as well as they might.
To illustrate this, let’s look at what happens when they DON'T work together.
Bob has an idea for a new feature - "Feature X".
He’s spec’ed it out in detail, and hands it over to Dave
Dave and his team set to work.
After 4 long weeks, it’s complete and it goes live.
Only then does Bob see the awful truth. Feature X is a failure.
Dave, as you can imagine, is furious. A month’s work down the drain.
It’s not a happy ending.
Let’s play out this story again.
Bob has an idea for a new feature - "Feature X".
Dave comes up with a “minimal” version of X - let’s call it “little x"
It takes just 2 days for Dave and his team to get "little x" live.
Bob can see straight away that “little x” isn’t really working.
So he suggests a change.
Dave doesn’t have a problem making the change
after all, “little" x only took a couple of days to build
The next day, “little y” is live.
The initial results are promising.
Dave has an idea for an improvement. Bob likes the sound of it.
it’s live the next day.
And so it goes on…
… With Bob and Dave working together to refine the feature,
one small step at a time.
Bringing this story to very happy ending.
Okay - we don’t need Bob and Dave to fall madly in love...
… but I hope you get the point.
Talk to you next time.