A Funny Java Flavoured Look at the World

Saturday, May 20, 2006

The Simplest Thing that Could Possibly Work

For a long time I never really understood this comment or this way of thinking. It seemed such an odd thing to say to advocate. It is similar to Test Driven Development where you have a test and then you do the simplest thing to make it pass. I believe their is also something similar to this idea in Extreme Programming which one of the key principles is

Simple Design.
"A program built with XP should be the simplest program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in XP this is brought about through "refactoring", discussed below."
I have for a long time suffered from putting in overloaded methods in case people in the future might need it or adding in functionality that wasn't needed to solve the current problem but might be useful later. About six months ago after reading something like the principle above and hearing other people say similar things, I have tried to give this waste of time up and just do the simplest thing needed

It wasn't until I tried writing a junit test first that I really started to understand what the real meaning was. I did a test and then just passed back what ever value I expected. Then when I tried another test I added in the functionality to make that pass. When I tried some other tests to try and break the code I found I had just enough code to allow the code to do what I wanted and no extra code. It was at this point I realised what the this statements means, just do the simplest thing to make the code work, anything else is just wasting your time.

I also take it to mean that do the simplest thing on this piece of code because there is another challenge waiting for you to write some more code. It means you end up writing more useful code that people are going to use rather than extra methods that people don't need but might in the future (but who says they will)

The statement doesn't mean you should just wedge in any old code, I take it to mean that you should just code enough code to solve your current problem but the code should be easy to extend, it's just that you are not going to that now.

The reason why I am blogging about this is because I saw this article on Artima today about the topic in the title, this is actually the last part in a series of articles. I recommend you read the article as it explains the idea in a much better way than my interpretation.

One good reason the article recommends you should do the simplest thing is because you often don't understand the problem fully when you are starting out and doing it this way means you don't waste to much time and code when you realise the problem is different to what you thought.

This quote really gets to the heart of the statement

In programming, a lot of simplicity comes from knowing what matters and what doesn't matter. A lot of times a program is made complicated because it's attending to details that aren't needed, or could have been avoided, or could have been relegated to something else.
Everyone has probably come across the actions the quote describes by accident. There have been times when for some reason I have lost the code I was writing, I had spent a week writing the code but when I found that it was gone it only took me a day to rewrite it and do it differently and more efficiently than before. The reason is when you tackle a coding problem the solution comes into investigating the problem, write some code that works and some code that doesn't and then refactoring it to be more usually more simple. All the knowledge is in your head through all the work you have done trying to solve the problem and knowing what you need to do to solve the problem.

Here's the link, enjoy

http://www.artima.com/intv/simplestP.html

I would be interested to read other people's interpretation of the doing the simplest thing that could possibly work because recently it's something I have been trying to remind myself of when tackling tasks.

2 Comments:

  • As Ron Jeffries has pointed out, though, the simplest thing is not the same as the easiest thing. Many programmers make the mistake of thinking that by taking the easy way out they are doing the simplest thing. But it often takes a lot of time and effort to achieve true simplicity.

    By Blogger Doug, at Mon May 22, 05:19:00 pm 2006  

  • very true. I think the target of trying to make the simplest code is code that is usually not very long but simple and elegant. It's usually when you see like a great piece of code, I am always amazed how small and simple it is.

    You are correct that it isn't the easiest because there is thougt into the design.

    it gives you something to aim for, it's like trying to write the perfect piece of code, you can never quite do it.

    By Blogger The Hosk, at Mon May 22, 11:30:00 pm 2006  

Post a Comment

<< Home