Born out of techniques that “revolutionised” Japanese manufacturing and engineering, come the principles behind ‘lean’ software development. Not Agile you understand, but lean.
The latest route to “dramatically increasing productivity and quality” (how did we know they were going to say that?), is detailed in a new book by those venerable scribes who earn their crust writing for the O’Reilly publishing house. But while I am a fan of their books; when I saw the headline announcing this new volume’s arrival, I couldn’t help wonder if a lean approach might occasionally leave us wishing there were a little more meat on the bones.
… and so I read on.
With a somewhat zen-like approach to problem solving, the book’s authors suggest that the reader learns how to adopt lean practices one at a time. They further state that at each level, measureable benefits will be seen. There are both “similarities and differences” between lean and Agile, but the exact form of these comparisons is not made clear in any summary information I could find. Umm, so they’re quite similar then we think?
The only chapter available for download review focuses on automated testing. Not automatic you understand, but automated. Automatic testing is just plain old simple software that scans and analyzes your source code after all. Instead automated testing is interested in checking the code’s correct behavior, something that a code analysis tool cannot do say the authors.
We can also learn that mistake-proofing is a fundamental lean concept as it “reduces waste by eliminating rework” and if you’re wondering why you haven’t read anything revolutionary yet in this blog, that’s because that’s what I was thinking when I wrote it.
So this makes me think two things: 1) is this just a veneer being placed on previously accepted principles of software development and 2) don’t we need a little fat and gristle for the meatier aspects of the total software development process as well?
I was speaking recently with Perforce Software’s Dave Robertson about the use of Agile and how Software Change Management can help manage a code repository for version control in complex systems that have an ‘element’ of Agile. OK it wasn’t ‘lean’ it was Agile (I haven’t started using ‘Lean’ in CAPS yet), but we know they are close anyway don’t we?
Robertson told me that if methodologies like Agile are used, they are not always suitable for all elements of the development lifecycle. For example, if you look at the ‘infrastructure and foundation’ levels in say, a database. Constructing these with Agile may not prudent. Go a little slower and lay down a little fat and connective tissue (if you don’t like gristle) so they can support the upper firmament of your software.
You can still use Agile, lean, low fat reduced carb process to build layers such as a web-facing interface mechanism (just for example) on top of that database. But make sure you have a meaty base to start with. Anyway, here’s the link if you still want to buy the book.