Tuesday, December 28, 2010

A (cynical) thought on maintenance vs. new development

I don't know many programmers who care for scut-work maintenance coding, but it does--typically--have one huge upside: Most of the decisions have already been made. Yes, I realize that has creativity-stifling connotations. Yet, to me, it seems to be a touchstone of new, groundbreaking development that everyone wants in on the glamor of designing without the responsibility for making the final call(s). Let's just say that when you find yourself in a meeting time-warp, listening to the same parties having the same arguments to avoid facing the same--now costlier--decisions, you can appreciate a spate of mindless drudgery.

As long as it's a short spate, anyway.

The trick, naturally, is to switch it up--think of it as balancing cardio and weight-lifting, if that helps. Cardio is boring (sometimes even with podcasts) And if you're working in a caste system that consistently has the same crowd on maintenance and the the other clique on shiny new development, it's a a red flag, IMO. Personally, I can only consider it "optimizing" if you're looking to develop dysfunctional habits--in individuals as well as the organization.