Stop making developers think so much

Jacob Orshalick

Want to see your developer efficiency sky rocket? Eliminate as many decision points as possible.

Developers want to code. Naming, code structure, design… we enjoy making these decisions. These are the decisions where our expertise can shine. It’s what we love to do. It’s what makes us enjoy our job.

We hate getting delayed at decision points. Decision points that could have been avoided or at the very least minimized.

Fewer decision points means: more efficient delivery, fewer mistakes, and happier developers

Want an immediate boost to your development team? Keep reading.

Well-defined requirements

Requirements can be written in many ways:

The way they’re written is less important than the content and how it’s understood.

A requirement is unclear if I have to decide whether it’s worth asking a question or if I should make an assumption.  We all know where assumptions get us…

Before scheduling requirements for an iteration or sprint, make sure:

  • Each requirement is well defined and documented just enough
  • Developers have been involved in planning conversations about the requirements
  • Any initial questions from the dev team have already been answered
  • The development team feels confident in their understanding

Well-defined requirements eliminate 90% of the questions developers would have to ask during a Sprint. So what about the remaining 10%?

Direct line to decision makers

When I have a question about a feature, I want someone who understands the problem and can provide an immediate answer.

Without this, you’re faced with:

  • Crafting communication necessary to describe the problem
  • Excessive meetings about the problem
  • Reading communication threads when other parties get involved
  • Making temporary assumptions that turn out to be wrong
  • Context switching to another problem so development can continue
  • Context switching to the original problem once a decision is made

A development team needs someone available with the authority to make decisions. A Product Owner, Product Manager, Business Analyst, whatever title they hold.

Have the decision makers:

  • Understand what’s been scheduled for the current Sprint
  • Join the daily standup to answer any questions that come up immediately
  • Provide “office hours” where they are available to jump on a quick call or join a discussion
  • Meet with developers prior to sprints to discuss upcoming features

Write opinionated software

A team should:

  • Believe there is a preferred way to build their software
  • Put boundaries around how their software is developed
  • Eliminate mistakes by enforcing agreed upon good practices
  • Automate the parts of a business process that are always applicable

Opinionated software eliminates unnecessary decisions for the development team. Some of the basics of writing opinionated software:

  • Have a well-defined technology stack: the technologies your team uses to build software should be well understood and easy to use. The base technologies should be easy to extend when necessary.
  • Follow well-known patterns: published patterns are well understood making it quick and easy for developers to grasp the idea and use them. Don’t make it a contest for how many patterns you can use, but certainly use them when it makes sense.
  • Eliminate boiler-plate code whenever possible: boiler-plate is repetitive code that gets copied throughout the codebase increasing complexity. Create utilities or a framework that handles the common behavior.
  • Automate cross-cutting behaviors: these are the repetitive behaviors like performance timing, auditing, trace logging, etc, that always apply. These should be handled automatically without the need for a developer to explicitly code anything.
  • Clearly define responsibilities: have a clearly defined architecture and project structure. Developers should understand where things like models, repositories, controllers, configuration files, etc belong. Leaving this up to each individual guarantees a mess.
  • Make it easy to write tests and enforce test coverage: if you want tests written, it better be easy to write them. Most developers don’t enjoy writing tests and will come up with any excuse not to. Enforce test coverage with tools to make sure developers don’t slip up.
  • Analyze the code for best practices: this is done through static analysis tools that check things like code structure and conventions. This should be automatically performed during a build to ensure it happens.

So remember…

Developers have enough decisions to make already. Eliminate the unnecessary ones. Not only will your developers be more efficient, they’ll love what they’re doing.

Related articles:

Like what you read? Subscribe to get articles delivered to your inbox.