Opportunistic Programming

As a developer, I’ve been frustrated at times when I felt that a product owner or manager was forcing me to spend an inordinate amount of time on a “pet feature” of theirs while glaring deficiencies elsewhere went unaddressed.

And to be fair, product owners and managers surely get frustrated at developers who spend too much time chasing some technical purity that no customer will care about instead of shipping.

I touched on this in a previous post—the importance of developer morale to the health of a project, and how it’s unwise for management to dictate the development team’s priorities all the time without considering their preferences and input.

Salvatore Sanfilippo (creator of Redis) introduced the term opportunistic programming:

There is a way to stress simplicity that I like to call “opportunistic programming”. Basically at every development step, the set of features to implement is chosen in order to have the maximum impact on the user base of the program, with the minimum requirement of efforts.

This really gets to the heart of my malaise when I’m being pushed to spend considerable time and effort on some aspect of a project when my intuition tells me it won’t pay off, and no one can adequately explain otherwise.

Salvatore goes on:

Often complexity is generated when there is no willingness to recognize that a non fundamental goal of a project is accounting for a very large amount of design complexity, or is making another more important goal very hard to reach, because there is a design tension among a fundamental feature and a non fundamental one. It is very important for a designer to recognize all the parts of a design that are not easy wins, that is, there is no proportionality between the effort and the advantages.

Let’s be real: code sucks, and adding more of it without a good reason is bad news.