We have a site which is hugely complex in its implementation. Conceptually, it is simple – a web-based catalog. But the implementation has become a multi-layered nightmare.
Can anyone indicate a “rule of thumb” for measuring when something has become too complex for the job it is doing?
1
Einstein’s Razor applies for the general case, whether you’re making a simple website or a massive multi-purpose applicaiton.
It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience
You’ll likely find the simplified form far more quotable: Everything should be made as simple as possible, but no simpler.
When you are creating a new system and have the choice between two development models, always select the one which leaves the system simpler unless you have a compelling reason to introduce the complexity. This compelling reason should be documented in such a form as to make sense to whomever inherits your code.
Unfortunately, it sounds like your specific case is an existing system that has become more complex over time. This leads you into the opposite principle, specifically If it ain’t broke, don’t fix it. A system that works should be left as-is, until it either breaks or a replacement is ready.
The question as to when you should replace vs. simply continue on is a management one, and really comes down to the cost in actual or opportunity dollars spent to maintain the considerable technical debt you have in the old system against the cost it would take to design, develop, deploy, convert, and support a new system.
The rule of thumb I always employ is to code just enough to meet the requirements. Using a minimalist approach ensures you can grow organically rather than assuming what the user wants. Its what made google such a great website in my opinion. Keep it simple
Now if the implementation is too complex, you may want to use MVC more effectively
A piece of software is a machine, with buttons, pipes, moving parts and everything else that might be part of a car, or some device at a factory, except that they’re represented in code. Imagine your machine (the web site) if brought to life as physical device. Are there unnecessary extra parts? Too many (or the wrong kind of) knobs? A strange exhaust stack? What is it really supposed to do?
Every system is different, and things can’t be measured the way they can in the physical world, so rules, ratios and formulae aren’t always available to the software engineer. However, a few guidelines might help when analyzing of your system:
-
Is there an internal Wiki or FAQ with detailed steps that must be performed in order to add or change functionality? Are these steps really necessary, and if so, can they be automated?
-
Is there just one person that know how the whole system goes together? What if he/she leaves the company?
-
Are there layers of abstraction that have only one real usage? (i.e. interfaces with only one concrete implementation).
-
How many data transformations occur between endpoints of the system? In some applications, you could use JSON up and down the stack without problem. This isn’t appropriate in every situation, but every time a data transformation occurs, evaluate if the layer requiring the transform is truly adding value.
-
Are certain technologies employed that were mandated for political, cost or other non-engineering reasons? (i.e. “We have to use Oracle because the CEO said it’s the best”)
-
For usability, have feedback been solicited from users (or people that didn’t work on the project)? Are there too many clicks, cluttered pages?
-
If you had to identify one “secret sauce” area of the code, what would it be? Could this functionality be extracted into a separate module allowing other pieces to interact with it in a cleaner manner?
-
Finally, could you design a simpler system? Make a prototype, and gather feedback from your co-workers. This is the best test of all.