Million dollar cutoff for software technique

I listened to a podcast recently interviewing Rob Page from Zope. At one point he talked about having SQL statements in your code vs. having accessor classes, and how as your code gets bigger there’s more need for OO design. No surprise. But then he said something interesting: if your project is smaller than $1M then straight SQL is OK, and over $1M you need accessors.

I don’t know whether I agree with the $1M cutoff, but I agree that there is a cutoff somewhere. I appreciate that Page was willing to take a stab at where the cutoff is. Also, I found it interesting that he measured size by dollars rather than, for example, lines of code. I’d like to see more pundits qualify their recommendations as a function of project budget.

Almost all advice on software engineering is about scaling up: bigger code bases, more users, etc. No one talks about the problem of scaling down. The implicit assumption is that you should concentrate on scaling up because scaling down is easy. I disagree. Over the last few years I’ve managed hundreds of small software projects, and I know that scaling down presents unique challenges. Maybe “scaling down” is the wrong term. My projects have scaled up in a different way: more projects rather than bigger projects.

One challenge of small projects is that they may become large projects; the opposite never happens. Sometimes the transition is so gradual that the project becomes too big for its infrastructure before anyone notices. Having some rule like the $1M cutoff could serve as a prompt for reflection along the way: Hey, now that we’re a $1M project, maybe we should start to refactor now to avoid a complete rewrite down the road.

One thought on “Million dollar cutoff for software technique

  1. I like the theoretical $1M cutoff, though I’d bring it lower because I’m not good at grasping complexity.

    But if you hired 5 good programmers for a year at $100,000 each (or any other equivalent ratio of programmers multiplied by time)* you’d probably need to introduce that degree of abstraction.

    However, the curious thing is that if you spend only 20% less, you’d get a much lower quality programmer, like me, who can’t manage without the abstraction, and would take about 20% longer to get the job done. And if you go 10% lower still, you’d probably have programmers who can’t handle the abstraction.

    *and burn the other $500,000 on overhead and marketing.

Comments are closed.