Smalltalk Tidbits, Industry Rants

What we really need...

The best answer, Dr. Neumann says, is to build computers that are secure and stable from the start. ... "We throw this together, shrink wrap it and throw it out there," he said. "There's no incentive to do it right, and that's pitiful."

Brad Appleton's blog has an interesting article over here on simplicity: Simple Ain't Easy Myths".

These are the quotes from the article that summarize the discussion well.

"A simplistic solution often does not work One definition of "simplistic" might be the false appearance of simplicity. It's not enough to seem/appear simple. It also has to work (successfully) in order to actually be simple"

"I think that true simplicity is about minimizing and managing overall complexity. Complexity in software design and development comes from the sheer size and complexity of the problem we are being asked to solve, and the richness and vastness of the interconnected maze of interactions within the system and between the system and its environment. The overall complexity of the system is dominated far more by the interactions between the parts that makeup the whole than it is by the parts alone. For any non-trivial system, simplicity often has less to do with the number and kind of different things involved and more to do with the number and kind of interdependencies between them. So achieving simplicity is less about managing "parts" of "things" or individual point-solutions, and is more about managing rules and relationships between the parts and things and solution-sets."

"When dealing with large or complex systems (like most software, and software processes) the number of things (scale) and different types of things (diversity) that need to be managed is overwhelming. If we can come up with a modicum of modest, simple rules & principles to govern our design decisions in ways that help us minimize and manage interdependencies, eliminate constraints, and remove waste, then we are on the path to solving the real problem and meeting stakeholder needs in a way that is both simple and sustainable."

ps. Sorry about the formatting but the submit page for the web site comments wasn't working as expected today. For some reason the embedded text editor wasn't showing up in Safari. Hmm... I guess it's complexity? ;-)

Comment by James Robertson

The HTML Javascript editor I use - TinyMCE - doesn't support Safari

The problem in many cases is that large networked systems are thrown together with many pieces that taken by themselves are well known and essentially simple in operation. The issue arises when these systems interact in unexpected ways due to the simple interfaces used to connect them. It's these simple interfaces that fail when problems arise. Or maybe they really should be called simplistic interfaces since they don't deal with the reality of what is needed to build distributed fault tollerant systems.

As has been said by Albert Einstein, "Everything should be made as simple as possible, but not simpler."

The problem seems to be that each component is a bit too much "simplier", especially when it is placed into operating contexts that it really wasn't designed to interact within. I see this all the time in code and full component systems where they can't handle error situations or inputs from other systems that deviate from the expected "parameters".

We also need systems that learn and can adapt to new situations including those between the components in a distributed system.

Unfortunately even in languages like Smalltalk it's too easy to write "brittle code" that can break at the slightest variation of input or expected use cases. Just like coding style, or test driven development, fault tolerance to errors and new use case variants is a coding disipline. This is especially a challenge when large groups of people work on a software system.