Monday, October 2, 2017

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.  


Sunday, October 1, 2017

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:
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.
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. 


Monday, September 25, 2017

My schedule at GOTO Copenhagen

GOTO Copenhagen 2017 is just around the corner, and I have taken a look at the talks that I definitely want to go to this year.

Unlike earlier years, GOTO Copenhagen starts on a Sunday this year, which makes some demands to the quality of the speakers, trying to lure people in early Sunday morning.

Luckily, the conference delivers - there are two keynotes on at 9:00, and while both looks interesting, I am going for Martin Thompson's talk. I have heard him speak a number of times, and every time the talk have been engaging and informative.

After the keynote, there are some interesting talks, but the next talk I really look forward to, is Dan North's Beyond Developer talk. Not only does the talk sound interesting and relevant, I also know that anything Dan North presents is going to be fun.

Skipping to the talks on Monday, I have spotted the following talks I'd be interested in:
The many security breaches in recent months, shows that security is still a hugely important topic, which is all too often ignored or neglected. These two talks addresses different, but equally important, aspects of security.

Tuesday, there is a track called Herding Cats: The Human Factor, where I plan to spend most of my time, for reasons I explained in my last blog post

Other than that track, I am looking forward to the end keynote by Linda Rising. Linda Rising is one of the most engaging and brilliant speakers I have ever heard, and it is a pleasure to go to one of her talks.

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.

Thursday, September 14, 2017

The importance of peoples tracks at IT conferences

Let's talk about the importance of peoples tracks at IT conferences.

Some IT conferences only focuses on technical issues, but some conferences, such as the QCon conferences and the GOTO conferences always include a peoples track.

I generally go to these tracks if I have the chance, since I think they are important.

Last month, James Damore published his now infamous open letter, where he wrote a screed against diversity in Google and the tech sector as a whole. The screed was not only incredibly scientific illiterate, but also clearly demonstrated the need for people tracks at conferences.


In the upcoming GOTO Copenhagen 2017 conference, there is a people track that illustrates why I think they are important.

The track contains five talks:
  • The Engineering-Manager Transition: How to take great engineers and make them great technical leaders
  • Stress and depression – a taboo in our time
  • Scaling Engineering Teams
  • The 2D Kitten Problem
  • Build the right thing: how to survive the accelerating rate of business change through experimentation
While these talks are all about people, they are quite diverse, allowing the listeners to learn from the experiences of others, and to see new perspectives.

In the above list of talks, it is especially the second and the fourth talk that I think makes the track worth my time.

The second talk,  Stress and depression – a taboo in our time by Gitte Klitgaard, raises a subject which is all too rarely discussed, and which most of us are affected by - either directly or indirectly.

The fourth talk, The 2D Kitten Problem by Laura Laugwitz, is described thus:
"Diversity" is one of those buzzwords that alternates between being supercharged and sadly hollow. While many tech companies like to boast about their diversity programs, the numbers regarding their employees don't change much. But that's no reason to give up on the concept of diversity just yet! However, we need to re-examine what actually constitutes this term in order to make it sustainable: Diversity is more than hiring a few "different" people, it's about empowering oneself and others to create positive change.

This talk will give back some meaning to the term diversity while illustrating why it's still important. There will be some interaction, some tangible examples and more than a few cats to help you through the more challenging parts of theories and self-reflection.
While it is highly unlike that James Damore would ever go to such a talk, it is talks like this that would have allowed Damore to understand the importance of diversity.

It is not possible to reach Damore and his irk, but there are other people out there who are not aware of the importance of diversity, who can be reached through such talks. This is why I think people talks are important, and why I hope conferences keep having them.

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.

Tearing down the walls



It is pretty widely accepted that one of the major challenges for IT projects is communications between the different parties involved.


The above figure demonstrates how a traditional IT project works, and why communication is such a big issue.

The business have some wishes, which they give to the requirement people, who turns them into requirements, which are handed over to the development team. The development team then develops the system, and hands it over to testing. When the system is tested, it is handed over to operations, which puts it into production.

Such a process is characterized by each group being walled off from each other, often in a real physical sense. It is also characterized by a lack of communications between the groups.
This means that it can take a long time to find misunderstandings, and that the requirements tend to become outdated before they reach production.

SCRUM and other Agile methods have tried to address this in different ways, but even so, communications problems still exists.

The above figure illustrates an IT project using SCRUM. Here the developers and testers form one team, and the requirements specification is handled by a PO who represents the business.

Due to the processes in SCRUM, the communication barrier between the PO and the SCRUM team is reduced, but there is still a barrier. Also, in most organizations, the barrier between the business and the PO is unfortunately as great as the barrier between business and requirements people in traditional projects.

There is also a communication barrier between the SCRUM team and operations.

The fairly recent concept of DevOps have tried to address the communication barrier between the SCRUM team and the operations people.










As the above figure illustrates, this is handled by embedding the operations people in the SCRUM team (this is obviously a simplified description).

Last November I was at a conference in Orlando, where one of the speakers were the PO for the SCRUM process, and he told us that there is a focus on adding DevOps to the SCRUM methodology.

Unfortunately, he also said that they are not going to do anything about adding requirements specification to the methodology.

This is, in my opinion, unfortunately, as it would help reduce the barrier between the business and the rest of the project, and between the PO and the SCRUM team.

So, what can be done instead, in order to remove the barrier between the business and the rest of the project?

Well, I think it will be hard to completely remove the barrier, but I think there are different ways of reducing the communication barrier.

These are, in random order:
  • Embedding a business person in the SCRUM team
  • Regular meetings
  • Techniques such as story mapping
These can obviously be combined.

Embedding a business person in the SCRUM team

This is an idea that was introduced with eXtreme Programming, though it probably existed before that as well.

It is simply getting someone from the business sitting together with the SCRUM team.

This is often hard to do, as it can be hard to get people released from their normal position in order to place them in an IT project, even if they continue to work on what they usually work with. This is partly due to the, probably reasonable, concern that the person will have much less time to do their job. But it is also often partly due to the fact that many bosses don't like not having people sitting apart from their usual team. On top of that, it might be hard for the business to see the value of embedding the business person in the SCRUM team.

If you manage to get a business person embedded with the SCRUM team, it is worth regularly evaluating whether the business person is the right person for the role, or whether there should be a rotation of the business people, in order to keep the focus fresh.

Regular meetings

A simple, but effective way of enabling communication between the business and the rest of the project, is to plan frequent meetings.

The sprint reviews in the SCRUM methodology is one type of frequent meetings, but there should be other meetings, such as requirements meetings between the PO and the business.

These meetings can be used for presenting user stories before they are taking into a sprint, in order to get the input from the business, and clarify any unclear requirements. It can also be used to prioritize the requirements, based on the current situation, and to adjust the scope of the project, based on any developments.

Techniques such as story mapping

Requirements in SCRUM projects are often written as user stories, and there are some techniques that can be used while writing these, allowing the business to get involved.

One of these methods is user story mapping.

No matter what technique is used, it is important that to ensure that the business are willing to get fully involved. If they are not committed, no technique will help reduce the communication barrier.








In conclusion, it is unlikely that it is completely possible to reduce the communication barriers completely in an IT project, but there are methodologies, concepts, and techniques that can greatly reduce them, allowing for a greater likelihood of the successful development of a system which fulfills the needs of the business.

One aspect I haven't touched on in this post, is the extra complications if the project isn't aimed at the internal business, but rather at customers outside the organization. External customers obviously adds an entirely extra complexity to communications, and is a subject for an entirely different blogpost.