Software Engineering: Change is the Only Best Practice

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.

Best practices simply don’t exist for all of software engineering. One group will tell you to engage in emergent design. Another guru will have seven counterexamples of why that doesn’t work, and that the system as a whole really needs to be designed up front. One guru will tell you that you need to get specialists on the team, that you need a database administrator to create a good data model, and a tester to make sure this stuff really works, and a JavaScript engineer to make the front end sing, etc. Another will point to successful projects where every member of the team was a generalist, and they were successful. Frequently, both sides will be right — it’s just different situations and different needs.

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!

No Responses to “Software Engineering: Change is the Only Best Practice”

  1. Doesn’t the term “best practice”, by definition, limit itself to a specific time and offer no room for improvement? Nothing quite so depressing as realizing you are as good as you’ll ever be. Perhaps a better term is “TBPATM”; the best practice at this moment. Then again I find pithy phrases such as “best practice”,. “pro-active”, “raise the bar”, “bring your a-team”, etc. to be so cliche I want to … the speaker.

  2. Oh, I don’t think best practice has to be limited to time or to offer no room for improvement. In fact, I kind of think that was the whole point of the article: best practices change. The best ideas today are not the best ideas tomorrow; we’ll have even better ones to meet our changed needs.

    (Okay, confession – I know that was the point of the article. I wrote it!)

    • I understand that was the point, and that you wrote the article. My point is/was that using such definite statement as “best practices” also bothered me because it seems so final, and so MBA. What next, “best programming language”? Best OS?

      • Catherine Powell

        I’m pretty sure the best OS / best IDE / best language flamewars are already happening. Just check out pretty much any programming forum!

        That being said, I hear your point. I disagree, but it’s not actually relevant to the thrust of the post, so I’m not going to worry about it.