The subject of this blog-post is not new. There are many blogs that simply scream about it. Personally, I cannot offer anything more radical than what was already said before me. Repetition is the mother of learning, so hopefully someone will listen.
One word, that seriously hurts my ear is - the “R” word. Resources! I do not hold anything specific against the word itself in any other context. However, when it is used to describe people - this is unbearable! It associates with something that is not alive, interchangeable, or just a thing. The least to say - it is very offensive.
According to wikipedia, a resource - is any physical or virtual entity of limited availability that needs to be consumed to obtain a benefit from it.
Do not know about you, but I think it is terribly wrong to think about people in the light of that definition. Especially, if someone would think like that about me.
Let’s get deeper. Wikipedia provides us with the definition of the Human Resources, and human resource management - a strategy that should maximize return on investment in the organization's human capital and minimize financial risk.
Probably, on some weird level this is right. However, this is not everything what we expect from the people. We want people to grow, make decisions, become more responsible, educate others, act on behalf of their benefit that would also benefit the organisation. We do not want to consume them to maximize the return of investment. People form the organisation itself and do the actual work.
People are not resources - they are live human beings! They breath, eat, feel, have different mood. They have non-deterministic behaviour and are not always rational. Same person in the same situation appearing again and again can behave differently.
When you treat a person the same way as you would treat, let’s say, a wood, coal or petrol, you would expect it to behave in the similar way. If you take a piece of wood from one campfire and bring it to another - it will burn, as it did before. If you take a petrol from one car and pour it into another, the car will work. But this analogy does not simply work with people. When you change a team, you cannot expect it to work the same way it just did.
You cannot treat people as something that you can only consume. In my opinion, you should only consider what you can give to the people. Let them do what they really like to do, be creative, to be heard, to have a time to live a life.
For a second, it might feel like it is a lot of freedom. But if you think about it, people is all you’ve got. And if you treat them right and if you guide them right - people are very grateful.
Treat people as people!
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:- 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
Even though those are not technical skills, somehow, I suspect, craftsmen would appreciate those qualities too.
So, do we really need that distinction? Why don’t we keep calling people “Software Developers”? Because that is what we are.
Last week we had a chance to visit Scan-Agile conference in Helsinki. It was organized by Agile Finland that is a local community that supports agile movement. As it turns out, we already know a lot of people from there, so for us it was also an opportunity to meet with old friends.
This conference is organized for the third time. Last year they skipped due to some local problems and conflicts with similar conferences at the same time. We visited all of them and they always have been different and great.
The Scan-Agile 2011 conference had slightly different organizational crew and different focus group. As they said it themselves, the focus was shifted more on developers and during many talks you could see guys writing code.
During the opening speech we were pleasantly surprised when organizers welcomed Agile Estonia. It was a way cooler than conference sponsors were introduced! Strange feeling to get attention from the whole audience and I even did not have my first cup of coffee yet. :)
One of the highlights for us was Jason Gorman's talk about craftsmanship. At the end he introduced a new concept - refuctoring. Its goal is the opposite of refactoring. It goes as a challenge, when developers change (refuctor) the perfectly written code into something that is hardly readable and easy to change. Not only it is a lot of fun, the idea behind it is that only really skilled professionals can make the code really stink. Refactoring is refuctoring, but with different objective. But the thoughts about craftsmanship call for a separate blog-post.
It was also nice that conference had four tracks. Two tracks for talks and two for workshops. You cannot really get bored there and find something that appeals your interest. Workshops as a separate track is just a wonderful idea. There are many cases when you need to try something yourself and learn by doing it.
Unfortunately, some workshops could not fit everyone who wanted to come. For instance Joseph Pelrine’s talk about self-organization was so popular that people had to listen to it on their feet including myself. That did not make the impression any worse. Very inspirational and deep thoughts there, that cannot fit even one and a half hour time slot.
All in all it was a great conference. Like usually there was a lot of socializing after the event. This is the case when you return from the conference full of new ideas and connected to many wonderful people.
Thanks a lot Scan-Agile and see you next time!
