YAGNI's been naggin' me
At the Agile conference I had the pleasure to run into a friend from last year's conference. We were bemoaning some the challenges of development and one of the topics was the interpretation of YAGNI (you ain't gonna need it) by one of his jr. developers. The developer was ruthless about deleting methods that were not actively used. Meanwhile, he and I, who have been doing this for over a decade each, were talking about how sometimes you need to leave unused code in place.
Mulling it over, I think I have an answer for all the YAGNI bigots out there that may make sense. In general I agree with the principle of deleting unused code and rewriting it if you need it later. Specifically, tho, there are areas where you want to leave it. Consider LEAD Tools. Suppose you somehow licensed the source code and were building an image processor. You look at your product and say "We're never going to use scalable vector graphics in our raster imager." So you go and delete all that code from the library. Did you gain anything? A little code size. But now if you want to add in a small vector method instead of just making the library call you have to dig up the original source, reinstate it, etc, etc, etc.
"But LEAD is a third party library" you say, not under our control. EXACTLY! In a properly stacked N-tier app you should be able to treat any layer as a separate library (within reason). The specific one is the ORM layer (domain objects, model, whatever). Suppose you have a portion of the product that is read-only data, so all the insert/update methods are yanked out. Next version we decide to add customization of these records. This just happened to us. Instead of it being a two day job it became a two week job. Why? Because someone thought "We don't need that common method implemented for this version" and removed it.
My point is this: Embrace YAGNI. Tighten up your code. Clean up your convoluted business logic. But also recognize parts of your app that have a library-like quality and treat them as such.
Mulling it over, I think I have an answer for all the YAGNI bigots out there that may make sense. In general I agree with the principle of deleting unused code and rewriting it if you need it later. Specifically, tho, there are areas where you want to leave it. Consider LEAD Tools. Suppose you somehow licensed the source code and were building an image processor. You look at your product and say "We're never going to use scalable vector graphics in our raster imager." So you go and delete all that code from the library. Did you gain anything? A little code size. But now if you want to add in a small vector method instead of just making the library call you have to dig up the original source, reinstate it, etc, etc, etc.
"But LEAD is a third party library" you say, not under our control. EXACTLY! In a properly stacked N-tier app you should be able to treat any layer as a separate library (within reason). The specific one is the ORM layer (domain objects, model, whatever). Suppose you have a portion of the product that is read-only data, so all the insert/update methods are yanked out. Next version we decide to add customization of these records. This just happened to us. Instead of it being a two day job it became a two week job. Why? Because someone thought "We don't need that common method implemented for this version" and removed it.
My point is this: Embrace YAGNI. Tighten up your code. Clean up your convoluted business logic. But also recognize parts of your app that have a library-like quality and treat them as such.
posted by nitpickable at
1:54 PM
0 Comments:
Post a Comment
<< Home