Unfortunately, many developers skim through point (1), and assume that the users actually know what they need, then think about point (2) forgetting the "cleanly" bit, skip point (3) altogether, and try to reduce the time at point (4) as much as possible by cutting corners, and call this a "simple" solution, when, in fact, it is a simplistic one.

Unfortunately, many developers skim through point (1), and assume that the users actually know what they need, then think about point (2) forgetting the "cleanly" bit, skip point (3) altogether, and try to reduce the time at point (4) as much as possible by cutting corners, and call this a "simple" solution, when, in fact, it is a simplistic one.

-

When this approach is used again and again to implement the various bits of functionality of the system, the net result is an increase of the internal complexity of the system, which will negatively affect maintainability and extensibility, and positively affect the appearance of bugs.

+

When this approach is used again and again to implement the various bits of functionality of the system, the net result is an increase of the internal complexity of the system, which will negatively affect maintainability and extensibility, and positively affect the appearance of bugs (not to mention the fact that the users will be unhappy because the functionality is not what they expected it to be).

[this is still work in progress]

[this is still work in progress]

Revision as of 13:57, 8 May 2009

"Very often, people confuse simple with simplistic. The nuance is lost on most." Clement Mok.

"Simplicity before understanding is simplistic; simplicity after understanding is simple." Edward de Bono.

First of all a couple of definitions (from the "New Oxford Dictionary Of English"):

simple easily understood or done; presenting no difficulty

simplistic treating complex issues and problems as if they were much simpler than they really are

I'm sure that most developers know that simple software is more maintainable, has fewer bugs, has a longer lifetime, etc., and that they always try to implement the simplest solutions they can possibly think of. We also know that many of those developers often end-up with unmaintainable code very quickly.

In my experience, the most common reason for that is due to lack of understanding of the problem being solved. In fact, when implementing a new piece of functionality, the real problem being solved has several aspects:

The users' requirements (is what the users are asking for, what they really need?)

How to fit the functionality into the system cleanly (what parts of the current system need to change, if any, to accommodate it nicely?)

What and how to test (How can I prove that the functionality is implemented correctly? How can I make the tests simple to write and simple to run?)

The time necessary to implement it (when do the users really need it?)

Unfortunately, many developers skim through point (1), and assume that the users actually know what they need, then think about point (2) forgetting the "cleanly" bit, skip point (3) altogether, and try to reduce the time at point (4) as much as possible by cutting corners, and call this a "simple" solution, when, in fact, it is a simplistic one.

When this approach is used again and again to implement the various bits of functionality of the system, the net result is an increase of the internal complexity of the system, which will negatively affect maintainability and extensibility, and positively affect the appearance of bugs (not to mention the fact that the users will be unhappy because the functionality is not what they expected it to be).