May 19, 2010
Another Rant About Reinventing The Wheel And Against Yet More Navel-GazingGood morrow, gentle sir.
There's only so many times you can sit back and watch people "invent" stuff that's already been invented (several times over) before you start to realise how Neo must have felt when The Architect told him he was not the first to be called "The One".
Underlying any successful approach to software development is just a handful of core principles, all of which we've known about for decades. The recipe for working software - useful, reliable, maintainable working software - combines these staple ingredients with in a simmering reduction of talent (because any approach requires talent to work).
1. Tackle development in the smallest meaningful chunks that can be released to the customer. Any betting man will tell you that putting all your money on one horse is foolish in the extreme. Software development is very risky, so manage that risk by breaking one big gamble down into smaller, less risky punts. It also helps teams focus, by breaking requirements down into more manageable chunks.
2. Get meaningful feedback as often as possible, and adapt your software based on what that feedback teaches you. This is another pivotal element in successful - well - succesful anything. Iterate. We're not actually capable of solving complex problems any other way. It's been nature's solution right from the Big Bang. Life is a product of iterative design, as it happens. Oh, and get feedback by the most objective means you can. Just a hint: basing decisions to adapt your software on stuff people tell you is unwise. Because people mostly talk bollocks. Better to observe users actually trying to use the software you've delivered to do things you've agreed they should be able to do using the software. It help if you know why they're using your software. I know, it's a crazy idea! Which leads me neatly on to...
3. Have testable goals. Software development is expensive and hugely risky. Why gamble all that money if you don't have a clear picture of what it is you're spending that money for? What does your customer hope to achieve? How will they know if they've achieved it? At all levels from the business strategy that's driving the whole project or programme, down to understanding what a single method should do to contribute to those goals, it's incredibly useful to know precisely where the goalposts are. The best way to express goals testably is by writing tests. Just in case you were wondering. These could be project KPIs or business simulations and scenarios, or they could be behavioural specs written in RSpec, or unit tests written with JUnit. This is especially important when iterating. Feedback from tests can give you a very firm indication if you're getting warmer (or colder) with each pass.
4. Do the more important stuff sooner, especially if it's easier to do. Well, duh! Sounds obvious, right. Software development's a gamble. You've got a fixed amount to bet. If you leave your juiciest bets to last, you could run out of cash before you get the chance to place those juicy bets. It's not just a question of what a feature might be worth. Also bear in mind the cost and risk it might incur. Higher value, less costly/risky requirements should be further upstream in your requirements pipeline (or "backlog", to use the hip new street vernacular that I know many of you kids are into today).
5. If you find yourself doing something more than once, consider programming an evil robot to do it for you. Hey, you know what software's really good for? It's good for automating repetitive tasks. We've dedicated ourselves to taking the grind out of many people's jobs. Accountants can add up a balance sheet instantaneously and with total accuracy and consistency using spreadsheet software, for example. And think how long Avatar would have taken to render using coloured pencils. So when you're copying all those files across to the web server for the 27th time, consider how much time and trouble and risk might be saved by writing a program to do that for you. When you're writing yet another block of code to save and retrieve some object from a database, consider how much time you could save by automatically generating that kind of code. And so on. At the very least, train a monkey to do it.
6. Write your code so that it's actually possible to apply the first 5 principles, especially the one that adds most of the value - iterating your design. I'll make no bones about it. We have always known this. The biggest impediment to writing new code is the code you've already written. People in white coats carrying clipboards, probably working at the Laboratoire Garnier, have discovered that people like me and you spend most of our time staring at other people's code wondering what the buggery-hell it's doing. In this respect, the perennial killer germs are complexity, dependencies, duplication, poor regression test assurance and general lack of comprehensibility - often due to poor choices of names for variables, functions, classes and so on. While there's been something of a resurgence in disciplines that make code easier to understand an to change - like Domain-driven Design and Software Craftsmanship - we've actually known pretty much exactly what we should have been doing for several decades. So suck on that, Clean Code naysayers!
7. Use software developers who are good at developing software. No, seriously. It's all been for nought if, after you adopt your super-duper shiny new Agile Lean Kanban Unified Model-driven Development Method, you bus in a bunch of inexperienced, unpracticed, unmotivated, unprofessional code slobs. Just as sure as your super-duper shiny new Million Dollar Luxury Show Home will turn into a run-down hovel if you move in a bunch of first year med students. Indeed, I'd forgo 1-6 if I knew I had 7. Because a team of great software developers would probably do 1-6 anyway, instintictively and habitually. Of course, the fly in the ointment is that there's a very limited supply of such developers.
8. Get better at developing software. How many times have you done something for the first time and it's been just absolutely perfect? So perfect you couldn't possibly have done it better? Or done it quicker? Or done it cheaper? Or done it in a way that killed less horses? There's usually room for improvement in any activity or endevour, and this can be achieved by reflecting on what you've done and how you did it, aided by scientific principles to stop you jumping off the deep end into New Age Mumbo Jumbo Voodoo where you end up trying to improve design quality by homeopathic means or some such rubbish. Measurments can help, if they're good measurements and they're used in a grown-up way. Hard evidence generally is more useful than hearsay and anecdotal evidence. Check in histories, build reports, test reports, code metrics, screen captures, system logs, team height above sea level and average shoe size are just some of the useful data sources that can be analysed for clues as to how things could be done better. Smoke signals, aura readings and 100% discussion or opinion-based retrospectives tend to be the least useful. And practice needs to be part of the team's daily routine. Programming encompasses many theoretical discplines, but it's still by-and-large a practical skill, like speaking a foreign language. When you spot a deficiency highlihgted by your restrospectives, incorporating specially-designed exercises in your practice regime is a good way to turn a theoretical fix into a habitually-applied solution.
My point here is that there's no news here. All of these principles were known before most of us started our careers. Indeed, before many people had computers in their homes. What really would be novel is if we all started actually applying them. Instead of just dreaming up sexy new ways of talking about them. There's surely a lot more to discover about the art and science of software development. But when it comes to these core principles and "the old ways" that people like Knuth, Jacobson, Jackson, Hoare, Gilb and others were writing about while many of us were still in short trousers (or just glints in our parents' eyes), I think we're all talked-out.
Time for doing, not talking.
Posted 9 years, 2 months ago on May 19, 2010