I hereby decree

by David LeMieux


I have been thinking a lot lately about how to balance short term gains against long term gains when it comes to software development. I suspect I am not the first but what I struggle with is that much of what can be accomplished in the short term is not suitable for long term growth. Focusing too much on the long term can mean you miss short term opportunities and the feedback loop takes too long. You don't want to spend too much time on something that isn't going to help you or anyone else.

I do think the balance lies somewhere in that 1) It is important to understand the problem that needs to be solved in contrast to providing implementations details to any apparent problem without understanding it. 2) Setting up a good foundation, while not bullet proof, will get you a long way toward extensibility and being able to make quick wins later on. 3) Taking a tick-tock approach to short and long term goals (stability vs features, for example) allows teams to achieve both, but at the possible risk of extra context switching and thrashing.

While I am generally a fan of something akin to "agile development" I think that the idea of an Minimum Viable Product (MVP) can sometimes be detrimental if it becomes synonymous with ignoring quality along with features. In my opinion we'd all be able to make the most rock solid set of one or two features needed for a product instead of three or four buggy features.

I am also a firm believer in living within constraints. It isn't always easy and can even be humbling (saying no to a client because your product is lacking something the want can be hard to do) it can also be a catalyst for change while helping to keep things coherent in the mean time. Short term gains should follow patterns and be built on a solid foundation. Long term gains should be the rebuilding or shoring up of that foundation.


blog comments powered by Disqus