In Software Development, Best Practices Can Be Dangerous

Many years ago, I worked for a consulting company that was asked to provide “best practices” for their software development teams. Dutifully, I helped put together what I thought were some best practices that they should follow.

Today, I don’t remember what best practices I captured for that client, but I’m guessing that I’d probably cringe if I were to see them, now. Were they that bad? At the time, they were probably reasonable, but they certainly won’t be useful anymore. Today, you can find all sorts of best practices. A quick search on Google will find you 680 million results. I can’t imagine trying to read through all of those, and I imagine that though there must be some good advice in there, I question how anyone would be able to differentiate the good from the not-as-good.

It reminds me of the scene in the movie Megamind in which Will Ferrell’s character, Megamind, speaking to his minion (David Cross), says: “Okay, Minion, you were right, and I was…less right!”

It’s common to see companies use best practices because they can use them to justify how they want to do things. They believe that these practices will help them be successful. Sometimes, they’re even right.

Where do Best Practices Come From?

Spend any amount of time reading about software development tools, practices, languages, architectures, etc. and you’ll find lots of opinions (you’re reading one right now!). Many of them come from someone’s experience, though many are based upon studies (in some cases, over many years and across many different environments). Typically, though, they are not based upon “first principles” or the fundamentals. These “best practices” come about in order to solve some problem. If you have that problem, and you find the solution, you’re in luck.

In fact, it’s not too difficult to find articles espousing a particular process or technology and another that states the exact opposite. If you want to justify to your manager that your team should do X or use Y tool/language/whatever, there’s a good chance you’ll find an article that agrees with you.

This isn’t to say that for many of those espousing a particular practice are trying to pull the wool over your eyes, and this isn’t to say that there aren’t good practices out there. For example, there are many successful Scrum teams, as well as Kanban teams, and a lot of important, useful software has been written in COBOL, C, C++, Java, Python, etc.

Danger, Will Robinson!

Danger occurs when best practices are selected and followed with little questioning and little thought, justifying the decision because it’s a “best practice.” They are selected without clear purpose.

Whether it’s Scrum, Kanban, Pair Programming, the new cool language on the block, a new architectural pattern that looks great, companies commonly don’t do sufficient due diligence when selecting and implementing new changes. Does it fit with their culture? What principles and values are driving the selection? How will success be measured by the change? What’s the opportunity cost? What if it fails? What’s the backup plan?

These kinds of questions can be boiled down to needing a well-defined purpose and the principles that should drive the decisions, implementations, and success criteria.

Purpose-Driven

Have you ever met a developer who was trying to figure out a problem, found the solution on Stack Overflow, copied the code and ran with it, not understanding what they just did? What about a company which was convinced to follow Scrum, but couldn’t afford (or didn’t want to afford) Scrum Masters, so had the Product Owner handle the responsibilities? There are plenty of companies who claim to do Agile so that they can recruit talent that is not interested in following a waterfall-based process.

Companies that don’t focus on best practices, that don’t “pull the best practice off the shelf and run with it,” that make purposeful decisions about what works best for them based, tend to get better by-in by their employees. They are flexible enough to stop doing what’s not working and make adjustments to be successful.

Which is worse, failing or succeeding by accident?

When I work with engineers, I teach them to do things on purpose. I believe that this is a fundamental principle of developing software. For example, if they are working on a defect and figure out the solution but don’t understand why, I tell them to go back and figure out the why. If they are following a particular approach in designing a system, I want them to understand why that approach works in the given situation.

Succeeding by accident means you didn’t learn anything. Failing is an opportunity to learn. You know the most about a product what it’s done, so building software is ultimately a learning process.

Principle-Supported

Years ago, I was working at a consulting company who was working with a client to improve a particular project that was failing. I was acting as an architect and was reviewing the basic architecture, design, and even the code. I was able to identify a number of issues and made what I considered to be good recommendations in order to turn around the project.

One of my recommendations had to do with using a particular application server. The consulting company that I worked for was small, so it wasn’t uncommon for one of the partners to get involved in a particular project. In this case, not only did he step in, but stepped in far enough to talk to me about changing my recommendation about which application server to use. He wanted me to use one from a well known vendor (it was also well known for being slow and hard to work with).

We disagreed, but what was disappointing about the exchange was his question to me: “will this application server work?” In other words, he wanted me to admit that the application server he wanted to recommend would serve the purpose. Begrudgingly, I agreed. We went with it. It wasn’t until much later that I found out that the small consulting company that I worked for received marketing money from the vendor in question and that recommending them put additional money in our pockets.

And, by the way, it could be easily said that the recommendation we provided for the application server was a “best practice.” In this case, the decision was certainly purpose-driven, but that’s not enough.

Best practices can be considered “best” when they are applied to a particular scenario and context. However, they rarely come with a nice long specification of what scenarios and contexts they work best within. This is why it’s critical to identify not only the purpose but the principles and context the practices will be applied.

Some organizations need to focus on customer safety and privacy. Some must focus on specific regulations. Others must figure out how to deliver quickly or provide sufficient scale, etc. For some companies, the principles and context change over time due to a changing business environment. Has your company, organization or team ever sat down and discussed what was really important, what principles you wanted everyone to abide by? These can be powerful in terms of guiding decisions, implementing practices, and understanding success criteria when you review the results of those decisions.

For example, let’s say your organization has a principle about transparency, both within and without the organization. You’re picking a tool to track defects. Some questions you might ask during that selection process:

• How will this provide transparency to our internal stakeholders (such as reports, drill-downs, metrics, etc.)?
• How will our customers interact with this tool?
• Is there data that shouldn’t be exposed because it won’t be interpreted properly or be understood? How can the tool handle this type of data?

I’ve seen organizations make choices around tools based upon what upper-management wanted but which ignored the needs of those who would use it on a daily basis.

As another example, what if you’re developing a design system for how your customers will interact with your software and you have a principle that specifies that you want to make using your software as simple as possible? You might ask yourself these kinds of questions:

• How many new terms are being introduced that the customer might not know or understand? How do we convey the meaning quickly and easily?
• For each component type, how will customers know what they mean and how to interact with them?
• How do colors impact how different segments of the customer might be able to read content, and how will it guide their eyes across the screen?

I’ve seen organizations choose design approaches that focused on what the designer thought “looked good” rather than the impact to the customer.

Companies, organizations and teams make better decisions and provide better ownership to their employees when they do things on purpose and with well defined and understood principles.

Conclusion

Best practices are defined as such for a good reason. That means that they shouldn’t necessarily be ignored or dismissed. However, blind acceptance of them because they are “best practices” is just as dangerous.

If you, as did Alice in Wonderland, come to a fork in the road and don’t know where you’re going, does it matter which path you take?