How is this relevant to anything in the world of software development?

1. System Design

When designing systems, separate components by logic functionality. Systems that are responsible for continuous database queries, should not be tied to a web site that serves content, such as in Simulate a Windows Service using ASP.NET. While this idea may be good in theory and for any shared hosting environment when you can’t install or run services on the server, the potential that a deadlock or frozen thread occurs will increase. If that occurs, you can kiss all of your active user sessions goodbye.

2. Application Design

Separate application logic out so that when one component gets changed, it doesn’t force a complete rewrite. Websites and web services should not tie directly to the data layer. Design N-layer systems (read the differences between N-Tier and N-Layer applications) so that there are no direct dependencies on lower-level technologies being used.

Maintainability in separate components increases as the number of layers does. Take this in moderation though, too much loose-coupling in your layers, leads to overkill and needless complexity.

3. Class Design

When designing classes, follow the Single Responsibility Principle (SRP) of the S.O.L.I.D Class Design Principles. If your class has more than one reason to change, then it may be “too big to fail”. The below example helps:

The above breaks the SRP because any minor change required to one of the three purposes of this class causes the whole class to change:

1. The process to calculate the tax rate of the employee
2. Database Schema that matches to the Worker
3. Employee Id that is used. SSN today, numeric number tomorrow

Any single change impacts the class which is responsible for three very different purposes. While this is not “too big to fail”, the class is “too big for its own good”.

I hope this never occurs to any of you, but it definitely puts the problem of inheriting a poorly written/design application into perspective. “If only things had been done right the first time, changing it would be so much easier”. How many times have you heard that mantra? Hindsight is 20/20. We should focus on how we deal with these messy situations instead of complaining about them. Here are a couple thoughts:

1. Relax, look around, and determine what is going on.
Before you go haywire on your project manager and threaten to quit the company, put a positive spin on it. Remember you were asked to be the expert and fix someone else’s mistake. Make sure you really determine what the problem is. Is the problem the fact that this was written poorly, or is the problem because you have to maintain it?

2. Recognize what you can change.
If the application that you were asked to fix is completely abysmal, make sure that you don’t dig yourself into a deeper hole. You obviously don’t want to work on this application longer than necessary (unless you are a glutton for punishment). At the same time, question why things were done the way they were. Reasons may have been entirely political and you may have absolutely no control over design. Don’t focus on those scenarios, focus on situations where you can help the next developer who needs to fix this.

3. Make sure you know what you are talking about.
Ensure that this is a poorly written application because it uses bad design methodologies, not because someone else wrote it. In explaining the problem to your peers and other developers, avoid a negative attitude. They are just going to see you as someone who complains, not someone who solves problems. When solving the problem, don’t create change for the sake of it or because you think you can do it better. The time for design has passed, this is development. Unless you were asked to do a rewrite, do a fix.

4. Lose your fear.
If you’ve got the last point down and you know what you are talking about, lose your fear. Dive right in. Express what is incorrect with the application to managers and see how they respond with it.

5. Get away from it.
I solve my most difficult problems away from the computer. Sometimes it happens at home, sometimes during dinner, and even in the shower. You know the deal. If it isn’t an urgent production issue, give yourself a 24 hour mental break. Think about something else. This answer will come to you tomorrow and you will laugh that the solution is not as complex as you expected. 

6. Attack it in units.
Don’t bulldoze the whole project. Take notice of the systems’ components and break the problems down into smaller units. Ask yourself how you can make these pieces perform more efficient. If you can’t get any more juice out of it, then make the code more readable and understandable. As you further break the code down into individual methods and components you can create unit tests to ensure that each portion is acting as intended. This will benefit future developers so that they can easily make changes and ensure that they aren’t breaking existing functionality.

7. Use this as an opportunity to educate others!
Always come away from every experience with something you have learned. It may be something you learned not to do, but either way you know better. I will repeat, hindsight is 20/20. Use it as the chance to help others know better too. Find a junior level developer and challenge them. Ask them what they think the problem is and see if they are capable of producing a better solution.

I read somewhere, developers have a high tolerance for working with ugly code (as long as they were the one who wrote it). No one wants to openly admit that they created a code catastrophe. However, really what we should do when we write code is not put others in harms’ way like we have been. In order to do that, we should make sure that the code we write can be broken down into as many chunks as possible. Complex problems require simple solutions. There is always the developer with an ego problem who tends to believe the opposite. They think that complex problems require tricky coding. Sometimes those developers are so concerned for writing a generic solution to the problem that they go above and beyond what the requirements ask for and in the end make it more difficult to troubleshoot or fix the problem.