After years of promoting best practice and automated test driven development (ATDD) / behaviour driven development (BDD) with Continuous Integration (CI), I have really taken the lessons of Lean and continuous improvement (kaizen) on board. I have been removing waste (muda) from the development cycle to reduce the time taken to deliver business requirements.
Some of this is in acknowledgement that the business is right – technology can take too long to deliver; you might even say I’ve gone native (or to the dark side). So I present you with my streamlined development methodology: Honesty Driven Development (TM) or HDD for short.
Whilst this can be applied to compiled languages, they are too slow to help keep a business nimble – so the natural home is with interpreted languages (or static files on a web server).
What are the key things that slow down the delivery of new software?
- Too many environments
- Builds & deployments
- The overhead of creating & maintaining automated tests
- Branching & merging
- Locking in version control systems
- Lengthy manual test cycles
- Troubleshooting “well it works on my machine“
- Tracking build numbers and defects
- Lack of pragmatism in the pursuit of perfection/elegance
Honesty Driven Development
At the high level there is one simple principle: If the developer honestly believes they’re doing the right thing – then that’s fine. If they screw up, they have to pay money into the honesty box.
This could be stated as an application of ‘JFDI’.
So how do you put it into practice?
The easiest way is to have all developers work directly on the live system – this allows features to be delivered rapidly and gives instant feedback (it either works or it doesn’t).
This is also the perfect anti-dote to ‘shelfware’.
Are there any risks?
Every piece of software has bugs at some point – the best way to reduce defects with HDD is to employ experienced self-taught programmers (developers/engineers with a technical degree may bang on about quality, defect leakage, capability maturity, code coverage, cyclomatic complexity, cyclic dependencies etc. when they could have been churning out code).
Update: please note that this was posted as an April Fools’ joke (as you would have realised if you’d clicked on the first link above).