Three Problems For The Next Era of Software Craftsmanship

In 1900 David Hilbert challenged the best mathematical minds to solve 23 problems. This set of problems has influenced the mathematics of the next century, leading to surprising discoveries. Probably the most shocking discovery was that axiomatic systems have inherent limitations.

Today, a different set of very bright people face a new era. 7 years of Software Craftsmanship has led to changes in the world of software. I can travel almost anywhere in Europe and find a community connected to software craftsmanship. People from the community authored books and articles. We stay in touch all the time thanks to modern technology such as slack, twitter, facebook and meetup. Local communities and companies organize conferences. And a brave member of this community started a newsletter, trying to guide us through the news in the field. We share what we love and we love to share.

I love this community. I feel at home in every meetup, at every SoCraTes or I TAKE unconference, on the slack channel and when discussing on twitter with people I’ve met through these events.

I’m impressed with what we’ve realized until now. I’ve been lucky to have a front seat row in this time of change. I was introducing people to software craftsmanship in 2009-2011 at various conferences, co-facilitated with Maria Diaconu first coderetreat outside US in 2009, facilitated a few first coderetreats including the one in Berlin. I remember how it was when I had to explain the basics of TDD, refactoring, the four elements of simple design or clean code in these communities. I’ve done it over and over. Then I heard other people were doing the same, and they started communities to practice these techniques. There were articles written about them. Inevitably, there was backlash, sometimes noisy, but it faded away and the community continued on its path.

I am now convinced that our basis is strong. It doesn’t mean we’ve convinced everybody. We don’t have to. Software Craftsmanship is bigger than any of us, and it’s growing strong. And I believe it’s time to deal with the hard problems of this industry.

Like David Hilbert in 1900, I’m proposing a list of problems that I believe this community of bright, motivated people should solve. Not because they are easy, but because they fulfill the promise of Software Craftsmanship: raising the bar of our profession.

Problem #1: Eradicate legacy code

Legacy code as we understand it today is code that we are afraid to change. Despite our best efforts of learning and practicing the techniques of our craft, there’s still a huge amount of legacy code in the world. As long as we don’t have to change it, it’s not a problem. But what if we do? What about the times when we have to rewrite it?

We have methods to deal with legacy code, and some of us enjoy doing that. But the truth is these methods are slow and painful. And now, hundreds of thousands of developers are writing more legacy code. Can we win this battle? Can we find the cure and the vaccine for legacy code?

Problem #2: Raise the standard of proof

The difference between a software engineer and a bridge engineer is that the bridge engineer knows the scientific laws that apply to the bridge. I imagine bridge engineers discuss things like: resistance of materials, weight distribution, forces that act on the bridge. Software developers, however, discuss personal experiences, preferences and opinions.

Don’t get me wrong: this is not an attack on our techniques. I love TDD. Refactoring is like breathing to me. Domain modeling helped me again and again.

In order to raise the bar we have to recognize a painful truth: the standard of proof in software development is very low. Just because TDD helped me or my team doesn’t mean it helps most developers or most code bases. We need more investigations, more data and more scientific experiments to make this assertion.

So can we start collaborating with the scientific community so that they offer us the proofs we need? Can we start providing them with volunteers for scientific experiments and with real code bases to analyze? Can they raise their standard of experiments once we build bridges between industry and academia ?

Problem #3: Educate the next generation on real world software development techniques

When I finished university, I had no idea how to manage large code bases. I didn’t know how to design software. I learned about coupling the hard way, by making huge mistakes in the first projects I developed. I was lucky to have a mentor who taught me unit testing, software design and how to write readable code.

Today I’m the CTO of a startup and I’m involved in hiring developers. We start from the premise that they won’t know these things, and that we’ll have to teach them.

There’s an obvious disconnect between what we need from professional software developers and what they learn in school. Graduates should know TDD, the four elements of simple design, SOLID principles, ways to avoid mistakes, pair programming, code review etc. Graduate bridge engineers know at least the techniques to use to avoid the bridge from collapsing.

Can we introduce these real-world techniques into the curriculum? Can we write the curriculum and give it to the teachers to freely use, change, and adapt? Can we find teachers to run a pilot program and prove that it works and helps the industry?

Conclusion

We are at a turning point in the development of the Software Craftsmanship movement. I’m proposing three problems we should focus on to really fulfill the promise of “raising the bar of professional software development”. These are not easy problems. There isn’t any one lone person who can solve any of them. Instead, they need focused effort from the community for a longer period.

This list doesn’t mean I think we should stop doing what we’ve done in this community until now. It’s not an either/or proposal. In fact, it’s OK if none of these problems interest you. In that case, I urge you to make your own list public, so that other people join your quest. More important than the list is the conversation that I hope it will generate.

What’s Next?

The goal of this article was to state a list of problems. I hope that it will generate enough interest so that we can start discussing possible solutions. I have some ideas for starting, but very limited time for implementation. If you’re interested in any of the problems, let’s chat on slack, twitter, email etc.

  • Pingback: The aftermath of ‘the three problems’ blog post – alexbolboaca.ro()

  • I don’t think you can scientifically prove the value of TDD. Every cycle of TDD is in the context of the code AT THAT POINT IN TIME. And at that point in time, it depends on the feedback you’re getting for that context, and it depends on that person’s brain in what they know to apply at that time during red | green | refactor. There are too many factors in TDD, benefits, that are based on short cycles and many variables, you can’t scientifically prove that it doesn’t work or does work. It’s just not that simple to quantify.

    • Thanks Dave. Good point indeed.

      Knowing that something cannot be proved is also good for knowledge. My general point is that I’d like to see these arguments, this debate based on facts and logic rather than emotions and opinions.

      And if it’s true that we cannot prove generally that “TDD is good” (which is, I accept, a very fuzzy remark), another good question is: Could we split TDD in smaller things that we can prove, or does it only make sense as a whole thing? For example, does eliminating duplication lead to better designs (again, very fuzzy, better how?) or not? etc. Do shorter cycles make a difference even when not using TDD? etc.

      Science works slowly, but it’s the best way of understanding the world that we have. Gravity still has mysteries, despite being the subject of famous breakthroughs from some of the best scientists who ever lived. Yet, we understand the universe better because it was studied. The idea that it’s hard or impossible to completely prove or define something shouldn’t stop us from advancing as far as we can.