Two kinds of YAGNI
Written on 1 May 2008
I seem to be blog-stalking Keith again.
In his post on Creation under Constraints he uses a post from Andrew Binstock to write about the benefits of discipline on creativity. After all, is there anything more constrained than the form of a Rock’n'Roll song? Bartok had a thing about using the Golden Ratio to structure his work. Even in my misspent youth playing free jazz, the good musicians had an identifiable voice that implied form and structure.
Getting back to the point (there is one? ed.), the phrase You Ain’t Gonna Need It (YAGNI) often seems to be applied at the micro level by using primitive types: I’ll just use a String for this address, I can figure out whether I need a type later. Except that, later there are Strings all over the code, only some of which should be Addresses and, by the way, it turns out that I’ve assigned some company names (also String) to address fields by mistake.
String is about implementation, it’s not expressive in the domain of the code. And I’d double that claim for anything that involves templated collections, when there are three or more levels of nested angle brackets it’s time to turn back.
An alternative view, is to say: I need an Address, I’ll declare an empty type and add features as I discover the need. I don’t expect to need a getBytes() method on Address, but I might well need to ask it for its post code.
Over time, I’ve become more and more convinced of the value of declaring types for everything. I don’t observe this practice as much as I think I should, probably for the same reason I have too many fillings.
Incidentally, for a fine example of working under constraints, the Abelson and Sussman videos go for hours before they discover a need for mutable values.
Filed in: Software culture, Test-Driven.
>> it’s not expressive in the domain of the code.
I like this a lot - a really succinct way of describing why so much code is such hard work to understand.
And a strong second for Abelson and Sussman. Teaching programming via functional abstraction now seems prescient…
Steve, I agree with your conclusions and I don’t as much see this particular example as a case of YAGNI. Agile processes don’t free us up from our responsibilities to apply sensible design practices to the problem.
To me, this is a case of applying some domain knowledge and coming up with the conclusion ‘I need an address now’ - so you are going to need it. YAGNI would be applied however if you guessed what methods you needed for you address ahead of time - for example if you don’t need a post code now, don’t add it just in case. I also tend to use objects instead of built in types no matter how small - firstly to aid understanding and secondly to encapsulate any business knowledge where it belongs.
@David. Thanks for your comment.
@Andrew
I suppose I’m (over)reacting to some styles of TDD that I’ve seen — and that I’ve done myself. I think there’s a worst-case combination with some interpretations of DTSTTCPW that leads to code that’s all implementation.
Couldn’t agree more - though, like you, I don’t do this as often as I know I should.
You express intent much more clearly with explicit types, and there are lots of other benefits. For example, you’ll get much better auto-completion of method parameters in your IDE.