How smart developers generate lousy code
Most experienced developers can think of a time when they worked on a team with other accomplished programmers. Yet the code quality was anywhere from “eh” to “oh god you didn’t actually ship that did you?!” Here’s how this can happen, and what to do to minimize the chances it’ll happen to you.
Depending on gravity (as with old Roman bridges built without mortar) is safer than depending on other things that are more likely to change, such as your users' whims.
Image credit: Flickr/Charly Morlock
Sarah Mei spoke about a time she worked on a team with really expert developers. Every one of them was someone whom you'd admire, who had previous written code that you and I would boast to have created. Yet, these smart people created modules that didn't talk to each other. And its quality was, to be kind, on the rotten side.
You've probably encountered something like this at some point in your own programming career. Instead of the team creating more than the sum of its parts, the end result looked like something created by a novice developer. If not like crayon sketches from an untalented 6-year-old.
Sarah Mei during her "More Than Good Design" session at O'Reilly Fluent Conference for Web developers, 2013
Which is what inspired Pivotal Labs' Sarah Mei's session, "More Than Good Design," at this week's O'Reilly Fluent Conference for Web developers. In her session description, she explained, "The people you're working with affect the code more than you do, in aggregate. In fact, codebases grow to resemble their creators' relationships over time. As a result, many of the forces guiding our day-to-day software design decisions are social – and invisible. The good news is that social interactions can be mapped out and made visible. We can improve what we can see."
In her session, Mei looked at the intersection between design and team organization in order to identify the factors that affect the process of writing good code. Nobody writes good code all the time, of course, but certainly there are things that can inspire your average quality to be better or worse.
Of course, that starts with identifying what good code is, which is a topic that has kept academics busy for 40 years. Mei's own conclusion is that code quality "is defined by its patterns of dependencies." Those dependencies identify whether a code base is easy to change.
And, naturally, not all dependencies have equal weight. Mei offered the example of a Roman bridge, built without mortar, that's lasted for 2,000 years. The dependency for that building project relied on gravity. But depending on gravity is safer than on other things that are more likely to change, such as your users' whims.
Good code, Mei asserted, relies on three things: object oriented design principles, development practices, and – eek! – other people. It's that last bit where things get wonky. But it's also something that nearly every developer needs to deal with, since building anything interesting usually involves a development team. That means that most of the code a developer works with has been written by someone else. As a result, she reminded everyone, "You sink or swim as a team."
Lots of work has been done to improve team structure and good working conditions for developers. Sometime it works, other times it fails. Mei cited one company she worked for – the anecdote with which I started this story – in which she loved having her own office, because it meant she could get into the flow writing code. She could focus! Except, as it turned out, she didn't focus on the right things. In another team of seven or eight people, developers were encouraged to do whatever they felt like ... which turned out to include, "Have every developer write code in a different language."
Mei has found – in her experience and research reading – that good predictors of good code include:
The technical qualifications of the humans involved
Previous experience with the code base
Good communication among team members
The best of those indicators? The one that most commonly predicts quality results? Good team communication.
That doesn't mean that a development team with iffy code quality needs a new manager. It's not the company reporting structure that fails (necessarily) but the communication between the people who work on the code. For example, in one project there was one software architect who was a go-between for two teams of two developers. He didn't know what either team needed, said Mei, and the two teams weren't directly speaking to one another. After all, the architect was supposed to be the go-between. Just imagine what that code looked like. (You may wince.)
If you want to identify the problems with your own code quality, "Look at the code and see what it tells you about the team structure," Mei suggested. If you're a senior developer, resist the urge to (immediately) refactor the code that makes you say, "Huh?!" – and ask, "How did it get this way?"
Among her fixes:
Pair programming. This can be informal and ad hoc, Mei said, but it obviously improves communication. (Lots of developers resist this because constitutionally they don't like to talk to people, but really, she insisted, communication is a skill you can improve, and you need to.)
Create opportunities for informal communication. There's lots of ways to do this: sit next to one another in the same place so you overhear what another developer is working on; use IRC or instant messaging; bring into the office a super-fancy coffee machine that you have to show people how to use.
Focus on teach/learn/practice, she said, and encourage high-bandwidth communication. Think of it as optimizing interfaces: You're improving the edges between the people on your team.
Hack your team, Mei urged. You'll all be happier with the software you write as a result.
