Note to developers everywhere: you are not a snowflake, and neither is your project.
Posted on Friday, January 1st, 2010 | Filed under build management, development
Came across this rambling piece of Maven hatred, and it gave me a good chuckle. While the author makes some valid points, his argument is rather clouded by his obvious love affair with Rake and – to a lesser degree – Ant. In a few spots, he’s grossly misinformed, reaching, or just plain wrong. While there are certainly reasons to choose a tool other than Maven for a given project (i.e. any deliverable the format of which Maven doesn’t support out of the box), there is simply no denying that it has its place in the tool box.
What’s more interesting to me than his overtly subjective rant thinly disguised as analysis, is the overarching notion that every project has its own, unique needs. The reality is that in the overwhelming majority of cases, it doesn’t. It. Just. Doesn’t. Just because you can do something in a non-standard way, doesn’t mean there’s a need to, or that the benefit of doing something your way outweighs the cost of not following whatever the convention (tool-enforced or otherwise) is.
The author obviously comes from a consulting background (as alluded to here), and consultants generally have the luxury of only being around their handiwork for a limited amount of time, after which the hot mess of long-term maintenance and support – along with all the skeletons you had to cram in the closet to make your go-live date – become someone else’s problem. As a result, the true cost of implementing a custom, proprietary build process is mostly hidden from its creators. What makes sense initially and for the duration of an implementation track, doesn’t necessarily make sense in the long run, once you factor in the learning curve and the cost of supporting and maintaining your fancy homegrown build process.
Maybe, just maybe, conventional build processes work for conventional deliverables. Maybe, just maybe, the conventional wisdom is actually wisdom. I’ve spent enough time fixing other people’s build processes over the past decade or so to know that, generally speaking, when developers are let of the leash long enough to whip up something ‘custom’, the driving force is generally ‘to do something interesting or cool’ before it is actually solving an actual problem. And while the solution may in and of itself be good, the very fact that it’s different from anything else often becomes its own world of trouble.
What I’ve learned more than anything is that building software – like developing it – is its own discrete art form, and one developers tend to suck at. Not for lack of skill, but for lack of focus, and oftentimes a blatant conflict of interest. There is virtue and value in doing things the ‘conventional’ way, whatever that may be. And for all its faults, Maven lets you hit the ground running. You can’t honestly compare it to Rake/Raven/Ant without considering the cost of building, maintaining and supporting a company-standard toolkit based on any of those three, that gives you the functionality you get from Maven out of the box. It’s entirely likely that there are organizations that have legitimately unique needs and requirements, or that operate on a scale where the benefit of a (relatively) custom tool stack outweighs its cost. I will however argue that you, the reader, are far more likely to not work for one.
Comments
Leave a Reply