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.
Pleasant reading.
ReplyDeleteI started out as and long was a craftsman type in the extreme. Then slowly learnt to understand business value thinking and the idea of quality as "just good enough". I learnt its necessity, but still disliked it. Only in recent years, the agile ideas have brought peace to my mind - knowing that new iterations or new small orders in the future are probably/possible, after the current "just good enough" delivery, makes it bearable and even fun.
Good thinking and bright points, there are indeed pitfalls that you should avoid. I agree that Software Craftsmanship [SC] is not enough in itself and needs to be augmented.
ReplyDeleteOn the other hand though, Agile has been very much concentrating on people, like interactions and retrospection and processes. In my opinion the craft of writing software has been neglected. SC is an attempt to bring quality code back to Agile.
It does not mean that we should refactor until the code is perfect, instead we should attempt to hone our skills all the time so that it takes less and less time to write good and maintainable code.
I personally feel SC is an attitude that describes one's approach to software development and links like minded people together. You know, if I could choose, I'd rather work with a craftsman than "9-17 guy" :)
Jason has addressed this same subject in his blog: http://parlezuml.com/blog/?postid=989
Also Adewale Oshineye has good points on his blog: http://blog.oshineye.com/2011/01/software-craftsmanship-more-than-just.html
ps. keep your blog posts coming, this is good stuff!
Thanks!
ReplyDeleteAs you see, I am not against the things that craftsmanship advocates.
My concern is due to the separation of two concepts - "software developer" and "craftsman". To me those words are synonyms. And the separation itself is not healthy, to my mind.
First, you can blame PostgreSQL in everything if you are "just" a developer.
Second, if I were a young student, interested in a career in SW development. What message would I get after reading about craftsmanship? The holy thing where I can focus on my perfect code.
The understanding of the need of customer collaboration will come, but probably it will take years.
I spend time teaching students at the Tallinn University of Technology. And it is very hard to explain to students who yet study, that the need comes before the realisation.
We do not need to have a totally new thing as craftsmanship, just set up higher standards for existing developers
Really interesting thoughts! It was a pleasure to read them.
ReplyDeleteAnd I personally like a lot of passion in what you say.
I like every software developer become a craftsman. But people are different. Unfortunately, many of them just don't want to be craftsmen. They are quite happy to do their jobs just good enough to be quite good paid for. Those are professional programmers in the original meaning of word "professional". To be professional doesn't mean to be "good". It means to be "good enough to be paid for". So, it assures just some level of quality.
But there are others for whom software development is not just a profession, it's also a passion. They are passional programmers in contract to professional ones. They want to master their skills, to grow, to evolve. And they don't blame anything for their mistakes and even failures. At the end we are just people, we made mistakes. Then it's different if we learn from mistakes and become better, or if we just look to blame something or somebody else.
As you can see many IT projects are done by professional, not passional software developers. As a result there are such blaming to open-source products, and repeating the same mistakes time over time.
The cause of such situation is in society. Society accepts quality of professional programmers. Society agree to pay for even repeating failures.
And we are part of society. Let's not accept low quality products if there are better and affordable others. And finally then professionals will have to make choice to do their jobs with passion or to quit. In a ideal case. :)
I don't understant the discussion is software development either art, science or "crafsmanship". I wonder why software professionalists want to forget the engineering discipline?
ReplyDeleteAs stated in Wikipedia:
"Engineering is the discipline, art, skill and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge, in order to design and build structures, machines, devices, systems, materials and processes that safely realize improvements to the lives of people."
To me, this states the most important thing; improve the lives of others. I'm proud to be a software engineer.