Sunday, December 8, 2013

My Take on Development Best Practices

I was recently asked to contribute to a VentureBeat feature on best practices for software engineering. I'll withhold my opinion on the piece; for the record, here's the full text I provided:

A true master developer knows how to maximize velocity while maintaining quality.

Here's my top ten:
  1. KISS - complexity is your #1 enemy. Everything should be as simple as possible. Invest in simplifying your architecture and codebase and it will pay off in velocity. When there's more than one way to go, choose the simpler way. Don't over-engineer things. Anything that's "unavoidably complex" is best avoided entirely.
  2. TDD is how you build defect-free code as quickly as humanly possible. Never, ever, say you'll write the tests later, or "it's done except for writing tests" - that's how they did it in the '90s. We know better than that now. Measure test coverage and keep it at 100%.
  3. Build your prototypes under the assumption that they'll evolve into your product whether you like it or not; you may intend to throw it away and start from scratch later but it usually doesn't work out that way. This means start writing tests when you start writing code.
  4. Develop your software securely from inception since it's extremely painful to "add security" later. If you don't know how to do this, get someone on your team who does.
  5. Keep your workspace clean - purge all unnecessary code, remove unnecessary dependencies, drop DB tables you no longer need (though you might need to retain backups), keep your team wiki up-to-date.
  6. Automate QA and ops as much as possible - development is inherently iterative so maximizing velocity means driving your iteration time down. Aim for at least push-button if not fully automatic deploys. Build on every commit to master.
  7. Make your tests as high-veracity as possible. It might seem like a lot of work, but it's an investment you'll be thankful for when you narrowly avoid shipping a subtle, nasty bug.
  8. Software engineering is a team sport; peer review all commits. A critique-seeking, low-ego culture fosters team-wide excellence.
  9. Deploy whenever you have something ready to release; otherwise you've paid for the work but you're not realizing the value of it.
  10. Only refactor when the problem and the solution are both staring you in the face - premature refactoring is a huge waste of time. Don't invest in perfecting anything that might conceivably be dropped in the next 6 months. And premature optimization is the root of all evil.
Success is when a single developer can fearlessly rewrite core modules in the morning and deploy to production in the afternoon with zero disruption for your customers.

1 comment:

  1. agreed except for 2. tests have cost. sometimes cost outweigh the benefit. ways to get the benefit without that cost. context is key. still, overall lots of wisdom here.