When I work on my own personal software projects, I enjoy total freedom: on the technologies I use, on how I document design – typically on a piece of paper I lost – on my coding style, on the kind of testing I do. I also don’t have any deadlines or customers waiting for my code. I practice my craftsmanship for my own enjoyment. Mind you, the team is made up of me, myself and I focused on building a database of game theory optimal strategies for poker. And every once in a while, I still look at old code I wrote and wonder what the hell I meant to do!
On the other hand, when I work as part of a team, or more often as part of a team of teams… Well, we accomplish a lot more, in our case open source and mission-critical software for 250 of the largest companies in the world. It’s great to have this feeling that I contribute to solving big problems. But that also means I’ve had to maintain code written a few years ago by colleagues, often wasting hours trying to understand how it should work, what it does, what doesn’t work and guessing at the intent. I’ve picked up old trouble tickets with no understanding of what the customer impact was or what had been tried so far to resolve the issue. It can feel like the Tower of Babel, ready to topple at any moment.
On the right track
This isn’t exactly a new idea. A famous example is the gauge of train tracks in the United States. We all know the country was built with railways. Initially some Northern states just adopted the English gauge standards — which were already a quirky 4 feet by 8-½ — but many other states, more rebellious and individualistic, came up with their own gauges, perhaps more efficient for their geography, perhaps for no particular reason, who knows? What happened is obvious. When a train had a load to carry from North to South, it had to stop at the state border, unload one train and put everything back on the next one. What a waste of time and energy! This is the reality for so many software engineers today: they are trained and motivated to create elegant software that makes trains go super fast, but spend more than half their days offloading parcels from stopped trains; these fantastic problem solvers spend most of their time on menial, stupid tasks…Poor return on investment for the employer, totally demotivating for engineers.
Standards allow engineers to do great work and stop wasting time on frustrating, mindless tasks.
That doesn’t mean standards are easy to implement. Software engineers are certainly problem solvers, great with numbers, but they are also very creative and artists at heart. I guarantee that someday soon we’ll see a piece of code hung on a wall at Le Louvre museum. (It’s already getting closer.) As creative artists, we’re opinionated. Sometimes standards are just a best practice and it’s reasonably easy to agree on them. Sometimes they’re just a convention, not particularly better than another, but we need everybody to respect them. It’s much harder to get developers to agree to stick to them consistently but worth the effort.
Set it, then forget it
The process we use at Scality for Zenko and RING is humble and semi-democratic. We shared a Google doc where engineers provided their input. As VP of engineering, I asked my team to think of cases where they wasted time and where standards would have avoided this. Well, I got loads of opinions. We had three categories: coding standards, design standards and ticket standards. My task now is to turn this input into a small initial set of actionable standards. By starting on small set, easy for all to agree on and act on, I feel we can start building a strong habit of enjoying standards and sticking to them. Then over time we can gradually improve and add to The Standard. That way all of our work — from tickets to pull requests — will be consistent. We’ll make these available online on Zenko forums so the larger community can participate in the discussion and use/modify them, too.
I’m confident this approach will help engineers spend less time on meaningless work and more on what they really want to do. At the end of the day, this is the most important task for an engineering manager: not telling engineers what to do, but removing all the idiot work so they can focus on creativity. Stay tuned for the next update to see how we’re doing!