Software without a design can very quickly grow into an unmanageable mess
Making changes to this mess or even maintaining it in a working condition can be a costly and time consuming exercise. I have recently come across two applications whose owners refuse to work on them any more – for fear of upsetting something and then never to work again. These are strategic applications, not just tiny insignificant bits of code.
In both cases, the companies can’t move, they can’t afford to re-engineer them – they are stuck.
A good design and some guiding principles can prevent the mess happening in the first place. It can even be retrospective to un-stick the project – so to speak.
I use the analogy of a building – very few would build a house without a design. And software can be far more complex than a house (and sometimes more costly too). You live with both.
Just a thought, but it occurred to me that the best way to pass an exam is to write the test paper.
Now before you say “obvious, you dopey dude” (use your own vocabulary) I’ve been using test driven development on certain types of project for years and am quite surprised that not many others do.
Like you build the tests before you design or write any code …
No need to over-do it of course, but it saves a huge amount of time and in fact helps with the requirements up-front too – one of the benefits is that it overcomes the “it always works this way … except for this little scenario that I forgot to mention” problem. Lots of other reasons too but I get boring …
Some of the quickest, largest and most successful projects I’ve been involved with have used this approach.
3D Printing, that’s how
3d printing seems to be taking a back seat when it comes to the press but I’ve been watching this for quite a while now. It’s unusual as often jounalists hail any new technology as world-changing only for it to be a little less than that.
It will change the world and faster than we think.
Imagine being able to “print” i.e. manufacture just about anything you want in your own home or office anywhere in the world.
Imagine the new car, a new pair of glasses, toys, medicine, food (yes food), body parts (yes body parts), clothes – it will all be printable.
Raw materials and their distribution will become a key factor (and by the way some of this is bio produced, i.e. made from growing crops!) as will design and copyright protection – open source? How do the designers get paid?
Oh boy are some people going to have to think hard in the very near future.
Me, well I’ll just print myself a new iPhone and call up some buddies, see what they think.
Why get the dev teams involved too early?
Well I say you ought to for two reasons:
- They will be prepared if the project does run
- They can often make significant contributions to the project
Leaving it too late is what I call “chucking it over the fence” often onto an already over-loaded team. Not good.
The dev teams on their part also have to ensure they stay positive (or they won’t get invited again!) and understand things from the business perspective. Things such as “fluid”, “unknowns” and “can do”.
So … you’re in the same game but the team is not working well?
A well performing team can deliver up to 10 times than the same poorly performing, demotivated team (yes really, I’ve seen this first hand) .
Turn that into cost – and you can do that easily – then you’ll get why we spend a lot of time on this subject.
It’s easy to demotivate hard working performers – try telling Federer (for example) that his forehand isn’t fast enough … you get the idea (if you stay around long enough)!
It’s also easy to motivate hard working performers too … spot the difference …
Well, this is about moving up a league in the game.
You do this with the existing teams (so it doesn’t cost much). You do have to invest some time and energy and maybe a little cash of course.
Very few teams can do this on their own, but most teams can move up a league or more! That’s why all good teams and players have a coach.
A coach understands the “Game” but can take an outside view and can study the strengths and weaknesses. They can also compare the team to others. They can coach the teams to “Raise the Game”.
Try it yourself – look at the team as a sports team. What would you do?
I liken IT, development teams in particular, to sports teams.
These teams are playing serious games, namely developing mission critical applications and systems for the organisations they serve.
We help “raise the game” for IT teams.
So maybe we need to look at what the “game” is? The objectives of the game:
- Understand what the business needs
- Help the business understand what can be done
- Develop applications that fulfil the need
- Develop quickly, as cost effective as possible and to a high quality
There are of course rules such as:
- Work with the business at all times
And the game, whilst intense, should be enjoyable.
So how about we “Raise the Game”?