It ain’t easy to be simple
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away (Antoine de Saint-Exupery)
Everything should be made as simple as possible, but not simpler (Albert Einstein)
What do these quotes, the Rube Goldberg machines, Occam’s Razor and the KISS principle have in common (Google and Wikipedia keep impressing me what you find by just searching for a simple little word)?
Well, they are all about SIMPLICITY (or lack thereof)!
Simplicity is also a central tenet in software engineering and development.
I’ve seen really great pieces of software that unfortunately were complex and awkward to use. I’ve seen classes that were simple to use, but that had so many different responsibilities that they were hard to understand and maintain. I’ve seen design rules that were supposed to make implementation for the programmers as easy as possible, but resulted in a big pile of overly redundant code (this is also not simplicity).
Simplicity is all about reducing this complexity as much as possible.
In software engineering, this principle should be applied wherever and whenever possible.
When designing and implementing, the class’s internals should be simple (not too much responsibility for a single class - this is where high cohesion comes into play), but also its interface should be simple (the Spring guys, for example, are doing a great job wrapping and simplifying complex third-party classes and components).
But this is also true for a system’s architecture. System components should be as simple as possible, resulting in probably more, but simpler components.
And last but not least, simplicity also makes sense for processes - the build process and the development process (I don’t want to use the agile buzzword here … oops, too late).
I think a good metric is, how easy it is to describe a component. If you can say in a few sentences, what a component does, then it is probably simple enough. This applies to classes, but also to system components or subsystems.
And a final note: the goal is avoiding complexity, not negating it.
August 5th, 2006 at 11:06
Hi Heli!
I agree with you that Software Engineering should follow the KISS principle and that software architecture and classes should be describable with a few words.
Albert Einstein also said that people who do not have proper and deep understanding about the topic they are talking tend to complicate things. The problem in software engineering is that the customer mostly do not understand the topic he is speaking about. Also the complexity of requirements and user expectations have increased over the last years. This leads to the problem that the probability of failures increases due to size and complexity. Take Microsoft’s Vista for example, the orignial requirements for Vista were to ambitious that even a company like Microsoft could not realize.
I think to avoid or reduce complexity for an overall system is only possible in an isolated environment or with an adequate amount of time. The only possiblity in my opinion to reduce complexity is to invest a lot of time to define and priortize the requirements with the customer. As we all know this causes expenses nobody wants to pay. In most commercial projects the policy maker are economic people with no proper understanding in the field of software engineering. Furthermore, the software engineer mostly has no knowledge in the domain of the customer. Add the challenge of rapid ongoing change in the environment of software engineering. To compete this challenges i think you need a very motivated and talented team that gets support from business processes.
August 8th, 2006 at 22:34
Very good point, Mario. Simplicity has to start way before implementation, design or even architectural planning takes place.
It is already the phase of gathering and analysing requirements and planning the overall functionality of the system where a lot of emphasis should be put on making everything as simple as possible.
You mentioned the problem that customers and developers live in two different worlds. The customer knows his domain and business and he knows which problem he wants solved (though he usually does not know how to solve it). The developers know their business, which in most cases has not much in common with their customer\’s. This commonly called impedance mismatch makes it difficult for these groups to communicate efficiently, which may be a reason why they usually don\’t communicate (another reason is of course that the customer cannot be expected to answer questions of hundreds of developers).
Even bridging this gap with someone like a business analyst does not necessarily solve this problem. This person has to translate the problem from the customer\’s domain so that the developers understand it. He also translates questions from the developers and asks them to the customer. Aside from the rare case that this person is an expert in both domains, information loss is imminent.
Enter simplicity. If the problem domain is simplified (or abstracted) as much as possible, the business analyst is much more likely to understand exactly what the customer wants. On the other hand it\’s much easier to convey the real problem to the developers without all of this white noise around.
In a perfect world, the customers and developers might even use the same abstractions or metaphors for the same thing.
Hey, in this perfect world they might even talk face to face with each other!