This series of posts was first published at the Fortnox developer blog during 2014. The articles where collected, refinished and put on display here after Jonas moved on from Fortnox in 2015.

The series consists of five blog posts:

Software craftsmanship - Part 1 - Covers the main points of Agile, the original version.

Software craftsmanship - Part 2 - Cover the rest of the Agile manifesto as well as talking about TDD and testing in general.

Software craftsmanship - Part 3 - Rundown of software craftsmanship.

Software craftsmanship - Part 4 - Spending some time on the SOLID principles.

Software craftsmanship - Part 5 - Refactoring, with actual code and stuff …

I have spent a lot of time talking about Agile and why we have it. I have not spent any time on Craftsmanship yet, so lets.

Intro

We spent a fair bit of time talking about the Agile movement and it’s, in my opinion at least, virtues. I gave a very, very short intro to TDD and referred to the software craftsmanship movement more than once. Today we will spend some time talking about why we want it, why the agile movement has failed, in some respect at least, and what the software craftsmanship movement is all about and if you should care.

The manifesto

The software craftsmanship movement is defined by a manifesto, just like the agile movement. It’s short and to the point so I will reproduce it here:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.¹

Well that is straightforward enough and sounds, at least to me, like good ideas. More on why they are good ideas further down but first; Why do we need this?

The failure of Agile

The first thing to note is that it’s not the thoughts behind the agile movement that have failed, it’s the movement itself, at least according to the authors of the software craftsmanship manifesto.

Have you recently received any invitations to attend agile training in your inbox? Any posters about scrum master certifications? Any ads for courses in standup meetings? If you haven’t seen any such things recently you are among a very few in our industry and that is at the core of the problem with the agile movement.

We, developers, started it². It was meant as a tool for us to improve and excel. We analysed the problem with existing project management regimes and wrote our own. All the roles played by us. The scrum master is a developer. The standup meetings are lead by a developer. The customers are talked to by developers. Basically we cut out the middle man, the project leaders.

Well, middlemen don’t like to be cut out :) So they all started to read up on agile project management and came back as the obvious choice for scrum masters and other non technical roles in the agile machinery.

This has spawned a massive industry of certifications, weekend courses and other quick fix, agilification solutions³. It’s an industry that’s not going away. It’s large, established and making people a lot of money. And not necessarily all bad either.

Let them eat cake

But one thing got left by the wayside in all this, the sense of community and progression that was there in the beginning. Since the agile process is now an established development process and the scrum masters et.al. are played by project managers and other non-developers we lost the heart in the manifesto⁴.

It was meant to be a process of improvement. When you formalise the process and nail it down in the company process documentation you lose flexibility and control. Especially if you are a developer.

So with some of the original intent lost to the success of the agile manifesto something else was needed to take it’s place. Something to carry the torch for developers who wanted to steadily improve their craft, without meddling from project managers and mid-level executives.

Craftsmanship

If we look at the manifesto for software craftsmen again we can note that the first paragraphs neatly excludes anyone who isn’t a developer from the community this time: “As aspiring Software Craftsmen”, “professional software development” and “helping others learn the craft”. It’s hard to insert yourself in that sentence unless you, at least partially, write code for a living…

With that point clearly made it goes on to reiterate some of the core values from the agile movement: customer collaboration, community, quality and flexibility can all be seen in both manifestos. So the difference is not so much what they want to achieve or what they value but how they go about it.

The agile manifesto got focused into establishing a new way to organise and manage projects while the software craftsmanship manifesto tries to establish a community for software developers who seek to improve continually. Who want’s to have long relationships with their customers and thereby establish trust and take responsibility for their work. And who understands the deeper values of designing well, refactoring often and testing their work.

What now, testing?

Yes I know, it’s not spelled out in there but since most of the original ideas for the manifesto came from companies like 8:th light, home to Robert C Martin AKA Uncle Bob, first archon of TDD as well as having early signatures from people like Corey Haines, Martin Fowler and Kent Beck, the author of “Test Driven Development: By Example”, it’s more than just a hunch from my side that they are implying TDD, among other things, when they say “well-crafted software” and “steadily adding value”⁵.

So by inference being a part of the software craftsmanship community should get you going in the direction of test driven development if you are not already practicing it.

Good ideas

I said above that the manifesto, to me, encompasses some good ideas. Things like sharing and helping, in this case sharing knowledge and helping each there grow, are always good. But there are several other key points in the manifesto. For example the last part about productive partnerships.

Productive partnerships

The agile movement moved developers closer to the customers. With this shortening of the communication paths and the rapid iterations of agile comes software that is closely aligned with what the customer wants. But it still leaves some possibilities on the table, things like that we are the professionals, we know the technical domain and we have to be able to say no.

