Title: Playing By The Rules

Author: Martin Moene

Date: 09 November 2014 15:27:08 +00:00 or Sun, 09 November 2014 15:27:08 +00:00

Summary: Pete Goodliffe makes up his own rules.

Body: 

If I'd observed all the rules, I'd never have got anywhere.
~ Marilyn Monroe

We live our lives by many rules. This could be a dystopian Orwellian nightmare, but it’s not. Some rules are imposed on us. But some we set ourselves. These rules oil the cogs of our lives.

Rules facilitate our play, describing how a game works: saying who has won and how. They make our sports fair and enjoyable, and provide plenty of opportunity for (mis)interpretation (see soccer’s off-side rule).

They impinge on our travel, where security rules dictate you can only carry so much liquid, and no sharp objects, on airplanes. They describe traffic speed limits, and how to safely navigate a path on the road. Such rules ensure the safety of all.

Rules bound our social norms, stating that it’s not appropriate to lick a stranger’s ear when you first meet them, no matter how tasty it looks.

Yes, we live our lives continually observing a set of rules. We’re so used to this that we often don’t think about them.

Unsurprisingly, the same holds in our development work. There are a wide range of rules we follow at the codeface. Development process norms. Mandated toolchains and workflows. Office etiquette. Language syntax. Design patterns. These are the things that define what it is to be a professional programmer, and the way we play the development game with other people.

If you join a new project, there are various rules that you’d expect to be in place. Rules governing the responsible creation of high-quality code. Rules governing working processes and practices. And specific rules about the project and problem domain: perhaps legal regulations in force for financial trading, or safety guidelines for health markets.

These rules they help us work well together. They help orchestrate and harmonise our efforts.

We need more rules!

But sometimes all of these rules, good as they are, aren’t enough. Sometimes the poor programmers need more rules. Really, we do.

We need rules that we’ve made ourselves. Rules that we can take ownership of. Rules that define the culture and working methods of development in our particular team. These needn’t be large unwieldy draconian edicts. Just something simple you can give new team members so that they can immediately play the game with you. These are rules that describe something more than mere methods and processes; they are rules that describe a coding culture – how to be a good player in the team.

Programming teams have a set of rules. These rules define what we do and how we do it. But they also describe a coding culture.

Sound sane? Well, we think so. Our team’s Tao of development is summed up in three short complementary statements. From these all other practices follow. These statements are now enshrined in our team folklore, have been printed out in large, friendly letters, and emblazon our communal work area. They reign over all we do; whenever we face a choice, a tricky decision, or a heated discussion, they help to guide us to the right answer.

Are you ready to receive our wisdom? Brace yourself. Our three earth-shattering rules for writing good code are:

• Keep it simple
• Use your brain
• Nothing is set in stone

That’s it. Aren’t they great?

We set these rules because we think they lead to better software, and have helped us become better programmers.

They perfectly describe the attitude, the sense of community, and the culture of our team. Our rules are purposefully short and pithy; we don’t like lengthy bureaucratic dictats or unnecessary complication. They require developer responsibility to interpret and follow; we trust our team, and these rules empower the team. They are always new ways to apply them in our codebase; we are always learning and seeking to improve.

Set the rules

These rules make sense to us, in our project, in our company, and in our industry. They may not have the same import for you.

What rules are you currently working to? That is, apart from the ban on licking your colleagues’ ears. Do you have a coding standard (either formal, or informal) in place? Do you have development process rules (perhaps the likes of: Be in for 10 a.m. because we have a stand-up meeting. All code must be reviewed before check-in. All bug reports must have clear repro steps before being handed to a developer)?

What rules govern your team culture? What informal, unwritten ways of collaborating, or approaches to the code, are particular to your team?

Consider formulating a small, simple set of rules that you can define your coding culture with. Can you distill it to something pithy like our three rules?

Don’t rely on vague unwritten team ‘rules’. Make the implicit rules explicit, and take control of your coding culture.

In the spirit of our third rule, don’t forget that nothing is set in stone –including your rules. Rules are there to be broken, after all. Or rather, rules are there to be remade. Your rules may justifiably change over time as your team learns and grows. What is pertinent now may not be in the future.

Questions

1. List the software development process rules currently in place in your project. How well are these enforced and followed?
2. How does this project’s culture differ from your previous projects? Is it a better or worse project to work in? Can the difference be captured or improved in a rule?
3. Do you think your team would rally around an agreed set of rules?
4. Does the shape, style, and quality of your code have any effect on a projects’ coding culture? Does the team shape the code, or does the code shape the team?

Notes: 

More fields may be available via dynamicdata ..