UPDATE 12 November 2018: Emily has reached out to me after reading this blog post, and she has pointed out that I misrepresented her position in this blog post. Specifically, that I made her arguments sound weak.
After reading her feedback, I realized my mistake. I apologize for any ill effects it might have caused. I have also updated the blog post to better reflect her position.
If you have read this blog post before, I’d like to state that her argument for companies investing in practice time for developers has a strong connection with business reasons, unlike I mistakenly stated before. I quote from her article: “Giving developers time to learn makes good business sense in a competitive world where attracting and retaining skilled people is an advantage in the marketplace.”
And a personal note: I was on the other side of the argument in the past, and it’s been hard for me to reach out. I have therefore to thank Emily for reaching out, and for the civil way in which we’ve solved this problem. I realize in hindsight that it would have been much better if I offered her and the other participants to the debate a chance to comment before publishing this post. I will try to do better next time.
I’ve recently had the opportunity to be part of a debate on technical practices, along with Emily Bache, Sandro Mancuso and Robert C. Martin, at the London Software Craftsmanship Conference. The debate took an interesting turn when Emily and Bob had an exchange on when should the developers practice their craft: at home or at work?
If you watch the video, you will notice that I didn’t participate in that part of the debate. The main reason is that I didn’t have a clearly formulated opinion at that time.
Since then, Emily has published a well thought article about the topic, which prompted me to clarify my own thoughts. It’s only fair to write it down and add my own two pence to the story.
But first, a bit of context.
How I Learned My Craft
I wrote and talked before about my journey, but I think it’s only fair to the readers to be honest about my experience and my possible biases.
The short story is that I was lucky to have a few mentors but that most of the things I know I’ve learned by practicing at home, through remote pairing, or in communities.
I was lucky to have a mentor from Belgium who insisted on following strict rules for writing code, testing, and designing for a C++ application at the beginning of my career. He gave us a list of books that we not only had to read, but to follow as strictly as possible. He was reading every line of code and I would often get in the morning an email detailing all the mistakes I’ve made. It wasn’t a pleasant experience; but once I got over the initial challenge, I realized how much I had learned. He trusted me to become the team leader for the team, although I had no experience in that role. This experience has shaped my knowledge of software design, unit testing and technical leadership.
Years later after this experience, I was very lucky to have Maria Diaconu as a coach, to meet Corey Haines, to have many conversations with JB Rainsberger whom I consider my second mentor. Another fundamental encounter for my professional life has been the original and down-to-earth thinker of our days, David Hussman, who unfortunately died a few months ago. (Dude, I miss you).
But these encounters were mostly important because they gave me a direction when I was missing it. None of these people gave me recipes, but all of them opened my mind.
I had to practice. And I did: at home, in cafes, in hotels, in airports and airplanes, in communities, through remote pair programming etc. Sometimes, at work, especially after I started working for Mozaic Works where high quality is the norm.
I’ve learned a lot of things alone. Was it nice? Was it fair towards me? I don’t think in those terms. I love programming. I love my craft. If I weren’t practicing at home, I would be reading about programming, or trying various tools, or other programming languages, or installing and configuring various applications. I am a builder at heart, and I don’t feel good unless I try out things.
But why do we need to practice at all? Why can’t we just know how to develop software?
The Big Problem
There is a big problem at the core of software development today. It’s not that the industry is young; that’s just an excuse we’re telling ourselves. It’s not that software is fundamentally different from anything else humanity has ever done; that’s just ignoring that programming is just designing using code as a prototyping material. It’s not even that there are too many programmers, although that may be a contributing factor.
The problem we have today is that we know how to build software faster & better, but most programmers can’t apply the practices needed to do that, and there’s often little incentive on doing them.
The only reason we’re discussing whether we should practice at home or at work is because there’s a deficit of skill in the industry. If 80% of the programmers were skilled in clean code, all the XP practices, all the reliability practices, risk assessment, secure coding, then we wouldn’t have this debate. I don’t want to presume, but I think I can safely assume that both Emily and Bob agree with this.
The Disagreement
The big disagreement between Bob and Emily, given this problem, is about who should invest into growing the developers skill.
Bob’s argument comes to individual responsibility. My best rendition of the argument is the following: it’s your job to be the best professional you can, and practicing is the way you become the best professional you can, so you should practice at home.
Emily’s argument is centered around inclusion. Again, my best rendition of the argument is: not everyone has the time or the possibility to practice at home; therefore it would be elitist to allow only time at home for practice and companies should invest in their employees to ensure their best results.
During the debate, another issue was about the focus of the trainings. If you count on the company to grow your skills, what skills will they grow? I can only relate to this question, since I have often seen as a coach in large companies that their training focus was on skills that were important to the company rather than opening options in the careers of programmers; for example mainframe development or specific off-the-shelf programs.
As I mentioned before, my life experience is closer to Bob’s view. I have always tried to learn the most so that my skills are relevant to the industry. I love to do that, so for me learning and practicing programming is an enjoyable part of life.
However, I appreciate the possibilities for learning that I have in Mozaic Works, and I’ve tried to create a great learning environment for our development team. But that’s not necessarily easy to sustain financially.
There’s more to each of their argument.
Bob’s solution is based on the idea that every programmer will suddenly become passionate and will want to get better. His internal belief seems to be that programmers will see the light if only enough people will show it to others. This belief has brought us the Software Craft movement, for which I’m grateful. But I don’t believe it will fundamentally improve the industry.
Emily’s solution is for companies to invest in programmers because, I quote: “Giving developers time to learn makes good business sense in a competitive world where attracting and retaining skilled people is an advantage in the marketplace.” I agree with this argument in the current market context. Since many companies struggle to find programmers, it makes sense to add more incentives, and training is one of them. But have ten times the number of programmers overnight and these perks will disappear as fast as you can say “craft”.
And that brings me to the main reason why I believe neither solution is good enough: we’re dealing with a systemic problem.
Systemic Problems Require Systemic Thinking
Both Bob’s and Emily’s proposals fall short because this is a systemic issue. It won’t get solved with local solutions, but it requires a systemic approach. I will use the “repeated why” technique to figure out if we can find other solutions.
Why do we have the skill deficit in the industry?
One, there is little incentive for companies to avoid issues with their software. Why don’t companies have these incentives? Because the consequences of mistakes are too small. Why are the consequences so small? Because this industry somehow managed to convince users that bugs are inevitable and they should live with them. (Sure, there are specific application domains where these incentives exist, and the programming practices are often different.)
Is this the truth? I would argue that there are indeed bugs that are very difficult to catch or predict, and that some of them will escape even the most advanced methods we know today; but I estimate those bugs to about 1-3% of the current population.
Two, the education of programmers is too short and not good enough.
I’m a diplomat engineer in software, but when I finished the university I knew very little about writing code that works and refactoring legacy code. These are two fundamental skills that would be unthinkable for other types of engineers.
Why is the education lacking? Because the people teaching the curricula have little industry experience. Take this with a grain of salt; I understand from friends that universities have improved their curricula in the past years, but there’s still a lot to do.
Even if it’s the best education, it’s too short – we should probably consider a system that allows programmers to go back to school every 5 years or so. Looking back at my career, it took me about 10 years to understand and embrace functional programming, although I took the course in university; some things just require years to pass in order to appreciate them at their just value.
The apprenticeship model is also interesting, but it has fundamental issues when financed by one company. Nothing is stopping people from leaving once they upgraded their skills and are thrust into projects they don’t particularly enjoy. From a business perspective, this is a huge financial risk.
I criticized the positions of both Bob and Emily, so now the question is: is there a solution?
Possible Solutions
Since we’re dealing with a complex adaptive system, we cannot predict its future state. We can however make experiments and see whether it’s heading in the right direction or not.
First, can we change the incentives of companies? Not really. There are a few scenarios that might produce the change. One is government regulation, for example involving mandatory insurance of software once it passes a certain number of users (I stole this idea from Bruce Schneier). Second is if consumers start revolting against bugs. Third, and the most likely one, is the rise of viable competition that proves fewer bugs are possible. So I guess the experiment would be to start your own companies who sell viable products using all the good practices. I doubt many of you will, and I won’t blame you, since this is both difficult and risky.
How about education? Here are a few experiments:
- Reaching out from the industry to the universities to build curricula that is closer to the needs of the industry
- An apprenticeship program that’s paid through contributions from multiple companies, for programmers of all ages
- Professional associations that tend to the career needs of their members and who are accepted by companies (like for doctors, lawyers etc)., funded through individual contributions and donations
- A new type of university for programmers, who supports them wherever they are in their career and that becomes an industry standard.
Are there other experiments we can run? Most likely yes. Please come up with more.
Conclusions
Are these solutions good enough? Probably not. But my real aim with this blog post was never to be the smart a$$ who comes with the best solution nobody thought about.
Instead, I wanted to share a systemic perspective on a problem that affects the industry that I work in. I hope this perspective will help you move towards realistic solutions that will benefit us all.
And if there’s one thing that you take away from this: sometimes we see symptoms of systemic problems, and systemic problems require systemic solutions.