Epic Battle: Simplicity Versus Complexity

I’ve seen this too many times to not consider it a common theme in every project. I’m sure I’m not going out on a limb when I say that everyone starts their project with the goal of simplifying their current process, but with all that can be accomplished with the Extranet framework and starter solutions, the temptation to add additional complexity is often tough to resist. I submit the following for your consideration:

Complexity is evil and should only be allowed into your project when absolutely necessary

Strong statement, I know, but I find that we don’t ask the question “Is there a simpler way?” often enough. I’ve been wondering lately why this is the case and have formed a theory:

Simple is boring and we don’t like being bored

Now, before you disagree with me, let me explain.

There are many reasons why complexity will creep into a project.

We don’t spend enough time challenging current processes
It’s an all too common occurrence. We spend the time to document how things are getting done in the current processes with the intent to have it serve as a baseline for processes to be configured into the new system. We frequently don’t spend enough time asking why things are done the way they are. By not understanding the reasons for existing complex processes, we miss the opportunity to simplify them. Processes can become complex for a variety of reasons. Complexity can come from changes over years of use where special cases creep in to accommodate holes in the standard process. Understanding why the complexity is there affords us an opportunity to address the root cause and avoid the need for the complicated workaround.

Historical technology limitations force complexity where there shouldn’t be
This is an easy one to identify. For example, if the “technology” is paper-based forms, a common means of dealing with multiple forms is to force the researcher to provide the same information multiple times on each form. A paper system also forces your hand on how the review process is best facilitated, which is often cumbersome and involves multiple copies of the same documents.

Even if the “old” technology allows the process to be conducted online, there are countless examples of complex processes that are forced upon us by the technology in use at the time. In all fairness, your Click Extranet-based implementation will fall into that camp in the future as newer versions of Extranet allow for even simpler processes. This one is tough to avoid assuming evolving technology will continue to allow us to improve over time.

When presented the opportunity to simplify, we often choose to do more rather than simplify what we have
I blame this tendency on us being human. I’ve long held the belief that if we aren’t challenging ourselves to do more, better, faster, we get bored. As developers, we all have a character flaw that drives us to things that are challenging. It’s just more stimulating. The reality, though, is this drive to “complexicate” doesn’t serve us or our users well. With complexity comes the burden of reduced quality, higher development and maintenance costs, and a steeper learning curve for the end users.

As a developer myself, I’m not above this temptation. We all want to build a better mousetrap without turning it into a Rube Goldberg invention. We just need the discipline to recognize that, when a simple approach works well, there is no need to improve it. When favoring a complicated solution, ask yourself why you are so proud of it. Is it because it’s the most elegant and direct way to meet the requirements, or are you just proud of how complicated it is?

Not leveraging the patterns promoted by Click Extranet
This is a tough one. All of bring our own experience, prejudices and design preferences to the project and when they aren’t directly supported by the conventions, patterns and metaphors and tools, provided by the chosen framework, we have a decision to make. Do we re-examine our personal preferences in light of what the platform makes easy albeit in a certain way, or do we assume the increased complexity involved in not leveraging features of that platform and instead “skiing out of bounds”?

As with all things, there are many paths to the final destination. choosing to adopt the path that is already paved by the chosen platform will allow you to get there sooner and with fewer scrapes. I understand the desire to do it “your way”, but my advice to you would be to give the simple path a try first and only create your own roads when the existing ones can’t get you where you need to go. The more you can leverage the Extranet platform and starter site, the simpler your deployment project.

…

Complicated just takes longer and costs more. It’s important that we continually ask ourselves,”Is this complexity really necessary?” and “Is there a simpler way?”

Cheers!