Following Hakuna Matata or always striving for perfection are two very different ways of living your life. In the short term Hakuna Matata (which means “No Worries”) looks tempting, but there’s also happiness to be found in the strive for perfection through a continuous improvement mindset.
Image courtesy of Wikimedia Commons
Earlier this year I went on a skiing vacation for a week. Looking at the people in the slopes, there were many different styles of skiing. Some were good, some were bad. Some looked concentrated, some looked happy. But I think that everyone enjoyed being there. During the week I thought about different mindsets for skiing (mindsets that are also applicable to programming, don’t worry – this post is about programming and not only skiing).
I think that by just watching the people skiing, they can be grouped into four categories that reveal their mindset. Are they living by Hakuna Matata or are they continuous improvers that always want to learn? Those different mindsets are important when you form a software development team.
A team in trouble would probably say that they would very much welcome expert help – but would they really? Are they ready to face the brutal facts of the state of the project?
An important part of the psychology behind forming a team is the distinction between “we in the team” on the inside and the rest of the world on the outside. To some extent this is good: A team with a strong spirit will be able to handle any obstacle in the outside world. But in some cases it can backfire, when the team stop looking at themselves, but only look at the outside world to explain problems. In fact; when a team is in trouble, they will in most cases first find external reasons for the trouble.
The customer demanded a huge change, with a very tight deadline.
The architecture in this legacy system is so hard to work with that it takes forever to make changes.
The first one is external – the customer asked for a change, but what about the second? It might be that the system was recently handed over to the team in which case it is external. But what if the team has been in charge for maintenance of the system for a year? The fact that the legacy system that they took over had an architecture that’s hard to work with is external. The fact that they haven’t done anything to it in a year is at least partly internal to the team.
Looking deeper at the first example that might be internal as well. The change may be huge to the team’s standards, but if they had a flexible architecture and proper automated tests in place it might not have been such a big issue. If the team has worked in isolation for too long, they are less likely to see that their architecture is inflexible and that their testing is sub standard.
I know that you are a top rated developer. In fact I know that everyone reading this is rankning among the top 10% of all developers. How I know? Because 90% of all developers never read a programming blog, never make any side projects to learn something new, never spend any time or effort outside work hours to improve.
Many years ago, Tom Demarco and Timothy Lister wrote in Peopleware:
The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one. That fact is horrifying for anyone concerned about the quality of work in the field, for folks like us who write books, it is positively tragic.
Back when they wrote that, books and not the web was the main source of information. Nowadays blogs and other web resources have largely overtaken books as the main source of information. Did that solve the problem? Do people read more? In my experience: Unfortunately not. The basic pattern persists: Most developers don’t care.
