Tuesday, May 19, 2009

Working Off-Site: Practices for the Indie Software Developer

Being an indie software developer isn't easy; getting and keeping clients, managing payment and collections, doing the books, complex taxes, ensuring you have software licenses and top-end gear, setting up a home office properly, and keeping up-to-date on the latest technologies, finding and managing benefits like health care and a 401k, all without a manager telling you to get it done, isn't for everybody. It's hard work. 

For me, there's no doubt. Like an actor, writer, or musician, I'm all about the project and my role. I perceive myself as "talent", and like to be in direct control of what I work on, when I work on it, and how much I earn for doing it. For the first 10 years of my career in technology, I worked in strategic planning and R&D at American Express, and as a technology specialist (essentially a field technologist, building prototypes and comparative demonstrations) for Microsoft. I won't get into a lot of detail as to why I decided to leave and go it on my own; suffice to say that I prefer the freedom to pursue work that interests me every day, and I like to keep my focus very specialized. 

One you actually pull the trigger on self-employment though, you find a lot of the romance of "being your own boss" dries right up. It's scary, and you find yourself working harder than ever; keeping your books straight, or learning a new programming language, is time consuming work, but nobody is going to pay you for it. Working from home is a discipline as well; it's so easy to "take a break", and watch some TV, play a little guitar...and kill the whole day. "Oh, I'll make up the time, pull an all nighter," and all that. Sure, maybe once in a while, but if you do it all the time, you won't be able to sustain it and your work will suffer. 

With all that said, here are some of the more valuable tips I've compiled from my five years as an indie software developer. 

- Don't jump in suddenly. Doing it right costs money and will take time to get up and running, you have to be prepared for some lean times. If you don't have any money in the bank or are just having trouble finding a job, you're better off spending your time at networking events and job fairs, and finding training to get your skills together. Collect unemployment and beat the street, there's no shame in that if you're really working it, and employers will recognize the effort. 

- Take a business class, get a couple of books on starting and running a small business. I dreaded this, but did it, and have to say it was one of the most valuable bits of training I've ever had. In particular, I picked up a book "How to be a Successful Freelancer", and found it invaluable. Aside from the obvious "keep your books straight" sort of stuff, I got a template for a freelance contract, advice on the kind of clients I should pursue, how to set a rate confidently, some basic negotiation strategies, and an understanding of how important documenting the entire process of approach, negotiation, contract, work status, and closing out, is. 

- Set up a business checking account, register your business name under a DBA ("doing business as"), and use something like Harvest (google it) or Quicken, to track money coming into that account. I use Harvest and can tell you exactly how many hours I've worked, how much I've made, and how much I've got coming in, at any time. 

- Create a workflow for working with a client; set up a process, make sure you have templates of your contract ready, have your resources (development server and testing environment, etc.) all up and running. Let your client know in advance how you typically set up and work on a project. This isn't to say that you should be like, "this is how I work and this is how you're going to work with me," but more like "typically, after we get through exchanging NDA and work agreement, I'll set up the space on my testing server and give you access so you can monitor the in-progress product whenever you like...I provide daily status updates at the end of each day, I'd appreciate if you could review them periodically to make sure I'm on the right track...I can be contacted at this AIM account, or on Skype, or by phone, during normal business hours, but feel free to leave me messages at any time...", that sort of thing. 

- I can't believe how many indie developers don't have this set up, so I'll put it in caps...HAVE A WEBSITE AND A DEDICATED, REGULARLY BACKED UP, SUPPORTED, DEVELOPMENT SERVER. PAY FOR IT. If you're indie and want to beat out the organized dev shops for a contract, you have to be GOOD. If you don't have your own tools, like a basic website with links to samples of your work and your resume/contact info, and a server to show in-progress work or experiments you're tooling with, you're not going to convince anybody you're really into what you do. More than likely, this sort of developer is just one that can't find a job, and is trying to freelance a little until they find one...which means they'll drop your project the second they do. 

- It's hard to believe I have to say this, but from what I've seen, it's necessary; don't steal to do your job, don't depend on others to provide you with your tools. Invest in a good laptop and the software you need. Pirating your software isn't cool, it doesn't make you look smarter or hipper. If you'll steal the software from the manufacturer because of some Robin Hood rationale, sooner or later, you'll probably steal from me. Spending a couple thousand dollars for the tools you plan on making a living with, which you get to write off anyway, isn't unreasonable at all. 

- Provide your clients with FTP and SVN. I run both on my server, and give access to my clients for free for the duration of the project; I know of no other solo indie developer that does this, and I can't imagine why not, particularly since, aside from the server, it's all free. If the client has these resources set up and wants me to use theirs, great. But even if that's the case, saying I have it and can provide it--and many clients take advantage of it even if they do have it already--makes me look more pro. 

