Quick should never imply dirty

Posted by Chris on December 06, 2006

My friend and former colleague “Magnus MÃ¥rtensson”:http://blog.noop.se/ recently wrote about “his feelings”:http://blog.noop.se/2006/12/02/When+Quick+And+Dirty+Becomes+Just+Dirty.aspx about “YAGNI”:http://c2.com/xp/YouArentGonnaNeedIt.html and how he instead would like us to follow what he calls “GYCFKSTF” (Give Yourself Credit For Knowing Some Things First). I do not quite agree with what he says (but I guess you knew that already Magnus ;) and started to write a comment, but when it became a bit long I decided to post it here instead.

There is nothing in YAGNI (or other things in XP) that says you cannot “give yourself credit for knowing something”. From the C2 page linked above, here is a relevant quote:

bq. This doesn’t mean you should avoid building flexibility into your code. It means you shouldn’t overengineer something based on what you *think you might need later on*.

I do not interpret YAGNI the same way as Magnus does. I definitely agree that there is a need for some balancing critique of popular things such as agile and terms such as YAGNI. But I think that it will be difficult to come to a conclusion when the different sides have such different interpretations of what they are promoting/critizising. The readers will have to decide for themselves which interpretation they agree with.

What I find that Magnus is doing here is taking something he does not really like (YAGNI), looking at it from some angle and/or interpreting it in one way which makes it look like a bad thing, and then saying that this is the essence of that thing, so naturally it is a bad thing.

To me, YAGNI is just XP’s way of implementing the lean principle of deferring decisions until the latest responsible moment. I do not think that anyone can complain about how this principle works for Toyota and other lean (non-software) companies, but at the same time I realize that what I am doing is just the same thing as Magnus. I am looking at something that I like (YAGNI), from an angle that makes it look like a good thing, and saying that this is the essence of that thing, so naturally it is a good thing. Debates like these will never have any winner, but then again I do not think the meaning of debating is winning. By discussing it everyone is a winner, since hopefully we all learn something in the process. :)

On the smaller scale, YAGNI and TDD says that we should try and solve our problem (get to green) as fast as possible, cutting corners while doing so. This might result in us adding a “public IADAL AAccess” property. However, when we are at green we are encouraged to think, to remove duplication and to improve our design. In this case though we might just be happy with our implementation and add the next test, the one for the IBDAL. Since we need to get to green fast, we would again just add the “public IBDAL BAccess” property. However, now we start to see duplication. At this stage we must refactor to improve our design.

If we do not continuously refactor to improve the code and design, everything will turn into a “BigBallOfMud”:http://www.laputan.org/mud/. Therefore I do not agree that YAGNI will turn into YAGFI (You Ain’t Gonna Fix It!). Agile practices require a lot of disciple, more so than any other method I have encountered, and being professional and always thinking about how the code and design can be improved is part of this.

On the slightly larger scale, YAGNI says that we should “Always implement things when you *actually* need them, never when you just *foresee* that you need them.” It does not say anything about how we should implement things (e.g. “you are not allowed to use a generic version!”). I like to think about it as “do not design for future requirements, but do design for flexibility”. So what would be YAGNI then? Lets say that we “know” that in the future the DALAccess class will need to support feature X (maybe serialization or whatever). We “know” this because there is a story that has been created but not selected for this iteration* which will need this functionality. Lets say that we have done this sort of thing lots of times before, so we “know” that by simply creating an IXable interface and letting our class implement that (or maybe even just returning dummy values for now, the important thing is that the architecture is correct, right?) we will be good for the future. Doing this is violating YAGNI. First of all we do not even know if we need the feature. Implementing it, or at least designing for it now, will take unnecessary time and produce code that might possibly be unnecessary in the end. Next is the question of whether or not this design is the correct one. Based on our experience and what we know now we might be able to say that this design is the correct one. However, if we defer the decision to when we actually need the feature we will know even more and be able to make an even better decision.

So, from my positive point of view, YAGNI is a great guideline that helps me create software that is as simple as possible, but no simpler.

*: ~Again, this is an example of how YAGNI makes more sense for anyone really doing XP, since the fact that there exists a story does not even mean it will ever be selected for implementation.~


Trackbacks are closed.

blog comments powered by Disqus