Why Good Developers Write Bad Code – Mathieu Lavallee

Why good developers write bad code?

A joke:

2015-05-22 09.03.02One person raises his hand, so the people in the room say: is your team that good? No, says the person, my team is so bad, the plane would not take off 🙂 Fun! But, are our teams so bad, or are they working in a problematic environment? Matthieu wants to find out.

In previous work Matthieu has observed individual programmer activities, programmer practices and team dynamics, but it was hard to find exactly where the problems started.

The new approach is observe project dynamics within an organization. The context was a 5000+ person company, and the project was a second attempt to build a complex computer system(thousands of pages of specs). The first attempt failed so there was a lot of pressure on this project, with a fixed time frame and budget.

The methodology used was non-participant shadowing of team meetings for 10 months, and minimal interference with developers (because the company did not trust the researchers too much yet) .

The core team consisted of 4 senior developers, 2 junior, 2 contractors and 1 manager, all of which were hired for this project, so they had <1 year of experience. For many meetings other people joined in as well:

2015-05-22 09.10.37

In total 54 people from 15+ teams attended the meetings! So, we can safely conclude that to understand software we need to understand human.

Results

Matthieu found 10 issues, which he divided into three levels: organizational, intra-team and inter-team. Unfortunately he only has time to talk about 3.

Organizational: Even though there were processes in place, people use informal channels, not using a form but calling their friend Bob in the database department. But, this team was pretty new within the organization, which slowed the project down. For example, for one library, customer support said a certain feature could not be done, but when they found a developers via an informal network, it was added in 1 week.

Inter-team: Many modules were developed in parallel, but they depend on each other, when the one changes other have too. Because of this, the manager stressed that their scope needed to be protected. This caused a lot of inter-team conflicts. For example there was a certain refactoring which they estimated at 400 hours of workload to fix it once and for all. But, with 100 years and a few wrappers it also worked. Result: 12 wrappers and ugly code. The decision was then made to do it the cheap way, because they thought of the priorities of their team above the priorities of the company. The team fought for a refactoring project after deploy, but it was never approved.

Organizational: Because there had been a big bug in the software a while back, they introduced very heavy processes for adding new code, and they were afraid about bugs. For example, one development team maintained a list of bugs, but did not report them. There was no information flow between the teams about this, because bugs were bad, so not reporting seemed safer.

To validate the study, Matthieu presented his results both within and outside of the company, and they were confirmed in both.