I did a talk today for the local BCS about how to get started if you need to design a software solution when all you have is a business vision and a blank sheet of paper. During the Q&A towards the end of the session, somebody asked whether the 80-20 rule was still holding true. In this particular case, the question was about whether software was developed in 20% of the time, with the remaining 80% being needed to make it actually work. Reading between the lines, in my head, I translated this as "does software development still suffer from the same old quality problems?".
My response was that some software teams do work this way and I'll stick by that. I've seen teams essentially writing crap and then relying on excessively long testing phases or large post-development maintenance contracts to patch all of the holes that shouldn't really be there in the first place. Other teams, however, put emphasis into actually getting it right first time using a lot of the "good" practices that you'd associate with modern software development; automated testing, continuous integration, source code control, patterns, reuse, etc. I'd also suggest that such teams can probably get it right way quicker than those other teams churning out whatever it is they do churn out.
If you've been following the software development blogosphere recently, you'll have seen a ton of stuff about software craftsmanship. The question I was asked is a perfect example of how doing a good job differs from doing a bad job. Craftsmanship if you like.
Now, there have been lots of posts recently about what software craftsmanship is or isn't; including discussion about what characterises a craftsman, whether it's just about beautiful code, whether it's about delivering what's expected and so on. For me, it's simple. I want it all and I want it now ... software that exhibits good design, is of a high quality, has beautiful code, works, meets expectations and generally makes everybody engaged in the process happy. I also want it to be done efficiently, effectively and with minimum messing around.
Our industry is a bit of a mixed bag. Some developers are excellent, always striving to improve, while others are just in it for the money. However you look at it, this software craftsmanship stuff is mainly about improvement from within. I train developers on a regular basis and I'm trying to do my bit to help teams build better software. But what we really need is for people outside of the industry to start peeking in and see what's going on. I know it would be hard to achieve, but I do think that there should be some way for people using our services to differentiate the good from the bad. Many vendor-based certifications are essentially worthless and they certainly don't reflect anything about the craftsmanship aspects that people are talking about. A Microsoft certification might reflect that somebody knows what an ASP.NET page is, but could the holder of that certification actually design, build and deploy a robust, decent quality website that did what it was supposed to?
Many people engaging software development services have very low expectations of software teams, probably due to past failures or because they've hired 9-5 developers that were paid too much, didn't know what they're doing1 and delivered nothing2. Others are simply naive about the whole engagement process and are being taken for a ride by organisations taking advantage of this fact. As an industry, I think it's time for some differentiation and professionalism across the board.
2 A friend told me a story about a contractor that was tasked with building a database-driven website and he basically only delivered a HTML mockup. He would always drive the keyboard during demos and nobody ever doubted his progress. But one day he was rumbled, left in a hurry and was never seen again. Beware the developer with no shoes.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.