Software Engineering Best Practices
By Catherine Powell
In my day job, I’m a VP Engineering for several clients. Almost every client engagement starts with someone — usually the CEO, but sometimes another business type — saying, “We’d like you to help the team learn best practices.”
This is a really tough question. After all, if you put ten engineers in a room and ask them about best practices, you’re probably going to get at least 20 opinions! If you ask them again six months or a year later, you’ll get a new set of 20 opinions, and there won’t be a whole lot of overlap.
Herewith, for free, is the only best practice I’ve been able to stick with:
It’s all going to change. Be ready.
It gets worse when you get into specific technologies; there, you’re more vulnerable to time-based changes. “Use restful authentication for Rails authentication authentication” was the conventional wisdom three years ago. Now, many projects use devise instead. Same problem, different best practice. The only thing that changed was time, and the availability of various solutions.
Ultimately, best practices are blanket statements that do not take actual situations into account. Today’s problems are not the same as yesterday’s problems. Today’s solutions and teams are not yesterdays solutions or teams. There are things that are usually a good idea (hint: test driven development), but there are also cases where that is a bad idea and cases where that is a good idea that doesn’t go far enough. In software testing, this is called “context-awareness” or the “context-based” school of decision making. Be aware of your particular situation and how any advice applies to it, applies to part of your situation, or simply isn’t relevant. Take the “best practices” you hear, and make some informed, explicit decisions about whether you’ll use them and why. That is the most value you can gain from any advice.
The one thing you can count on is that the software you write today for today’s problem, that won’t be the right thing to do for a different problem a year or two later. Your toolbox will change. Your methods for developing software will change. Best practice: be ready for change.
What “best practices” have you heard? Where have you found that they do apply, or that they don’t apply? Let us know!