Simple Is not Simplistic

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 15: Line 15:
When the previous 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 introduction of defects (not to mention the fact that the users will be unhappy because the functionality, almost certainly, will not match their expectations).
When the previous 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 introduction of defects (not to mention the fact that the users will be unhappy because the functionality, almost certainly, will not match their expectations).
 +
 +
Doing the right thing--i.e., deal with all the above points appropriately--is a bit more difficult, and, in the short term, more time consuming, but, in the medium and long term the system will be easier to maintain and the users much happier.
 +
 +
Of course, there may be times when a solution is required very quickly and a clean implementation in a short time is impossible. However, hacking it should be a deliberate choice, and the real costs--the impact of the technical debt that needs to be paid back--balanced against the gains.
[this is still work in progress]
[this is still work in progress]

Revision as of 16:02, 8 May 2009

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 them 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 real problem. In fact, when implementing a new piece of functionality, the real problem has several aspects:

  1. Understand The requirements (is what the users are asking for, what they really need?)
  2. Think about how to fit the functionality into the system cleanly (what parts of the current system need to change, if any, to accommodate it nicely?)
  3. Think about 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?)
  4. Given all the above, think about the time necessary to implement it (and also understand when the users really need it)

Unfortunately, many developers think that a "simple" solution is: skim through point (1), and assume that the users actually know what they need; think about point (2) forgetting the "cleanly" bit; skip point (3) altogether; reduce the time at point (4) as much as possible by cutting corners. Far from being simple, that actually is a "simplistic" solution.

When the previous 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 introduction of defects (not to mention the fact that the users will be unhappy because the functionality, almost certainly, will not match their expectations).

Doing the right thing--i.e., deal with all the above points appropriately--is a bit more difficult, and, in the short term, more time consuming, but, in the medium and long term the system will be easier to maintain and the users much happier.

Of course, there may be times when a solution is required very quickly and a clean implementation in a short time is impossible. However, hacking it should be a deliberate choice, and the real costs--the impact of the technical debt that needs to be paid back--balanced against the gains.

[this is still work in progress]


By Giovanni Asproni


This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools