Test First Development/AgileCategory: Programming | 2 Comments |
20 06 2005 |
Took a class last week on Test First Development taught by Brian Button. I really like a lot of the ideas associated with this methodology. There were a couple of issues I have with some of the ideas though. I like the idea of writing a simple test, then writing some simple code for that test, then writing another test and some more code and then refactoring. The problem I have is that Brian believes that the code should dictate the architecture and you shouldn’t spend any time designing the application and instead just start with a piece of functionality and implementing. His point is that if you follow the test, code, test, code and refactor strategy, you will know when you need to create an interface for any particular class you are developing. He believes with the advances in the tools available that the IDE will do all of the hard work of extracting these interfaces for you. My problem is when I tried to use this approach I felt lost in the beginning without any guiding generalized design. I feel that this caused me to take more time trying to refactor to the correct design and I still ended up with the same thing I would have if I had started by creating a general design to follow in the beginning.
I’m not saying that for some people this approach doesn’t work, but for me it is just easier to come up with some extremely general rails to follow and if the design needs to change I can make that change when it is necessary. To relate this programming strategy to a video game :), it is like playing a new RPG and not knowing what your mission is and just wondering around talking to people until you finally figure it out. You may start off in the completly wrong direction and then have to do all of this extra work to get back on track. That is how I feel when I start coding without a general design to follow.
Part of my problem is around agile programming in general. I understand the idea of not putting in functionality that is not part of the immediate requirements. I agree with the concept of coding for today and refactoring for tomorrow, but I don’t see the problem with spending a small amount of time coming up with a flexible design that will make changes and maintenance easier down the road. I don’t like the saying “Sometimes you have to write bad code.” It is a horrible methodology just to save a little time in the beginning and most of the time when they say “Well this application just isn’t going to be around long enough for it to matter,” most of the time those are the applications that are still around 10 years later. This is the whole reason we have all of this horrible unmaintainable legacy code still around to this day.
This entry was posted
on Monday, June 20th, 2005 at 8:22 pm and is filed under Programming.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Nate,
If I gave the impression that you should never draw some pictures before you start, I was wrong. There is nothing wrong at all with spending a few minutes or an hour thinking about what you’re about to do. They keys are to know when to stop, and to use what you learned from modeling, but still let the code guide.
Modeling on paper is a great way to organize your thoughts, but it is still just a guess. Code is real.
— bab
I’m really starting to see the advantages with a n-tier configurable design where everything is developed to an interface. I think the advantages to this type of design are tremendous and it allows for easy reimplementations of different parts of the application without it affecting other aspects of the application.
I’m also a big advocate of AOP and proxying of aspects of an application that cross cut the entire application like transactions and security. I’m at the point that I really do not feel this belongs in the code.
Basically I’m falling further and further into the Spring mentality. Dependency Inversion with Dependency Injection makes life a lot easy for everyone, from the person writing the application to the person maintaining the application.
More on subject I feel that starting with a 2 tier or 3 tier design first is a good starting point. From your class I feel that your opinion would be that I’ve done too much upfront design, but I feel that in most applications I’m going to end up working my way into this basic design almost every time, so it makes sense to me to just start there and if the code refactors away from that design, then it does, but most likely it won’t and typically I end up with a nice configurable and very flexible system.
Almost all of my experience has been in the J2EE realm, so there may be cases outside of that realm that a n-tier architecture does not make sense, but from a J2EE or SOA perspective I think it makes a lot of sense.