The Rules

I missed an interesting discussion today (my fault, I had work to do), but the subject merits a post.

The gist is that with all the advice on SOLID principles, TDD, BDD, enough "seminal works" on coding style to fill up a small library and whatever house rules an individual company or team adds on top of that... are software developers drowning in guidelines?

Specifically, are they drowning in guidelines that are mostly about the small picture, day-to-day stuff?

I've talked before about how most of us end up working on relatively simple CRUD applications, and collectively we need to learn to put on our pixellated sunglasses and deal with it. Given the frequency with which I find applications featuring five tiers, a teetering pile of IoC scaffolding and 10,000 lines of BDD pipework to post a value to a REST API and display the response to a user, I suspect I'll be talking about it for many years to come.

So with this in mind, stuff is simple, and the rules ought to be similarly simple. What it comes down to, when you eschew all the detail and figure out what you're trying to do at an abstract level, is this:

1. It works. Always.
2. Anyone can maintain it.

That second one is important. It's not just, "you can maintain it, because you know where everything is and evidently you don't mind being called mid-holiday for some unpaid overtime". It means that any random programmer from your organisation can open up the project, grok the idioms, and figure out what it's doing within the space of a few minutes. This covers everything from readability, simplicity and clear segregation of responsibilities up to not deciding to write a Ruby on Rails app in the middle of a Java shop just because you happen to like Ruby. Oh, and maybe some tests so said maintainer has some comfort they're not about to break the world with a seemingly innocuous bugfix.

So if such a rule does indeed cover everything, then what's the point of it? Well, because it's at an abstract enough level you have to think about what you're doing. If I write methods that are seven lines or fewer because I have a checklist on my wall that says methods must be short, I'm not really thinking about maintainability. Every so often I'll actively make things worse by splitting up a coherent piece of code that just happened to be one line too long, or playing code golf to fit everything within my line budget. But if I'm looking at my code and thinking, "would I enjoy diving into this monstrous function six months down the line?" then I'm making a rational decision.

Taking another industry as an example, Bob Lutz talks about this mindset in Car Guys vs Bean Counters - that General Motors spent the '80s and '90s putting out lacklustre car after lacklustre car because everybody involved in product development was working to a checklist of, "things that make a good car within a budget" and never thinking, "would I spend my own money on this vehicle?" This is the same path the supposedly established rules of development are taking us down - we're ticking every single box on the "things that make good code" list while shipping bloated, slow behemoths that nobody in their right mind would want to work on afterwards. "Would I want to maintain this?" Well, would you?