If you consider yourself to be in a partnership with your customers, a long lived partnership. You will naturally align your goals with theirs in such a way that you want them to maximise their success.

Even though many consultancies still act as if it were the golden days of the IT-boom, building crap software with impunity⁶, the software craftsmanship movement is trying it’s best to change this. For consultants, customers are basically the sales organisation. They bring in the end customers that in turn bring in the money that go partially to paying developer salaries.

Sounds like a no brainer to take care of the hand that feeds you, no? Well, it hasn’t always been. And above all there has been, and still is to a large extent, a culture of just saying yes. “The customer is always right” might work in retail, but not when you are the domain expert. It’s our responsibility as professionals to point out when our customers are spending their money wrong.

We are the domain experts, we should force our customers to rethink when appropriate. We should challenge the data they use when making technical decisions (often none or close to none). We should challenge their choice of platform and framework (honestly, they shouldn’t care much⁷). And we should help them prioritise the tasks to maximise their utility and push vanity features and “nice to have”s to the very end of the backlog.

Maximising utility and profit for the customer is most definitely part of the job description of every professional developer. When was the last time you considered exactly how what you do affects the customers bottom line. When did you last challenge a task on the basis of customer profitability? Do you know what drives your customers business? If not you should find out, they will gladly tell you if you ask them …

Community of professional

The hope of all involved here is that we can help each other to build a community where we share our knowledge and that can act as a forum to discuss tools and techniques for improving our craft, for getting better at building software.

If you are an employee of a good™ company you might already have a community where you can grow and improve. If you are still at school it’s more or less what you do each day. But some day you will grow out of your rather small pond. If you apply yourself you will outgrow your peers and you will need to find other people to help you grow, others that want to help you grow.

The software craftsmanship movement is a movement for everyone who wants to improve and help others improve. And since the movement includes most of the people that are the biggest influences on my thinking and development over the past several years, it was a natural place for me to go. Maybe it’s where you want to go as well?

Steadily adding value

This also goes back to the argument about the customer and their profitability. Adding value in this case is adding value for the customer, ie making them more money. And since we are not only interested in the short term here this includes things like refactoring, modularised design, composition of small objects, clear boundaries between parts of the system and a lot more.

This might feel apart from the money making part, after all in the worst case these things can end up being nothing more than navel gazing and self indulgence. But there is an intrinsic value here as well. Your customers needs will change over time and you need to prepare the software for that change.

Since we don’t know what changes will be required we have to stay as flexible as possible. That means having a design that affords change. Adapting the design over time to keep the flexibility while adding utility and doing this in some kind of framework that helps us staying on track and not going off on some yak shaving mission.

Well-crafted software

Leading up to this then, the swamp. Not that I don’t believe you can make well-crafted software. It’s that everybody has a different idea about exactly how you do that :) I will spend a lot of time on this point in future posts, so I’ll gloss over it here.

Well-crafted software is basically what I described above. Software that affords change, serves it’s purpose and does so as effectively as possible.

This is more than just programming, more than code. Into this comes things like technology choice, platform, framework, language etc. It’s about metrics and business decisions and aligning development effort to support them. It’s about using processes and tools that maximise your productivity while minimising the amount of shaved yaks or explored rabbit holes.

It’s about professionalism and what that means, especially it’s about what that means to the people that wrote the manifesto and if you agree with them. If you do, and you’ll know in a few weeks, you should sign the charter and keep working on your skills. If you don’t you should not sign the charter, but by all means keep improving your skills anyway.

Thats a lot …

To be honest, it depends… For me, personally, the cost of software craftsmanship is non-existent. I had ended up somewhere close to the lower end ideals of the software craftsmanship movement before I heard about it. So that extra step was not very far for me.

But if you don’t yet believe in test driven development, haven’t heard about refactoring and only know the singleton pattern and feel uneasy about what composition over inheritance mean, you will most likely feel like you have a ways to go.

But we have to remember that the manifesto, and signing there off, is a statement of intent. It’s not a certification, very explicitly so. It doesn’t require you to believe that TDD is the best thing since sliced bread. It doesn’t require you to know certain techniques or practices. All it requires is that you feel strongly about your craft. That you apply yourself to it and getting better at it. That you see your career as a journey and that you see that journey as a worthy goal in itself.

What’s next?

Well, since I lauded to that there are some techniques and tools that are de-facto standard, if not in the movement than at least for the people in it, I thought I’d talk a bit about them.

So in the next few weeks we will talk refactoring, design and why you should read “Patterns of Enterprise Application Architecture” even if it sounds like the most boring book ever.

See you then and remember, refactor mercilessly.

Image courtesy of Rob Shenk at Flickr under a Creative Commons - Attribution, Share Alike license.