Complexity

jplindstrom on 2003-01-16T21:31:23

http://www.tmtm.com/insanity/2002/11/09.html#a386 Complexity, I would assert, is the biggest factor involved in anything having to do with the software field. It is explosive, far reaching, and massive in its scope. -- Robert L Glass, Communications of the ACM, November 2002

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Unknown

So how do you remove complexity?

What do you really want?

brian_d_foy on 2003-01-16T22:08:33

You remove complexity by redefining the problem, abandoning unnecessary constraints, or fixing the root of the problem. Most of that means figuring out the actual desired end state rather than the perceived one. For instance, "I want a list of customers" instead of "I want an HTML table generated dynamically from our legacy database". In the military we call this "commander's intent"---things are going to go to crap and rather than sticking to the plan, we improvise, adapt, and overcome to acheive the commander's intent rather than the plan in place before things went to crap (although sometimes our methods are less than laudatory).

Fools ignore it - "Can't you just..." use MS SQL server for everything under the sun?

Pragatists suffer it - just brute force it, (or install Microsoft) and add more to the budget for the extra work. Modify everything to work around problems that wouldn't be there in a different approach.

Geniuses remove it - use the right tools for the right job, but don't make the tools the job. DBI, for instance, removes the particular database product from the problem. The database servre no longer has a stranglehold on the design.

Re:What do you really want?

jplindstrom on 2003-01-16T23:08:11
Great answer, it got me thinking.

"You remove complexity by redefining the problem"

This I like. A lot.

"Geniuses remove it"

I guess one way of removing complexity is to just swipe it under the rug--data hiding and modular design. By definition you hide complexity and provide a simpler way of looking at things.

Re:What do you really want?

brian_d_foy on 2003-01-17T00:18:21
Sweeping it under the rug is the pragmatist approach---that's just dealing with it. Abstraction means the complexity is still there even though it is hidden.

My DBI example may have been ungood, but then again, you can completely remove the database server from the problem---not just in abstraction but also in reality. You can use DBI with flat files (just like we do in Stonehenge's DBI course where we write a Zork text adventure game starting with flat files and DBI, then at the end convert it to mysql without changing any of the code (other than the DSN)).

I wish that I could come up with a better example, or one not based in technology.

What's that thing that Captain Kirk did in Star Trek II? :)

a bigger rug

educated_foo on 2003-01-17T03:11:32

So how do you remove complexity?

See previous journal entry. (was that deliberate?)

Re:a bigger rug

jplindstrom on 2003-01-17T15:32:49
Not really deliberate, no :)

It's an interesting angle, but I think writing the same thing in Perl is rather a more efficient way of managing the same amount of complexity.

But the custom-vs-standard-protocol issue can be an example of implementation complexity being removed by slightly redefining the problem (as mentioned above).

In another project, I was to write a server providing log reports. The initial (bad) idea, which I managed to veto, was to call this from an ASP application using some kind of custom COM control which we would have to write in addition to the ASP application itself. But since we ended up using HTTP we never had to write the COM component--it was already built by someone else and we could buy it instead of build it.

No integration problems, no development time, no debugging, no maintenance. Overall, less complexity for us to handle. Of course someone have to deal with the complexity (the component vendor), but if it's not on our radar anymore it's effectively gone.