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.
Related: Agile forecasting