3 ms·

a lot of projects are taking a soft process, like legal compliance, and trying to automate it. when you have requirements like < http://c2.com/cgi/wiki?WhyIsPay

a lot of projects are taking a soft process, like legal compliance, and trying to automate it. when you have requirements like < http://c2.com/cgi/wiki?WhyIsPayrollHard http://c2.com/cgi/wiki?WhyIsPayrollHard > perhaps the best factoring of interfaces, the best set of metaphors, aren't obvious, or are shifting. It certainly isn't something you can get right on the first try - if it was, we'd just Waterfall it and call it a day. So, yes, it is precisely a balance between future agility and shipping now - except if you don't ship now, you might not need the future agility ;) me saying this is particularly ironic because i'm the guy pushing scala adoption, clean code, fixing our abstractions, etc. i'm also less valueable to the business over the one-year timeframe that dictates my comp because of it. The only people incented to relenentlessly care about things like technical debt are those with equity.

trjordan 15y ago
Oh, for sure. I'm not advocating getting it right on the first try -- that's crazy talk. I'm mostly thinking about programming in the small: methods, classes, parameter lists, that sort of thing. Essentially complex problems can't (and shouldn't) be solved up front, but that doesn't imply the internals of that partially-solved problem should be disorganized, or that the API is inconsistent. I find that if I explicitly scope my work as I'm doing it, I can write good code to fuzzy specs, without over-generalizing, relatively quickly. Plus, coming back to it a couple months later (well within the typical employee-raise timeframe), I can fix or modify it much faster. It's a balance, to be sure, but I think it's sometimes possible to work both faster and better.