Original Image by Nicolas Raymond

Good practice in software development has always preached loose coupling and high cohesion.

While most developers understand this and try to keep to it, sometimes even seasoned professionals get carried away with an idea, quite often ending up in the creation of a big ball of mud. This will not only take the buggy part of the application down, but can make the entire stack unavailable.

It's important to understand how these situations start in order to identify them early and bring development back on track.

Don't try and be clever

Trying to create something that's really clever is quite often the beginning of a stupid situation. Yes, creating dynamic navigation menus that are generated directly from the CMS may sound like a marvelous idea, after all, the client wants to be able to create new pages and control their content. However, it's far too easy to create a bad implementation that ends in pain and misery for the development team if steps are not taken to make sure that the way the solution is being developed is also appropriate.

A ticking bomb

Several years ago, just this type of implementation was created. We cautioned the team doing the development that tying the site navigation into to the CMS too heavily would make it much harder to change, maintain or fix if something were to go wrong in the CMS. Fast forward to the present and a situation came up that caused the worst to happen. The entire site went down after months of uptime, and the team got called in to help the client to fight the fire. All parts of the customer facing site were inaccessible because the CMS had saved some of the pages in the wrong order. This caused an error in the site navigation, stopping all functionality on quite a busy e-commerce site.

Rather than create a system that had a separate navigation module that could ask the CMS for top level navigation pages, and fail gracefully if none were present or an error occurred, the navigation was tied directly into the third party CMS. The CMS had a custom extension written for it that would assume certain pages had to exist, with no way of falling back should something be awry.

The architects of that solution had not heeded the advice given to them and had created a time bomb in the site. Worse, all of the original developers that had created the solution had left the company by the time it exploded and it was rather over-engineered and scattered around the extensive codebase. This made it even more difficult for the team who were brought in to do emergency work on the site and get it back up and running.

Now, the original developers were by no means incompetent. Many of them had years of experience and had a good track record for making successful projects work. In this case, they just got carried away with an idea that they could solve multiple requirements with a single, integrated solution. They made the mistake of not stopping and asking where the boundaries should be and what should happen when it didn't work.

Bad implementation vs bad idea

The difference between a bad idea and a bad implementation of a good idea can be very hard to identify. This is where going back to basic principles is a must-do. If the development team had strictly adhered to the idea of loose coupling, they would have been able to see that how they were proposing to solve the navigation issue was going to couple separate modules together in a way that was going to cause nasty problems down the road.

Allowing the client to control the navigation was a good idea. It did indeed solve a real business requirement and was the correct thing to do. Tying CMS pages directly to the navigation was just a bad implementation of a good idea. The culprit was not having a clear separation of concerns and was the time bomb that created the outage.

This is a problem that is probably much more common than it would first appear. Most teams will not stop and take a critical look at what they are doing, after all building software is fun and nobody wants to be the one to throw water on the party. Changing the team culture to encourage critical thinking, not just smart ideas can be a good start to solving the issue, allowing team members to ground each other in a friendly and productive way.

As software professionals it's a good thing to get enthusiastic about an idea and to run with things. However, we must always step back and take a critical look at solutions to help ensure that we're not violating best practice in the name of progress.

Search

Bad implementation always trumps good ideas

19 September 2015 11:34 a.m.

Good practice in software development has always preached loose coupling and high cohesion.

While most developers understand this and try ...

Read More

New platform, new challenges

13 September 2015 19:13 p.m.

There was a question raised by a collegue of mine recently, that asked "How long should it take to get ...

Read More

SaltStack and Vagrant

14 February 2013 15:14 p.m.

Salt is an open source infrastructure management tool. While one use is to manage thousands of servers, it’s also very ...

Read More