Archive of UserLand's first discussion group, started October 5, 1998.

Meditation on Simplicity vs Complexity

Author:Russell Lipton
Posted:9/26/2000; 6:38:21 AM
Topic:Meditation on Simplicity vs Complexity
Msg #:21708
Prev/Next:21707 / 21709

I was involved in some heavy-duty CASE work for several years in the 1980s with a few large and well-known multinational corporations. The motives were (and remain) laudable: helping people manage the extraordinary complexity of large-systems development more productively. When you've got > 500 people (often > 1000) co-developing and co-maintaining stuff, you've got problems ...

People here scarcely need to be reminded of that nor the many tools and processes that admirably support large-scale development: design reviews, code inspections, test cases, walkthroughs of all kinds and such.

Yet, what we learned is that we don't know (and may never?) be able to manage that complexity without introducing another type of complexity that is equally pernicious.

Cf namespaces?

It isn't that our attempts to reduce organizational and systems complexity are ill-designed. Generally, our most brilliant software engineers throw their mind-bodies herocially at the task. The problem seems to be something in our human and cultural wiring - if indeed it really is a problem.

(Discursus: the giantism in our government, corporate and software cultures are not perhaps unrelated and their presumed benefits scarcely demonstrated after a mere forty years of real-time experimentation on people world-wide).

Namespaces appeal greatly to me intellectually. I am not expert enough to know whether they will work in the real world. Hey, the dream of a semantic Net gets all of my old CASE and expert system juices flowing. Surely, if we just throw today's (tomorrow's) expertise and processors at it, the electricity will jolt frankenstein to life, no)?

Meanwhile, Userland's approach to software and people matches my own experiences.

While it seems "wrong" to place people in the loop (cf Dave's comments today on nodetypes in OPML) if the loop can be automated, we found that people are always in the loop. Good!

Which is more human - emailing one another to fix nodetypes or trying, with one another, to keep namespaces straight? (That is a sincere question: I don't know).

Inexperienced programmers nearly always choose task automation as an unqualifiably justified goal if "it can be done". Maybe the wise programmer knows when to choose to include people explicitly in the computational dialogue, lest by "managing complexity", we reap unintended complex consequences that aren't necessarily people-centered.

There are responses to this message:

This page was archived on 6/13/2001; 4:56:51 PM.

© Copyright 1998-2001 UserLand Software, Inc.