I can get to that for you in the fall of 2015 - does that work for you?

[This is the second post in a series on being the sole developer in a "normal" (that is, non-software) business.]

The most obvious issue about being the only programmer in a shop is that it inherently limits the size and complexity of projects that can be accomplished. No matter if you're Linus Torvalds, at the end of the day you are still only a single coder (and in my case business analyst, designer, tester and documenter, too). Many potential projects can be recognized as exceeding my limits immediately. Those are the easy ones. Anything that would take longer than a few weeks of effort is basically out of the picture, because my time is scheduled doing so many other things, mostly supporting what already is in production. So to those requests the answer is, "Hire a consulting firm." Which can effectively kill the idea, because that added expense isn't in the budget.

The harder ones are the ones that come in that technically are reasonably doable by a single person. If it looks to be a few hours to a day's worth of effort, I may just try to knock it out and get it done (especially if the request is reasonable, the business value is obvious, and the requester isn't a bozo). But I have been burned by the apparent ease of a request many times.

If it is a few days to a few weeks, then it goes on "the list." For quite a while I resisted keeping "the list" up to date, because I knew what the result would be to look at it all and I get depressed easily enough as is without help. But recently my boss pushed me to bring it up to date. The result? Forty five projects, ranging from a day up to some weeks or a month in length. The worst part? Twelve of those projects are "high priority." And since I've updated "the list" a few more projects have started sniffing around my doorstep, howling to be let in.

I've been told that I can bring in consultants to "help" on a block of them but frankly, because of their (small) size, by the time I documented them out enough to be able to hand them off, I could just do the damned things myself. Which is the paralyzing part. On the one hand, I get push back from management on letting consultants come in to do "fact finding/discovery," because that sounds like a blank check. And on the other hand, anything beyond just thrusting a list of request titles (which is often all I get to start - "We need a system to track whatsits...talk to Fred Blatz for details") at a contractor would require about the same level of effort as just doing the whole thing in the first place.

Because, in general, our needs are simple. It isn't that any of these projects are hard. They're not. Once the requirements are understood, most are quite easy. It is understanding the requirements and capturing them that's the hard part.

So I end up thrashing around, a lot. Because I find it hard to prioritize across twelve "high priority" projects.

"You keep using that word. I do not think it means what you think it means."
- Inigo Montoya

At an earlier point in my career I was quite disdainful of project managers. I couldn't quite see what value they added to an organization.

"What is it you'd say you do here?"
- Bob Slydell

I no longer ask that question. Now I know. A project manager, a real project manager - someone who could sift and sort and force the business to prioritize, would be like working with Santa Claus. Willy Wonka. There'd be sunshine, unicorns, rainbows and candy every day. Or at least decisions, direction and discipline.

My ultimate worry is that at the end of the day my employer will figure out that a lot of what they have as projects aren't really worth automating. If they did an analysis of what it actually costs both up front and in the long term to automate some of what they want, they'd figure out there is no business value, no ROI. That list of 45 would shrivel to five. Maybe. And then? What would they need me for? Oh, I think I'd still have a job - it'd just be keeping the wheels on production day to day. But there wouldn't be much in the way of creating new things, which, let's face it, is the fun part of programming.

Ah, well - I really should go and figure out how I am going to "prioritize across the board" on those twelve "high priority" items before they become thirteen.