Setting up Shop

Accounting and Incorporation

Most of you probably know more about tax laws and finance than I do. I'm hopeless with cash and make no apologies. About all I know about money is that, in my country, most of it vanishes into the government unless you are very careful. One thing I do know, from bitter experience: Don't wait until you are saddles with a $25k tax bill to incorporate. It is simple, cheap to do, and saves a lot of heartache later. Take some advice from an old-timer: Find yourself a corporation lawyer, at least one partner, and incorporate.

Naming your business

While you are at it, you'll be asked to name your new corporation. I implore you, do not do as I did; follow the lead of Marc Ewing or Jeff Bezos and choose a name which has nothing whatsoever to do with either your business or with Linux, GNU or any specific item or service. Corporations (hopefully) live a long, long time and you stand a better chance of brand recognition with a neutral name than with one tied to the wrong industry

Somehow related to all this tax stuff is accounting. The short advice is "Just do it" and even better advice is "Marry someone who will do it for you", which is what I did. Unlike a vendor who has tangible inventory and real flows of boxes in and out of the shop, the consultant must be very careful to document their activities or face the wrath of the tax man. Drive to the mall to pick up a parcel? Log it. Donate time on a local community project? Log it. Track your time, even the time you spend administering your own desktop, and track it as finely as you can; if you hated doing this when you were working for someone else, you will hate it just as much doing it for yourself, but at least you will understand why your employer was so adamant about it.

Linux Accounting Software

Not to sell anything, and by the time you're done here there will probably be alternatives, but for most consultants' needs, open source programs such as the Starnix's BANAL will help you avoid keeping a "ghetto" Windows box just to run accounting software. GNUCash is not there yet, but is one to watch, and if you are not adverse to paying for software, there are several good packages; Proven Choice Dk is cheap, quite usable, and even handles Canadian tax and GST.

Consulting Rates

We all want to work on open source and it sure would be a bonus to be paid for it, but the software engineer is already one of the most exploited occupations. It does no one any good perpetuate this by selling yourself short. Under-cutting other consultants by gross amounts only makes us all look bad, and operating at a loss is not very good for business. Our costs in open source support are significantly less than for our proprietary-bound colleagues. We have no license costs, minimal training fees, significantly lower hardware and infrastructure costs, and, if you are well networked and respected in the Open Source community, you gain hefty labour and knowledge amplification benefits. The exact rates you charge depend on your local market, the industry you serve and your own expenses, and lets face it, your rates will also depend on whether or not you like the work; my best advice is to be reasonable, but be flexible. Factor your experience and your reputation, and price accordingly.

An important consideration is your downtime and in-house costs: If you estimate you can support your family on $40/hr, keep in mind that you will only score a fully paid 40hr week during the peak of a contract; you need to factor in down time, retraining costs (which includes subsidizing your other work on open source projects), the time you spend in research, in systems administration of your shop, and especially your time between contracts. Depending on your industrial sector and your geography, you may see as much as 30% of your time is revenue neutral; with just this consideration, that $40 has jumped to $60.

My only rule of thumb in pricing your services is to avoid fixed price quotes unless you have unequivocal project specifications; even if you do see such specifications, suspect them as being pure fantasy. We point to Linux as the epitome of a large project written in a reactive (rather than pro-active) mode, as something adapted and extended incrementally and only to meet the demands of the next set of engineering problems, but in truth all software is written like this. To think otherwise is wishful thinking backed up by smoke and mirrors. I have been consulting for two decades, and I have seen an exact specification only once (at Mitel Semiconductors). Give estimates, place caps, but avoid hard promises. Push for subscription pricing rather than piece work.

Subscription services are not always possible, especially with government funded projects, Canada Council grants and other fixed-expense advance payments, but even where an ongoing hourly rates is acceptable, it should also not give you carte blanche with your clients' money. Be realistic and be honest. You may think you can do it in X days or weeks, but unless you have been keeping excellent logs and have done the identical task many times, you really don't know. Far better to break your contract into milestones with deliverables, and give checkpoints along the way; the main reason for the mythic requirements specifications and and project schedules is not to know when you are done so much as to know how far you are from completion.

Project Estimates

Of all the components in consulting, the one I find most difficult is cost estimates. For the newcomer, it is practically impossible to consider all the factors, and all too easy to underestimate the costs of simple things like a comma where a colon should go, or a single equals where it should have been double. Project notebooks can provide clues to your own patterns of costs in design, development and maintenance, but in this business, these are most often just that, clues.

All of our work since 1983 has been things never done before, most often never done by anyone, at the very least, never done before by me. Prior project notes are useful for many things, but of limited use in estimating. Sometimes I envy people whose trade allows them to repeat the same hit single over and over. Still, however fluid the technology may be, there are some rules of thumb which are slightly more scientific than Hofstaedter's Law ("It always takes longer than you expect, even if you consider Hofstaedter's Law")

Here's a professional tip for project estimates: I have been using the "Fahrenheit/Celsius Rule" for 19 years and while my clients often don't like the figures, the method has not yet failed me. Take your best estimate. Double it. Take away 10% and add 32. Don't laugh. It works. Trust me.

Seriously, though, as a consultant, it is up to you to explain the reality to your clients. If there is pure research involved, separate it from the estimate and put a star beside it. Be honest and up front. If you can't estimate the time to completion, give some ranges, but mostly just chart out those dates you can deliver; one of those dates can even be the date of the more accurate estimate. Your clients will have finite resources and need to know when cost overruns are no longer worth the expense; since that is the purpose, if you also keep to that purpose, you are both working to the same goal.

Contracts and Boilerplates

The short answer on boilerplate contracts is "Forget it." That said, though, there is no need to reinvent the wheel and considering your contract is your only link to your payment, it's worth while to consider your contracts carefully.

Quality Control

Without a dedicated staff devoted to quality control, an independent consultant is at a disadvantage trying to guarantee industrial-strength quality control. By "Quality Control", I mean the usual quality assurance metrics and procedures that ensure a piece of software does what it was designed to do, and tells where it fails, how it behaves under stress, and all that jazz. This is essential in any serious software engineering.

The first level of QA is the test suite, and this is probably practiced by most if not all software developers. The program has requirement specs, you step through those specs in a controlled sequence of operations and verify that your program does what it was supposed to do.