Investing and Personal Finance

This continues last week’s post on Working With Computer Nerds (if you haven’t already, read part 1 first – it has cartoons!).

Unknowables

With computer work there’s almost always big unknowns.

Whereas most people learn their jobs, get good at them and do the same thing over and over (I want a lawyer who has seen hundreds of contracts just like the one she’s preparing for me), computer work is different.  Software can be copied so inexpensively it’s basically free.  This makes it redundant to do something that has already been done.  For legal reasons, this happens (I can’t get Google to send me the software that runs their servers or Microsoft to send me the source code for Windows XP, so if I want to make software LIKE theirs, I have to write it again from scratch).  For many thing however, copies are available FAR less expensively than it would cost to build a new version.  Computer nerds are almost always working on new things, because if they already had software to solve a specific problem, they’d just copy it (or buy it then copy it) and be finished.  Often computer people also dive into projects that involve technologies that are new to them and part of the project is learning something totally new, then using it to do the work (which is also new to them) they were hired to do.  This causes most of work that we actually do to be new, and therefore will usually be far more challenging than most people’s work (which is why we like it). Yes, this can be as frightening as it sounds.  I came to realize that a moment of blind, absolute panic was required in most contracts I worked (“Oh my god!  I’m not going to figure this out, I’ll miss the deadline and the client is going to shoot me dead!”).

An example of this, I did a 6-week contract at a publishing company (I’d never worked for that company or in that industry), building a content management system (which I’d never done), using Django (a framework I’d never used before), based on python (a programming language I’d never used) using PostgreSQL (a database I’d never used before).  As near as I can tell from their website, the system I put in place is still chugging away fine for them (and they were happy enough with my work that they wanted to extend the contract after I was finished).

The big reason for avoiding the two problems in last week’s post is that there’s enough uncertainty in software development, so remove any extra uncertainty that you can.  When someone does computer work, part of what they’re offering is insurance that they’ll deal with the expected unexpecteds – they should be allowed to do what they can to contain the amount of risk they’re being asked to insure.

This all being said, it’s not outside the realm of possibility (it’s actually fairly likely) that once the nerd digs deep enough into the problem they’ll find that something that was originally planned for that won’t do what it was expected to (some part of the system is missing a feature or there’s some incompatibility).  Usually when a computer nerd comes to you with this, they’ll also have 2 or 3 alternatives to offer.  Hear them out and take one of the alternatives.  You may be within your rights to insist what was originally discussed be delivered (especially if a couple extensions you wanted were turned down as “feature creep”), but it’s going to poison the working relationship if you can’t at least give a good reason why you need the exact original (sometime substitutions are necessary).  It may also be possible at this point to strong-arm a discount, but this is the opportunity to be the cool client who will get top priority in the future or be the difficult client who gets dropped as soon as business is good enough.

Imprecise Deadlines

Because of the above mentioned uncertainty, computer projects ofter take longer than expected.  It’s probably reasonable to hold firm on the money element of a deal (although many a junior nerd has driven themselves below minimum wage levels by poor estimates), but it’s worthwhile to give a project a bit of wriggle room, and let the computer nerd deliver a bit late if they run into problems.  I’d recommend padding the schedule by 10 or 20% and if they come and start seriously talking about a schedule slip, you’ll be a hero when you give them a bit of extra time.

Vendor Lock In

One of the things some technology vendors (and some computer nerds) do that drive me NUTS is vendor lock in.  They do work for a client, doing a good job at a reasonable price.  They’re hired back and start a good business relationship.  One day the client realizes that the price has been steadily increasing, the delivered value has been steadily decreasing, but they’re now reliant on the vendor for core technical needs (systems have been set up such that the the vendor is the only one who can modify them) and are being held hostage.  I would often stress to customers that I won’t do this, and would leave their systems in a well-documented state such that someone else could take over for me when and if this was needed.  Customers never seemed to care about this, but I’ve heard enough horror stories of companies getting shaken down for thousands of dollars for trivial changes that I can’t believe this isn’t a bigger concern for people.

To avoid this, present your concern to the computer worker as “what will we do if you get run over by a bus?” or, if it’s a bigger development company, “what will we do if you go bankrupt?”  Don’t be deflected by them laughing this off.  Get them to document everything, and occasionally hire ANOTHER computer nerd to have a look at what’s in place and see if they could take over if needed.  Both of these will increase the cost of a project, but in my opinion, is some of the best money you can spend on risk management.

For software that is at the core of a business, I think it needs to be developed in-house (hire an employee).  Giving an outside developer this much control over your entire company is reckless.

For computer nerds and people who have worked with nerds, what advice would you have for the best ways to works productively together?

{ 5 comments }