- Work regular hours as much as possible. There's this whole "I work while you sleep" thing. It's unhealthy. I don't want to know I can contact a developer at 2 a.m., I want to know that I can contact them at from 9-5, and that they'll be awake and lucid. Saying you weren't available for a conversation at 11 a.m. because you were up 'til 6 a.m. isn't good, and email timestamps at 3 a.m. with some garbled message are worse. People that work regular schedules at standard business hours generally do better work, because they don't work past the point of diminishing returns. I used to do all that; I don't anymore, I don't walk around burnt out with headaches from too much coffee and lack of sleep anymore, and my client list is stronger than ever. 

- Don't work in your bedroom if you can help it. It's really important to unplug when you're done for the day, and keeping your workstation in the same place you sleep makes it almost impossible. Set up a desk in your living room if you have to. 

- Offer to be available for onsite, schedule meetings. I generally don't work onsite because I invest heavily in tools and space to maximize my productivity. If a company insists on full-time onsite, I'm a lot more expensive, primarily because I want to deter it, but also because I have no intention of providing the services of a full-time employee that gets no benefits. However, if there are developer meetings once or twice a week and it's possible to be there physically, ask if you can go. If they say yes, GO AND DON'T BE LATE. If you can't physically go, ask for a conference number. You're indie, but for the duration of the project, it's important to be perceived as accessible by, and interested in, the rest of project team. 

- Don't go dark; from 9-5, fire up Skype, whatever IM the client uses, have your phone on and your email up, and respond immediately, even if just to say "I've reviewed the data, give me some time to respond". This is critical; I'm asking a client to trust me off site. If I stay visible and responsive all day every day, I  build the client's confidence tremendously. Again, it's funny how many indie developers will just go dark for a few days, thinking they understand what they need to do and don't need to communicate. 

- Send status every day when you wrap up, and post your work to your dev/testing server for review. State what work you've done, and any issues holding you up. If you don't get a response for a day or two, send an email asking if the client has been reading them, and if not, if they can get on a half hour call to review. It's extremely important to get daily feedback, even if they say "got your update, will review later". If the client goes dark, inform them that you're going to stop work until they respond. Don't give a client the opportunity to say "I looked over your work for the past two weeks today and have numerous issues, we're not satisfied." You'll end up doing work for free. 

- Don't work without a signed work order of some kind. The client MUST sign a document saying that you are getting paid X rate for Y work, and may end the relationship at any time, at which time all unpaid work comes due, and that the client (which could be the subcontractor) is directly responsible for this payment. It is NOT in your interest to let a client talk you out of this, you're better off without the work. If the actual client refuses to pay the organization that subcontracts you, that's not my problem. If they say "tough", get a debt collector on them and make no bones about the fact you'll spread the word. I have had to do this twice, and both times they paid up and even offered me more work, which of course I declined. Only once has a client actually not paid me, but that was early on, I know now that I compromised too much and should never have taken the client. 

- State, as part of that work order, that you are getting paid for time and service, not for a finished product. More than once I've seen a project go bad because another developer screws it up or vanishes, or the actual client (i.e. if you're being subcontracted) terminates the project. I hate when that happens, but ok, you still got my time, and I want to get paid for it. 

- Don't do flat rates; if you do, take your estimate, double it, and add 15%. Tell the client if you finish sooner you'll pro rate it, but that the budget must cover your initial figure. I've never, ever gotten involved in a project at a flat-rate that turned out to be really worth it, because clients add features and change requirements far too often to make the initial estimate valid, and argue when you say you need more money  because it's not the same project anymore. If you go by the hour, or a day rate (I even offer a monthly, with the contracted stipulation that if you book me for a month at my monthly rate, I am guaranteed the month's wage), you don't have this problem. Clients will frequently understate the complexity of a project to get a low bid, because they need to keep their budget down, often because they underbid a project themselves and are trying to find cheaper development to make the ends meet.

- Again, unplug at the end of the work day. Stop working. It's important. I go from 7 a.m. to 5:30 p.m. That's a long day, and my returns diminish after that. Go to the gym, take a bike ride, get some dinner, play your guitar, whatever. Get a good night's sleep and wake up refreshed. You'll do more consistent, higher quality work. Many don't believe it or think it's not "hardcore" or whatever; rarely do I say this as an absolute, but if you're one of them, you're wrong. 

That's about it for now; there's more, but those are the ones that are top-of-mind for me. But it's time to get down to business on my day project so I can knock off at 5:30 p.m, hit the gym, get a couple of songs down for band practice Thursday, and get a good night's sleep. Practice what you preach. 

As always, thanks for visiting. 

No comments:

Post a Comment