This one was in wait for a long time. Now I cannot postpone it any further, so I even consider to give blogging a chance. As a first real blog-post it will be pretentious, long and maybe even too emotional. In fact, everything you need in your first blog-post. Let’s get some coffee and here it goes...
Many individuals and even whole companies started advocating craftsmanship - an approach in software development focused on producing high quality software. Craftsmen master the skill of perfect software creation by constant practise, peer evaluation and many more. Each practice becomes a habit close to reflexes how to write tests before the code, execute them and continuously deploy the increment.
Jolly good! We want our people to be professional at what they do. To constantly improve skills, write good tests and software. I do, however, have several concerns, which I want to share with you.
Let’s look a bit back into history. Craftsmanship originates from Extreme Programming. An agile movement that was born in the US as a rebellion to the existing software development practices. The key feature was there to skip huge upfront designs and endless discussions and start writing software. Implement the easiest and working thing first and then refactor-refactor-refactor. Craftsmanship, in this sense, is a huge leap forward by setting high requirements to developers how they work and what they produce.
It seems to me, that somehow it became normal and, even worse - allowed, to do a sloppy job in software development. Considering the amount of pay even young specialists get, this is simply mind-blowing! In no other industry you would go away (and stay in business) with excuses like: customer changes his mind constantly, unexpected things happened or as simple as - it was too hard.
After parliamentary elections in Estonia, a company that was supposed to provide an IT solution to follow real-time voting results, blamed PostgreSQL database in the system crash (sorry, the article is on Estonian). Whole country had to follow results from Facebook and Twitter, which somehow stayed alive. Obviously, it was not that the company did not test the system properly. It was just way out of their control. Accepting the failure could have lead to some actions, that would prevent this from happening in future.But now the blame is delegated to complexity and open-source software. No actions required.
Come on! Get real! You would not want a brain-surgeon to hunt post-release bugs, won’t you? Also, you wouldn’t hire a young surgeon who just finished reading a book on how to perform a surgery (“Surgery for Dummies” or “Crash Course into Brain-surgery in 21 Days”) and let him lead one on his own. In almost all other areas there is a clear definition of quality. You can distinguish quality shoes, quality car, etc. The subject of software development is just too vague to tell what a quality product actually is.
In this light craftsmanship is awesome. Propagating the idea of clean code and pure design. Constantly mastering the skill.
However, craftsmanship also states the obvious. You expect people to know what they are doing and do it well. Is it even an option?? There simply should not be some special classes of people: the ones who can do job well and the ones who can skip this part.
So, why do I care? Let’s all become craftsmen?! Well... yes and no...
Let’s briefly visit history again. The Toyota Production System or Lean Production originates from Japan. Nowadays the buzzwords already mixed-up and not many distinguish the difference between Lean and Agile. However, Lean-thinking is very different. It is about understanding the domain, focusing on the whole and growing people. Compared to “do now, refactor later” attitude in Agile. Many believe that Lean production is about eliminating waste. But what it is really about is delivering value. This is exactly what craftsmanship does not consider - how to deliver value to the whole.
Probably you need another cup of coffee right now and I will explain.
If you will ask your customer, what does he need: a well-written software or his problems fixed (that at some times might be solved with a software). Chances are he wants both. But it is quite safe to assume that he mostly wants his problems fixed. Customer wants his business to grow, wants to spend less time on customer support, to have a faster development time to production, etc. No one wants a piece of software for the sake of just owning it; it has to support your business.
The fact of the matter is that not all problems should (or can) be solved by writing/changing software. To achieve higher performance you do not have to optimize your code for months. You can add more servers, increase bandwidth, simplify the configuration. And maybe this will be enough! This will be cheaper, faster and safer for you. Delivering value to your customer is more important than writing perfect software!
Let’s consider following example that is quite absurd on many levels. Imagine a situation - two independent companies develop the same software product for the same customer. One of the companies is the craftsmanship company and the other is not quite. The price is almost the same. Frankly, we are not always sure that we develop the right thing. In this case if we have to throw away the complete solution, then solutions from those two companies are just the same: they are equally useless. However, when these two solutions are different. One of them is perfect, but it is the wrong thing. The other one is not that remarkable, but does exactly what customer wanted. Which solution will you chose then?
Changing code is geeky. People, related to technology, basically - we are, tend to over-complicate things. It is much more fun to learn something new, dig into the code and make it happen. Instead of understanding the problem first and applying a solution that is maybe not favorable for you personally.
In my opinion, the real craftsman should be able to tell to the customer that he should not write any line of code. That problem should be addressed by other means. Otherwise, developing a software that is useless (although very perfect) leads to the worst case of Mortgage Driven Development that Jason Gorman talks about. When people develop software because they have to pay their bills and not because customer actually needs it.
What craftsmanship has - an isolation, focus on the code writing. What it lacks - the customer collaboration.
That’s the thing. No craftsmen will ever tell you that they do not collaborate with customers. Of course they are! They develop the software faster, get the feedback faster and introduce the change also faster. The only problem is that they somehow forget about that part when they talk about their job. This is the boring part, not that exciting and geeky. But people listen. They perceive it as a choice - you can talk to your customer or you can just write code.
Considering that there are craftsmen, that also implies that there are - non-craftsmen too. It seems like there are different career paths - you can do a good job or you can be sloppy. You can focus on code writing and tell everyone who asks “my job is to write a great software and not to judge its necessity”. But is it really what we want? Can you tell that such a team is truly cross-functional? There is no choice! You must be professional at what you do!
On the last note, when I started to think, what would I personally value the most in a software craftsman. I’d like him to:
So, do we really need that distinction? Why don’t we keep calling people “Software Developers”? Because that is what we are.
Many individuals and even whole companies started advocating craftsmanship - an approach in software development focused on producing high quality software. Craftsmen master the skill of perfect software creation by constant practise, peer evaluation and many more. Each practice becomes a habit close to reflexes how to write tests before the code, execute them and continuously deploy the increment.
Jolly good! We want our people to be professional at what they do. To constantly improve skills, write good tests and software. I do, however, have several concerns, which I want to share with you.
Let’s look a bit back into history. Craftsmanship originates from Extreme Programming. An agile movement that was born in the US as a rebellion to the existing software development practices. The key feature was there to skip huge upfront designs and endless discussions and start writing software. Implement the easiest and working thing first and then refactor-refactor-refactor. Craftsmanship, in this sense, is a huge leap forward by setting high requirements to developers how they work and what they produce.
It seems to me, that somehow it became normal and, even worse - allowed, to do a sloppy job in software development. Considering the amount of pay even young specialists get, this is simply mind-blowing! In no other industry you would go away (and stay in business) with excuses like: customer changes his mind constantly, unexpected things happened or as simple as - it was too hard.
After parliamentary elections in Estonia, a company that was supposed to provide an IT solution to follow real-time voting results, blamed PostgreSQL database in the system crash (sorry, the article is on Estonian). Whole country had to follow results from Facebook and Twitter, which somehow stayed alive. Obviously, it was not that the company did not test the system properly. It was just way out of their control. Accepting the failure could have lead to some actions, that would prevent this from happening in future.But now the blame is delegated to complexity and open-source software. No actions required.
Come on! Get real! You would not want a brain-surgeon to hunt post-release bugs, won’t you? Also, you wouldn’t hire a young surgeon who just finished reading a book on how to perform a surgery (“Surgery for Dummies” or “Crash Course into Brain-surgery in 21 Days”) and let him lead one on his own. In almost all other areas there is a clear definition of quality. You can distinguish quality shoes, quality car, etc. The subject of software development is just too vague to tell what a quality product actually is.
In this light craftsmanship is awesome. Propagating the idea of clean code and pure design. Constantly mastering the skill.
However, craftsmanship also states the obvious. You expect people to know what they are doing and do it well. Is it even an option?? There simply should not be some special classes of people: the ones who can do job well and the ones who can skip this part.
So, why do I care? Let’s all become craftsmen?! Well... yes and no...
Let’s briefly visit history again. The Toyota Production System or Lean Production originates from Japan. Nowadays the buzzwords already mixed-up and not many distinguish the difference between Lean and Agile. However, Lean-thinking is very different. It is about understanding the domain, focusing on the whole and growing people. Compared to “do now, refactor later” attitude in Agile. Many believe that Lean production is about eliminating waste. But what it is really about is delivering value. This is exactly what craftsmanship does not consider - how to deliver value to the whole.
Probably you need another cup of coffee right now and I will explain.
If you will ask your customer, what does he need: a well-written software or his problems fixed (that at some times might be solved with a software). Chances are he wants both. But it is quite safe to assume that he mostly wants his problems fixed. Customer wants his business to grow, wants to spend less time on customer support, to have a faster development time to production, etc. No one wants a piece of software for the sake of just owning it; it has to support your business.
The fact of the matter is that not all problems should (or can) be solved by writing/changing software. To achieve higher performance you do not have to optimize your code for months. You can add more servers, increase bandwidth, simplify the configuration. And maybe this will be enough! This will be cheaper, faster and safer for you. Delivering value to your customer is more important than writing perfect software!
Let’s consider following example that is quite absurd on many levels. Imagine a situation - two independent companies develop the same software product for the same customer. One of the companies is the craftsmanship company and the other is not quite. The price is almost the same. Frankly, we are not always sure that we develop the right thing. In this case if we have to throw away the complete solution, then solutions from those two companies are just the same: they are equally useless. However, when these two solutions are different. One of them is perfect, but it is the wrong thing. The other one is not that remarkable, but does exactly what customer wanted. Which solution will you chose then?
Changing code is geeky. People, related to technology, basically - we are, tend to over-complicate things. It is much more fun to learn something new, dig into the code and make it happen. Instead of understanding the problem first and applying a solution that is maybe not favorable for you personally.
In my opinion, the real craftsman should be able to tell to the customer that he should not write any line of code. That problem should be addressed by other means. Otherwise, developing a software that is useless (although very perfect) leads to the worst case of Mortgage Driven Development that Jason Gorman talks about. When people develop software because they have to pay their bills and not because customer actually needs it.
What craftsmanship has - an isolation, focus on the code writing. What it lacks - the customer collaboration.
That’s the thing. No craftsmen will ever tell you that they do not collaborate with customers. Of course they are! They develop the software faster, get the feedback faster and introduce the change also faster. The only problem is that they somehow forget about that part when they talk about their job. This is the boring part, not that exciting and geeky. But people listen. They perceive it as a choice - you can talk to your customer or you can just write code.
Considering that there are craftsmen, that also implies that there are - non-craftsmen too. It seems like there are different career paths - you can do a good job or you can be sloppy. You can focus on code writing and tell everyone who asks “my job is to write a great software and not to judge its necessity”. But is it really what we want? Can you tell that such a team is truly cross-functional? There is no choice! You must be professional at what you do!
On the last note, when I started to think, what would I personally value the most in a software craftsman. I’d like him to:
- get along with people
You can be awesome genius, know everything, but if it is impossible to work with you, if you do not listen and do not help - you are useless - have the ability of learning new technologies and a track record of doing that
Learning new things is fun, you shouldn’t know everything, but you should have a force inside of you that strives for new things and strives for improvement, perfection if you like - be responsible
finish what you start, accept mistakes and do not let others down
So, do we really need that distinction? Why don’t we keep calling people “Software Developers”? Because that is what we are.
