sept. 18

My team and I are working for two years on a big XP project now. Among the 8 developpers, we can find all the levels and all the educations. Some are engineers - for which IT is their first choice - and some were doing another job and have decided to switch direction.
Of course this does not mean that a kind of developper is better than another one, but this mean that we all have a different approach to a same problem, a different point of view, interpretation and understanding, depending of our experience, meaning habits, past and education.

Most of us had not done XP before this project, meaning that we had learned the methodology progressively and we have started to own it and to "customize" it to our needs.

For some of the group, XP has oftenly been considered as an excuse to do less. I mean I encounter people saying "No we shouldn't do that, because XP is iterative and so we should do only what we need for now. Let's do it simple, not more".
Said like that, it seems to be fully correct. Nevertheless, there is a huge misunderstanding behind this word of "simple".

Are we speaking of "simple code" or of "simpler solution" ?
There seem not to be any difference but it's huge and will drive all the future development. We could turn this question in another one - as it is in my view to exact ending of it - shall we throw the code in the future or shall we make it evolve ?

I have regulrarly fought during these 3 years to say : "simple do not mean to write very basic (too basic) code. So simple that this code will be thrown away in the next iteration because it is too simple (understand too low level, too concrete, without any level abstraction raised) to evolve".

I'm now reading the book "Extreme.NET" by Neil Roodyn. Not a very recent one so the .NET part is a bit outdated but the "philosophical part" is still very accurated.
There is a very nice sentence in it that, in my view, summarize all this to give a simple answer ;-)
And by "simple" here, I mean an answer that should be able to make all developpers think about themselves and what they produce.

"Simple does not mean easy. Developpers who are starting out often misinterpret this as "Do the easiest thing you can possibly do." [Pierre-Emmanuel Dautreppe's note : I would even say : "Do the more stupid thing you can"] This is incorrect; simple is often a lot harder to achieve than complicated. [...] The switch statement is easier to write, but the polymorphism provides a simpler solution."

A "simple solution" means a clear and open solution, a solution that will be simple to make evolve, that won't be reluctant to changes.

At the same time, Roy Osherove speaks about unit testing and call them TATs or TTLs, meaning "Throw-Away Tests" and "Tests That Lasts". For sure, it's a point that should make all of us think about our work.
For sure, I will come back often to this point in the future.



Didier Pieroux

Posted on vendredi, 5 octobre 2007 12:47

Very interesting reading!

Indeed, we need to use our brain a bit more to get a simple solution than to write simple code. And as we tend to be naturally lazy, I guess that we tend to favour simple pieces of code instead of simple solutions…

“Everything should be as simple as possible but not simpler.” (Attributed to A. Einstein)  Perhaps that the "simple code" tends to be the “simpler” stuff in our context.

Ajouter un commentaire

  • Commentaire
  • Aperçu immédiat