Compared with other leading professions, the software industry is still in the early stages of development. As in any field, software developers are constantly attempting to identify practices and principles to develop better and faster software. As we've grown up as an industry, we've created resources such as Software Architecture and the Agile Manifesto, the importance of which is clear and well-established.
But even with these resources and guides to best practice, think about how many software projects still fail today. Is it due to our inability to apply the techniques? Or because client demands often require developers to rush through the development cycle? These are both real and relevant factors - but bear with me, and I'll share my theory as to why most software projects fail.
We all know the feeling of moving fast, right? Imagine working on a greenfield project, with code being written at light speed. Everybody is happy and we're satisfied with ourselves and our work. But not long after that, things begin to get progressively slower and slower. Whereas previously we were hitting all our goals at every sprint, suddenly we're left with carryovers at every turn. What happened?
Long story short, code rots at an incredibly fast pace. We all know of techniques such as TDD and refactoring, but we ignore them in favor of speed. When we create a lousy design that is never cleaned, our code rots and kills development speed. We try to convince people to allow us to do major redesigns in order to go fast again, and we keep lying about our estimates. We have all been there right?
That was the Bad Code part - now let's talk about ourselves. Why do we allow this to happen? Why don't we do what we know we should be doing? I like to think that you're only as good as this gap between what you do now and what you think you should be doing. The answer to that question is quite simple in fact. Simply put, we're not professionals.
I could spend hours describing examples of poor practices most of us are guilty of on a daily basis, not only with our code but in how we interact with people. We developers tend to have a bad habit of always avoiding conflict, so we often say yes to whatever the question is. After all, it's very unlikely that we'll be the ones to pay the price for our lack of responsibility. To illustrate this better, take a look at the example listed here:
Imagine this conversation between a patient and a doctor:
Patient: “My arm hurts.” Doctor: “What would you like me to do about it?” Patient: “Make my arm stop hurting.” Doctor: “Do you want me to cut it off? I can do that.” Patient: “No, I just want it to stop hurting.” Doctor: “I could cut all the nerves to your arm. That’ll stop it.” Patient: “Isn’t there something less drastic you could do?” Doctor:“Ooops, sorry, time for my break.”
Clearly we don’t expect doctors to behave this way. Even though the patient is the boss, the patient expects the doctor to have the answers and help set the direction.
Here’s another version of the conversation:
Patient: “I want you to cut my arm off.” Doctor: “What’s wrong with your arm?” Patient: “It hurts. I’m tired of it. Just cut it off.” Doctor: “Let me see your arm. Hmmm. Looks like you’ve got a sprain or perhaps a hairline fracture. We should take some X-Rays.” Patient: “No, just cut it off.” Doctor: “Sir, I do not cut off healthy arms.” Patient: “But I’m paying you. You have to do what I say!” Doctor: “No, sir, I don’t. Cutting off your arm would violate my oath.”
Which of these two doctors would you rather be? Now project these two doctors into your own profession, and which would you rather be?
It was with these tendencies in mind that several well-known software developers such as Uncle Bob, Ron Jeffries and Corey Haines decided to create yet another Manifesto. This time, created for us. Here it is:
The first thing you may notice is that the manifesto calls its adopters Craftsmen. This is the term used to identify people who believe in the presented ideas. According to Corey Haines, there are essentially two ways to qualify as Craftsmen or Craftswomen. You can either adopt the title for yourself, or receive it from your employer. The latter is fairly uncommon in today's world.
Although the principles are fairly easy to understand in theory, the first one might be hard to define in actual practice. What does it mean for software to be well-crafted? At this point in my career, I've had experience with what is clearly not well-crafted software, so allow me to share my view of what the term means.
Well-crafted software is software created by developers who care. Those who practice disciplines such TDD, BDD, Refactoring, Principles of good design and never settle for anything less than their best work. We all know the difference between code written by someone who cares and code written by someone who doesn't.
One of the things I'm coming to realize as my career grows is that each principle becomes easier to follow if you do the previous one. Take Steadily adding value for example: it's almost impossible to do that if you don't have well-crafted software.
If things are still too abstract, I recommend the more direct message from Uncle Bob. The Programmer's Oath.
Software craftsmanship is about raising the bar of professional software development. It is a mindset where you accept the responsibilities of being a professional. You're constantly seeking improvement and teaching others about the craft, you take pride in what you do, and you are disciplined in the way you work. You're open to community as you believe that we grow stronger if we're together for the greater good.
All in all, it's a call for professionalism.