The aftermath of ‘the three problems’ blog post


In my previous post, I set out three problems that I believe software crafters worldwide should work on in the years to come to fulfill the promise of “raising the bar”. This is a quick update on its aftermath.


The blog post generated 430 views at the time of this writing, which you can see as low or high. I see it as “a few hundred people seem attracted by this idea, although we don’t know how many want to act on it”. We can work with that. The history of innovation shows that we don’t need more than a few people to work on these problems. It’s much more important to find the right group of smart and motivated people who are interested in solving them. The rest will follow.


The blog post generated a few reactions. Here’s a quick list.

Eradicate legacy code

Despite it being the first on the list, and sounding crazy, I was surprised to get a total of one reaction. I don’t know how to interpret that, but I have a few hypotheses:

  • we are so used to working with legacy code that we think it’s normal
  • we can’t imagine a world without legacy code
  • we don’t think it matters if we have legacy code or not

I’m not sure which one is true, so let’s see what my friend Felix PleČ™oianu had to say about it:

I have to say that I agree with him. Writing less code is always a good idea. It benefits everyone. Yet we aren’t doing it enough.

I have more things to say about this problem, but they will have to wait for another blog post.

Raise the Standard of Proof

I know from previous discussions that software developers tend to think it’s impossible to include science in software development. One reason was best expressed by the same Felix:

I’ve known Felix for a long time, going back to the Star Trek fan club and to a sci-fi writer’s club. He has imagination, and he has a healthy interest in science. Yet, this is how he perceives academia. And, again, I have to agree with him in most part.

Software development of today resembles a lot with psychology in the 19th century. Psychology has had a very difficult relation with science. Running repeatable, objective experiments seemed impossible when it comes to the human mind. It seemed like the only way of getting to understand it was by asking the subjects, which obviously wasn’t objective.

Things have evolved since. Behavioral psychology, behavioral economics and cognitive sciences have allowed a deeper insight into the once subjective world of the human mind, through truly scientific experiments.

I know that there are scientists looking into running experiments closer to the practice of software development. We know little about their work, and they have little access to the industry, thus running experiments on a handful of students. To get the results we need, we need to help them.

That’s why I was very happy when I saw a new “science” channel was created on the Software Craftsmanship slack team, and that conversations on science intensified.

Educate the Next Generation Of Developers

Hugo Estrada had an interesting contribution to this topic:

It turns out there is a course that touches on our practices and on managing large codebases. Really cool! More things need to happen, but it’s a good start.

What’s Next

I plan a few more blog posts on each problem. But none of these problems can be solved by one person. We need to team up.

The first step is to make your interest public. To make it easier for you to reach out to interested people, I’m proposing the hashtag #nextInSwCraft. Talk to you there!

Add comment Reflections on design, craft and software

A new home for merging ideas about design

It is my strong belief that software design can learn a lot from other design disciplines. I wrote blog posts, a book and did talks on this topic, and it was time to group them all together. These ideas have now a new home: My plan is to add more blog posts there, and to involve other people doing work in this area.

Read My Book “Usable Software Design”

How UX techniques can be applied to software design to develop software better (given that the developer is the user of software design).

Read My Book “Coderetreat Hosting And Facilitating”

Learn how to facilitate and host a coderetreat from two of the most experienced coderetreat facilitators.