@Steve We are agreeing more than not. I just wrote the comment to point that “easy to understand and lacking in unnecessary complexity” can also be misunderstood if not thought carefully.

Cheers
Francisco

1. Write a test that fails, giving a “red bar”.
2. Code the quickest / easiest way to a green bar.
3. Clean up the mess you made.

Kent Beck’s presentations in particular really stress the idea of getting to a green bar quickly, even if it means making a mess of the code. His point is, as I understand it, to spend as little time as possible with a “red bar”, since time spent with an outstanding broken test is a kind of risk — your safety net for modifying the code has a hole in it. Once the bar is green — all tests are passing — you’re free to spend as much time as needed to make the code simple and clean. And of course, in XP/TDD, taking that time is not just a freedom, it is a responsibility. :)

Thanks for your feedback. I’m glad you brought up the subject of development time and cost.

When developing a piece of code, it is important to consider the overall (not just the immediate) development cost.

In keeping with my earlier definition of “simplest”, a solution that is easy to understand and lacking in complexity will result in code that is less costly to maintain over the long haul.

In other words, a collection of inexpensive individual parts does not necessarily result in an inexpensive system.

–Steve

I kinda think that the simplest thing should be in reality the quickest thing that could possibly work. I dont like to introduce hacks into my code either, but that has more to do with the standards I have when coding than with the “simplest thing” concept itself.

I like to think that way because that’s how it is perceived by the customer, who is paying for my development time. In my mind he probably would want to have the quickest thing that could be done, having in mind the quality standards that have to be achieved.

Even because when you are aiming at the solution that is easy to understand and lacking in unnecessary complexity, you are probably doing the most complex thing that could possibly work, in terms of development time.

Cheers,
Francisco