There are many great books. Some of the books are called “life-changing” and some are just “classics”. We seek silver-bullets to make sense of the world. Revolutionary ideas that should rock our existence. Untold stories that explain what to do now. Many times we find what we seek for. A bitter disappointment might come a while after, realizing that a book did not have all the answers.
It is easy to talk about programming practices like how to start using TDD, best tools for user-story mapping or how to set up your continuous integration. These things are measurable and offer an easy way out. You can always say that you are Scrum, Kanban or whatever buzz-word is expected in your organization. However, if you dig inside, you’ll find that they are just developing code a bit differently and that does not affect an organization as the whole. Nothing actually changed.
Talking about values and the purpose often results in a philosophical discussion about good and evil. Sceptics draw analogies with religion, claiming that people who talk about that are fanatics.
To believe that something is true people need complex frameworks and formulas they do not fully understand. Pretending that you fully understand what is RUP or CMM makes you an expert in the field and sets you way above the rest who, actually, understand as much as you do. Keeping things simpler on the other hand creates an impression of amateurism and immaturity.
If you come home in the evening and tell that today at work you have been just nice to your colleagues, you wrote some test cases and talked to your users and decided that half of the things you planned to do are not needed - sounds like slacking off. Especially, compared to - having three meetings in one day, composing the project plan and having a serious discussion with the team about their productivity.
For the same reason, if someone asks me what do I do for living, I usually reply, that at work - I just make coffee (and that’s where this blog’s name comes from). Explanations sound very important and ambiguous. They create a flow of information that is anyway mostly ignored. Saying that - I develop software - basically states the obvious and as informative as my initial statement, but misses out the clue on one of my favorite drinks.
We need complexity to believe that it is true, important and... that it works.
Therefore, by reading the book or attending the master-class we expect magic to happen. Clarity to shine upon us. All problems solved. Just start using one simple thing and wait. Just start doing TDD or CI or whatever is popular buzz-word in your organization.
I do not argue, it is a good start if you’ve got nothing. The trick is, by starting using a totally new practice you see how it fits your needs and organization. You change it if you need it, drop it, or start doing something else besides that. But this part is already not in the “check-list”. However, not many go that far, but expect results instantly.
The need comes before action. You want to improve quality of your software and therefore you want to try out the TDD. That is just one option that you might to try out. Not vice versa - when you want to start doing TDD and see where does it take you. It definitely takes you somewhere, but you not necessarily want to be there, or tell the difference what has changed.
Understanding that the need comes first is fundamental. The good old excuse why agile software development does not suit someone’s company usually goes like that - our organization is unique, those things just cannot be implemented here, but we understand that they might actually work (in theory). In this case an organization is happy as it is. It is capable of paying the price for their own process and its stability. There is no need for it to change and that is totally fine. No point making revolution where it is not needed.
Books that do not discuss the programming practices, but talk about psychology and try to highlight the importance of the purpose are sometimes not taken seriously. In a nutshell, they talk about the fight between good and evil and of course everyone of us presumes that we are good already. It is hard to acknowledge that we do not know something or that we do not respect someone at work. We are great, and yeah, sometimes due to uniqueness of our organization we have to behave not the way we would like to. Bollocks!
On the other hand, the people, who do the actual work, always find the easiest way of doing it. If the purpose of the organization is to bill hours, people would produce hours and not necessarily the desired work. People will always find a way to hack the system, whatever it is. That does not seem as a good thing, but actually it is.
There is a way to combine the desire to do the simplest work possible and evolution of the organization. Let the people define how they want to work! People should feel responsible for the actions they are doing and see how does it affect an organization as the whole.
In “Implementing Lean Software Development” by Mary and Tom Poppendieck they discuss the principles of Lean organization. And they say that the most important principle is - Respect for the people. You can make this principle come true in your organization and you will discover all the rest. You can implement all other principles, but this one and you will fail miserably.
If you will ask people around you - do they respect people they work with? What is most likely answer you will be getting? In this case, why do we see so many organizational stupidity around us, why are not all organizations lean? Because the word “respect” has many layers and is understood differently. Saying “hello!” in the morning to everyone in the office is just being polite, that does not automatically show your gratitude. And in such quite abstract and humane matters we tend to think the best about ourselves.
There are, however, a few tricks that I would like to share, how I understand that principle. These things are quite easy to try out and they do not require mental paradigm shift (at least in the beginning). What you can be sure of - your organization will become better and will start evolving, just do not block it.
- Know your team
Hopefully, you know the names of your team-members. That is not enough. You should know their hobbies, favourite food, names of their children and spouses. After-all you spend the majority of your time with those people. You should know whom do you trust.
- Team events
Take your time to socialize with your team outside of the working hours. Go on to a road-trip. Climb a mountain, dig a cave. Go out to a local pub. You should see how people behave outside of the office rooms, do something stupid (or really clever) together. You do not have to become friends and buddies, but you should start caring for each other.
- Controlled failure
This is a good one. Seen many times in the literature. Noone knows what it means actually. If it is a failure - someone will be disappointed, there is no way around it. See the team taking the initiative and responsibility for their actions. If it is a production issue, let the team gather together and decide how to solve it together. Good news - you do not have to plan a disaster. Failures of one sort or another happen anyway in the team’s life. Make the responsibility visible.
- Visualize your life
Usually there is someone in the team who can draw. Visualize your decisions after the last retrospective. Put pictures from your last team event on a wall.
- Share achievements
Provide the financial information to the team how the product is doing. See the effect of each change you take to the live system. More over, if the organization is doing well, why not to share the success with everyone else? And you should not hide the failures. You all are in the same boat and if the boat is not doing well everybody should be concerned and help to get it back on track.
The tips above seem very straightforward. Probably even naive. However, there are few organizations who actually follow them. We always think about situation we are is and ourselves in our favour. So, I guess the next tip should be something like: be honest and fair to yourself and others. But, well... of course we are already...
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!
