Software craftsmanship ... I want it all

And I want it now

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.

1 Are half of IT professionals useless?

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.

About the author

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.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: Software craftsmanship ... I want it all

Good Post! And yes I've seen a couple of charlatans in my time as well, most notably the Java/JEE Guru contractor who had to ask for help in executing java from the command line as he couldn't figure out the classpath.

Re: Software craftsmanship ... I want it all

I've also had to help contractors/consultants hired as "Java experts" to compile and sort out classpath issues. It makes me very unhappy. :-/

Re: Software craftsmanship ... I want it all

nice post Simon, unfortunately that's the reality we have now. Many companies tough, tend to go for cheap solutions that in the end results in getting only the html mock-up. The contractors or development teams that focus on providing quality from the first line of code, of course may charge higher, but they'd provide quality with it. Check out my recent post, that reflects on that, basically how to start building quality in from the lowest leve. http://agile.am/dHxtTH

Re: Software craftsmanship ... I want it all

Thanks, I like your post too and it's so true. I've had a relatively hard time on a recent project because people's definition of "done" seems to vary wildly.This particular system suits integration level testing rather than unit testing, so that's what I've been asking team members to do. It took a while but we got there in the end and we have a much more robust code base as a result.

Re: Software craftsmanship ... I want it all

If you hired or recruited a bad developer, start by blaming yourself. If you didn't spot what they were up to, continue blaming yourself. After all, they probably didn't know any better - assume Hanlon's Razor applies. Does this need craftsmanship? I know it's not the zeitgeist, but how about a quality plan?

That said, there's enormous merit in what software craftsmanship champions. The trick, as ever, will be to apply "just enough".


Add a comment Send a TrackBack