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.

Agile 2007 Roundup

Got back earlier this week. I'll make a short post of my impressions since we're two days from release. The big trend is in adoption in the enterprise. Last year's conference was all about effecting change in a hostile environment or how to build small successes into wider adoption. This year was more experience reports from large corporations taking Agile out of small groups and doing whole organizational change.

SalesForce did a great presentation on how they handled a top down decision to move to agile development. It happened within a three month window. They did wholesale reprogramming of everyone, piecemeal training of project managers as they could, and employed coaches to move it all along. Sounded hectic as all hell, but they moved back from being a once a year (barely) release to quarterly releases, which is what they did was a smaller company.

The other trend I'm seeing is that Ruby is everyone's darling. There was some of this last year, but now it's almost a religion in some sects. I commented to an agile conference friend on how today's Ruby programmers are just recovering Java programmers. It's a nice language, but for my part dynamic languages have more issues than they solve. Didn't we go down this path with Visual Basic and collectively decide we wanted strong data typing more than we wanted flexible variables?

Anyhow, gotta run.

Meeting Critical Mass

My cube-mate put it well when he said this company is establishing a "Meeting Culture". There are some interesting properties to meetings. Kind of like vehicles on a freeway system, a few of them establish a productive flow of goods and services. Also like vehicles on a freeway system, too many of them and the whole system locks up creating cascading failure scenarios.

Take for instance my last two months. Things started out as one to two meetings a week. That was manageable so I could communicate directly with my devs to answer questions, and still communicate with the company at large via meetings to give external exposure to what we are doing. Then add in a couple weekly client calls. Then add in several monthly cross team collaboration meetings. Pretty soon I couldn't talk with my devs directly; they had to schedule meetings for my time. That further restricted my time to get actual work done.

At the height I had no more than 1/2 hour block at any point in the day to do actual work. As any developer will tell you, if all you have is 1/2 hour to code, you might as well not even start.
It takes at least 1-2 hours of uninterrupted time to achieve optimal flow in coding. As a result I've been playing a lot of Desktop Tower Defense. I prefer the 1.2 version of the game.