Comments on: Managing complexity

By: josh coates

josh coates — Fri, 25 May 2007 23:52:22 +0000

great article.

“Simplicity is prerequisite for reliability.”
– Edsger W.Dijkstra

By: What About Thad?

What About Thad? — Mon, 02 Apr 2007 19:28:39 +0000

I couldn’t agree more, particularly with regard to code complexity. When code manifest defects, the impediment to resolving them is rarely a lack of efficiency or elegance of the code; it’s understanding the code and grasping the effects of unintended consequences both in the cause of the problem and its potential solutions. A few years ago I made the commitment to always choose the obvious way over the clever way, even at the expense of abstraction and reuse. The results are sometimes unattractive, but I feel like the resulting code is better fortified to survive out in the world when I’m no longer around to care for it.

By: Paul McFate

Paul McFate — Mon, 02 Apr 2007 18:32:13 +0000

Very perceptive analysis of complexity. As we have moved toward “enterprise-wide solutions” the complexity of systems has created a system in which we now spend a disproportionate amount of time just managing the complexity. That coupled with the fact the decisions (regarding solutions) get made as far as possible from the problem by people who do not have (and experience shows often cannot have) a full understanding of it.

By: Mario Hipol

Mario Hipol — Tue, 27 Mar 2007 20:54:02 +0000

This was a great post. I have actually forwarded it along to our CEO, President and COO. I have tried in the past to communicate the need for simplicity in our complex environment. It has only been recent that I have seen this change taking place. I think seeing someone elses input on the same topic really helps.

In an environment where we work several outsourced projects at once the need for simplifying complexity (OXYMORON) to the least common denominator is so very important.

Thanks for the insight.

By: PaulH

PaulH — Thu, 22 Mar 2007 03:03:15 +0000

I am not a trained computer scientist (CS) and because of that I have always leaned torwards more simple solutions. The more I learn and become more of a trained CS I realize how much of an advantage that is.

I am working on a project right now where I have to denormalize an extremely normalized (forth normal form and then some) database because of performance issues. I did not design the schema, in fact I was against the complexity from the beginning, not because I thought it was too normalized, but because of the amount fo code and layers that needed to be written to make it work. Unfortunatly it took replacing the designer to get our system to work as it should have from the beginning – less tables, less code and less time. I saw all of this coming, but because my arguments were only its too complex nothing was done to stop the problems from going forward. its really sad.

Thanks for the post.

By: Benjamin Hofmann

Benjamin Hofmann — Sat, 17 Mar 2007 22:48:59 +0000

This is very interesting. My experience revolves around development and internet technologies. Often senior level developers will find something “cool” on the web and want to implement it. It could be a new framework, open source project, design pattern, etc. My philosophy has always been to keep it simple. I’ve had many stressful projects where problems occurred and support and resolution were hindered because of complexity.

When I am considering allowing the developers to try something new I gauge it against the available skill sets as well as the needs of the application. Do most of the developers on the team have the skills to be able to jump in at any time to support or maintain the application? Can the junior developers be easily trained to provide some level of support? Will the new code be fully utilized or will we be adding complexity and features that won’t be used or aren’t needed?

Questions like these help us keep things simple while allowing integration of new technologies.

I appreciated this post. It supported my basic beliefs and gave me many more ideas and suggestions to think about.

By: Patrick Faulk

Patrick Faulk — Fri, 16 Mar 2007 23:15:30 +0000

Pete,

Your reference to “abandon(ing) some amount of functionality to maintain simplicity” got me thinking about the twin problems of accurately defining “requirements” and the tendency to focus on “tools” rather than “processes.” Too often “requirements” are defined in terms of features rather than outputs – which in turn should be defined by the process. Lean principles tell us to eliminate process steps that do not add value. In automating a process, we may expand the principle and decide not to automate certain process steps, because doing so does not add sufficient value to justify the added costs of increased complexity. This only works if you have a clear understanding of what functionality is in fact *required* as opposed to “desired.”