Software Engineering Best Practices

A Dice Talent Community

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.

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!

IT Management Community | Fundamentals and Job Hunting