My favorite TV series ever (with the possible exception of The A-Team) is Burn Notice.
It is about a likable, good-natured, if not slightly single-minded ex-spy named Michael Weston. Michael was kicked out of the CIA, so while not trying to get his job back, he 
spends his days righting wrongs perpetrated against the good citizens of Miami. There are a lot of car chases and explosions along the way. It’s fantastic.
Throughout the course of the show – he gives spy tips and explains the situations he’s in as voice-overs while the action continues. In one situation he’s trying to find (and stop) an assassin that is about to do what assassins do. He explains, “Assassination is 1% shooting, 99% preparation, anticipating moves, devising approaches, recruiting sources, finding the perfect opportunity so the bullet is almost an afterthought.”
The same holds true for software. Putting an actual production system into play should be almost an afterthought. Unfortunately a typical software practitioner tends to spend 99% of their time shooting and only 1% preparing. Fortunately the consequences of this misplaced priority aren’t as extreme as it would be for the assassin that made the same mistake.
However, if we want to produce incredible software – we have to (almost obsessively) prepare. But what does this look like in practice?
This is where it gets interesting. Software is nowhere NEAR as simple as many people think it is – technologists included. This is probably why practitioners spend so little time preparing – why spend a lot of time on something that is so straightforward: you write some code, you make sure it works, you set up a server, you deploy – easy as pie.
I am being slightly sarcastic here – but in all seriousness – those basic steps are the only ones that seem to get any press. This is likely due to the fact that if you miss any of the aforementioned steps, you simply won’t be able to move forward at all. And further, for a trivial software engineering exercise, these steps are all you would need. However – this blog is called “Software For Profit” – and few profit from trivial exercises in software.
So to get past the basics we need to realize one major thing – software is about both people and technology. So, creating great software comes down to balancing people concerns and technology concerns. These concerns tend not to be particularly obvious – and even less obvious is the interplay that exists between them. Managing them properly can lead to multiplying value – managing them poorly can lead to severely diminishing value.
For example – if introduced correctly, a high-powered source code management tool may multiply developer productivity. If the discomfort of such large change (a people concern, for sure) is not accounted for – the same tool could significantly reduce developer productivity. Another interesting example is the interaction between software design and development process particularly within agile methodologies – a modular system with a well laid out object model is inherently much easier to clearly decompose and therefore much easier to deal with in a scrum planning session and during a sprint.
This blog will be dedicated to identifying a wide array of these people and technology concerns, explaining their interactions and suggesting ways to optimize them so that we can all write the best possible software.
Here’s to creating incredible software!!
