Something that took me a while to learn is how to be balanced when deciding on how to architect an application. Since at my current job I was thrown into a hybrid Architect/Developer position due to the small size of the company and my team, I didn’t really have any experience with doing it. After almost a year at it I decided to look back and see what I have done and how I can learn from mistakes and successes.
Remember Why You Were Hired
Why did your company hire you as a developer? If you answered “To create great software for employees and clients to use” you are wrong. You get hired at a company in order to create value for them. In the end, any software that you create needs to have a solid ROI, whether it is used by employees or clients. Does this mean that you should throw together whatever crappy code you want until it just works so that you can do it as quickly as possible? No, good architecture requires you to take maintainability into account as well since the business’ money will also be used to maintain the code (actually, more will be spent on maintaining than building). The problem comes in when a developer wants to solve a problem with a solution that is more complex than it needs to be and the extra time that it takes to implement that solution is really money wasted for the business. I’ll look into this in detail throughout this post.
The Folly of Anticipating Change
In the world of software, change is inevitable. With this in mind, developers naturally design systems so that they are adaptable and easy to change. However, there is a difference between creating a system that is easy to change and developing a system that anticipates change. If you try to anticipate changes before they come, you are wasting your time and, more importantly, the company’s time. You don’t know what changes will come down the line and if you anticipate a change that doesn’t happen then you will end up over-engineering the solution and causing a huge headache down the road. Focus on what is needed now while building an infrastructure that can change with as little effort as possible (such as using dependency injection and programming to interfaces). Rather than trying to build a system that will never have to change, build a system that embraces change and expects it. In the end, it’s really not that hard to change software, that’s why it’s called soft-ware. So stop worrying so much about what will come down the road and concentrate on the requirements right in front of you.
Design Patterns = Complexity
A final point on this subject (for now, at least) is that it is important to remember the cost of design patterns. Design patterns are great when they are applicable but they don’t need to be the first place you go to in order to solve every problem. This is because design patterns by their very nature add complexity to your application. This complexity is not always necessary. Be careful not to over-engineer your application just to use a design-pattern you want to try out. Every situation is unique; the word “pattern” implies a situation that repeats. Therefore, you may have to come up with a unique solution that fits the problem at hand. It is possible to architect a well-designed, elegant solution using object-oriented principles without having to adhere to a strict, named pattern. When a problem or situation arises and a design pattern fits the bill, then by all means use it. Just be mindful of the consequences of using it and make an informed decision.
All in all, the moral is to use balance. Remember that you are ultimately at your job to create value for the business, not build a beautiful piece of art to show off. Do you care that the pipes in your house are works of art or that water runs when you turn the knob? Build your applications so that they embrace change, not anticipate change. And don’t over-engineer your application for a design pattern’s sake. Use them only when you really need to. These principles help to provide well-designed, maintainable solutions that will bring value to your business.