This morning at Entrance, we got the low-down on making standard chunks of code into modular blocks from Kenny, Josh, Patrick and Brad.
We have seen a lot of software come in the door that doesn’t scale, isn’t able to be modified easily and can’t be easily tested on a large scale. In many cases, this is because in-house or freelance software teams have operated on short term tactical implementation budgets, without considering future implications of shortcuts taken while under fire. As software consultants and engineers ourselves, we fully understand that requirements change, especially as software ages, but prefer to take those changes into consideration when first creating code, rather than having to go back in and redo work later.
Software design is a long-term investment.
When a company first invests in software, its focus is often to automate a process quickly, so that end users see value as soon as possible. While it is not technically incorrect to create concrete code, an abstraction layer that separates code by functionality can help make it easier to change that functionality as needs inevitably change. Software built in a modular fashion can be separated and updated by module – like changing parts on a car. If only the battery is broken, as long as its separable from the rest, it can be easily replaced. Custom software is, by nature, specific to the business logic best suited for each situation. Because the business needs can be so unique it has the danger of becoming equivalent to an exotic custom vehicle. And everyone knows that luxury automobiles are more expensive to maintain because parts can be harder to get at, might need a specialized repairman etc. When an application is sure to see years of growth and use, we encourage it to be built in a way where parts can be changed out. Realistically, not all software is designed in this way, so we also actively teach our consultants to identify how to improve design for long-term flexibility.
Creating maintainable Software
Here are some examples of the design principles we try to follow:
Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns
Unit Testing: http://en.wikipedia.org/wiki/Unit_testing
SOLID: http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29
Factory Pattern: http://www.dofactory.com/Patterns/PatternFactory.aspx
Review C# & Interfaces: http://msdn.microsoft.com/en-us/library/vstudio/ms173156.aspx
Code Smell: http://en.wikipedia.org/wiki/Code_smell
For more detailed conversations about following these design principles, check out our Software Developer Tricks section of the blog, where our consultants give insight into best practices.