Not-done-here syndrome is mental laziness

The provocative title of this post, is one of the many great points made by Jessica Kerr at the morning keynote at today's GOTO Copenhagen. The keynote was called "Forget Velocity, Let's Talk Acceleration"

Jessica Kerr gave an energetic talk, which covered a lot of ground - enough for several blogposts, which I hopefully will get around to write in the next few days. This blogpost, however, will focus on the point expressed in the title.

Most of us have come across developers, some of them quite good, who suffered from the not-invented-here syndrome, i.e. they'll rather spent the time it takes to write the code themselves, instead of using existing code written elsewhere.

There are probably cases where it makes sense to write it yourself, rather than reuse or modify code made elsewhere, but it is rarely the case. Usually, it takes a lot of time and effort, and it ends up being not as good as the code you could have gotten elsewhere.

I've seen it happen from ORM over logging frameworks to even an entire Ajax framework.

I have always assumed that this happened because of the arrogance of the developers in question, who thought they were better than everyone else.

Not so, says Jessica Kerr - it is due to mental laziness.

This is based on the principle that programmers find it easy to invent new things, but hard to analyze existing code. This means that it is mentally easier to write a framework yourself, rather than take in a framework written by someone else, and get to understand it.

Or put differently, the mental energy you have to spent on writing the framework yourself is less than the mental energy you have to spent on learning a new framework.

Thus, people who suffer from a not-invented-here syndrome, are mentally lazy.

This resonates with me.

One of the followup points that Jessica Kerr made, was that if you look at something, and think that you should rewrite it, then you should stop up, and make sure that it isn't just mental laziness that is speaking.

It is often necessary to rewrite existing code, but rarely to the extend that developers and architects wants to do so. Rewriting the code, however, spares the developers and architects for the work they need to put into analyzing and understand the current code beyond the basic level.

So, in conclusion, rewrite code if necessary, but make sure it is really necessary, and not just done to avoid the hard work of analyzing the existing code.

Disclosure: This blogpost mentions the GOTO Copenhagen 2017 conference. As a blogger who blogs about that conference, I get a free ticket from the organizers. The organizers don't dictate what I write about, and don't have any say about the content of the posts.  

Progress is slow if you ignore the past

I have just returned from spending my Sunday at the 1st day of the 21st Danish GOTO conference (not all of them were named GOTO, there has been some name changes over the years).

As expected, it was a great day, with some great talks - if you want to see my running commentary on those talks, go look at my Twitter stream @kriswager

Most of the talks I attended were great, but I especially enjoyed the keynote Engineering You by Martin Thompson, and Dan North's talk Beyond Developer, both of which focused on how software engineers/developers should expand their knowledge and become better programmers.

Both of these talks started out by looking back at the roots of the field. Dan North took us all the way back to Ada Lovelace:

Taking us back to the roots. @tastapod starts his talk with going back to Ada Lovelace #Gotocph pic.twitter.com/exmt9OcroE

— Kristjan Wager (@kriswager) October 1, 2017

Martin Thompson, on the other hand, only took us back to 1967, where "software engineer" was coined. He spent some time on the 1968 Software Engineering conference sponsored by the NATO Science Committee, where many of the issues raised, and experiences expressed, would fit well into a conference today.

It is interesting how little we have learned in 50 years. Words on slide is from meeting in 1968 #Gotocph pic.twitter.com/XV1AxclpmQ

— Kristjan Wager (@kriswager) October 1, 2017

The above tweet only shows one of Martin Thompson's examples from the conference.

While it is easy to despair over how little progress that has been over the last 50 years, I think it is probably better to think about it this way: while our methodologies change, the problems we face are the same, and it makes sense to look at what people did in the past, to see if they have solved problems we face today.

A lot of people tend to think of pre-Agile days as a period of endless, mostly failing, waterfall projects, but the truth is, that this generally wasn't the case in the early days, and probably wasn't as common later, as legend makes it sound.

It is worth remembering that back in the early days of the field, people were not only building programs, they were also building the tools (e.g. compilers) they needed in order to build programs. These tools have evolved since then, but they are still based on the same solutions that we base our tools on today. Why should solutions to organizational problems be any different?

Disclosure: This blogpost mentions the GOTO Copenhagen 2017 conference. As a blogger who blogs about that conference, I get a free ticket from the organizers. The organizers don't dictate what I write about, and don't have any say about the content of the posts.