karlht | A new article: Thinking small (Reply)

This one's a bit of a tangent from the Humanitarian Techie series:

There are things I'm passionate about, and things that I'm good at, and they don't always coincide, but there's a pretty good correlation. I will never be a hotshot software developer -- I think too small. Small languages, small tools, Unix philosophy (see below). But I can solve problems, I can get data from point A to point Z, and I have a nose for bugs. I'm also a strange breed of speaker-to-machines: I have the need for solitude and the deep concentration or 'zone' of higher productivity/enlightenment/touching-the-face-of-the-algorithm, but I lack the disdain for ordinary politeness in everyday affairs. I can be as oblivious as any stereotypical absent-minded professor, but I connect just as deeply with my online friends when we finally meet in the flesh. Too much human contact makes me withdraw, overstimulated and ruffled, but I'm told that I'm a fantastic listener, that I would make a good counsellor or social worker. Love is more important to me than mathematics, but the euphoria of having solved a difficult problem is not to be denied.

It all comes down to thinking small. My mind is not advanced enough to ponder the movements of whole civilizations or whole countries or even whole political movements. I'm not much of an abtract thinker when it comes to human beings. I know my own feelings, and I can hazard a guess at the feelings of those closest to me. And if you put me in a room with one other person with whom I disagree, after a while I can try to put myself in her shoes and understand where she's coming from. But it doesn't generalize well, for me. Just because this person thinks in a particular way does not imply that everyone who lives within a certain distance of her thinks the same way.

Software is the same way for me. The Unix philosphy of 'do one thing, and do it well' appeals to me in a fundamental way. The notions of 'in the end, it's all text in a file' and 'generate your output in a way that's easy to parse' also make a sort of visceral sense to me. The abstraction of 'pipes,' where one program's output becomes another program's input, and so forth, seems to me to be a natural outgrowth of these three tenets taken together.

This is why ambitious projects to 'revolutionize' some computing-related activity always seem to leave me cold. The idea of a 'killer app' is pretty foreign to me, as well. For instance, grassroots non-profits need a freely-available way to keep track of their donors, their clients, their volunteers, and their money. Non-grassroots non-profits don't need these things; they have multi-million dollar budgets with which to buy software and hire technical help. So what's the traditional method for 'delivering enterprise software solutions' to tiny non-profits? There are several:

Buy a shrink-wrapped software package and try to adapt it to your needs, by yourself, with no technical assistance: You may even be able to get a non-profit discount on the software. But this is a sure-fire way to distract you from their primary mission and mire you in detail after detail of how to make the damned machine work. You didn't get into humanitarian work to be a computer technician; otherwise you'd be working at a tech service provider.
Take a flat-fee seminar or community college course on the package, in hopes that it will teach you enough to do #1. This somewhat improves your odds, but only if the package is well-known and the course is well-taught.
Buy a shrink-wrapped software package and then hire a consultant to set it up for you and train you on it: The consultant is then motivated to bleed you dry, and you can't really make any accurate assessments of progress until you're halfway through, at which point firing this consultant and hiring another one is prohibitive.
Buy a 'software and technical assistance package' from a 'technology provider' or TSO ('technology service organization'): This has the advantage that it may get you a deeper discount on the software; TSOs are generally able to aggregate their purchases, and the software vendors will often offer them deep discounts for their PR value (see last article). But since the TSO is also collecting fees for service, some of the same problems with consultants apply.
Open source the wrong way: Download a freely-available package and expect the 'accidental techie' to install it, learn how to use it, and then train everyone else. Don't laugh, this has happened at non-profits I've worked with.
Open source consultants: See #3. Just because a consultant specializes in open source products does not mean that he won't charge you 150% of your budget for the project. All cautions when dealing with consultants apply.
Download an open-source application and then hook up with a socially-minded kid at the local Linux Users' Group: This is actually a better idea than you might think. He may not be the most socially adept volunteer you've ever had, but the experience will look awfully good on his resume. And if you can pay him a little, so much the better. He won't have a family to support, so he's less likely to need full-time work or benefits. Downsides include the need for someone to train your staff in using the machine; training's a tricky skill to pick up.
Pool your resources with other area non-profits and hire a consultant to share (the 'Circuit Rider' approach): This has been used with some success in the past; a major advantage is that it frequently becomes a long-term relationship where the Circuit Rider gets to know your needs very well. The major downside is that Circuit Riders are often very poorly paid, so they have to pack in lots of clients, and so are frequently very pressed for time. Frequently they do have families, but cannot afford health insurance or other benefits. This can lead to budget overruns simply to help keep the Circuit Rider afloat.

All of these methods have advantages and disadvantages. Please comment on this post and tell me if you can think of more.

Next time, I'll see if we can improve on current practice, with emphasis on thinking small.