If you are the lone gun, take aim at time bandits

It's 11 A.M. on a Sunday, and I am workingâ€"againâ€"at my computer. The longer than full-time hours come with being the CTO of a three-person startup. I write software, produce papers, meet with venture capital firms, develop company strategy; in fact, I'm pretty much involved in everything. But, as the lone software developer, I have a primary responsibility to produce the software that our company has to deliver. As a result, I have to manage my time effectively to meet software deadlines while still being available for all the other important tasks on my plate.

There are two key ideas that can help you survive in this situation:

• Learn to effectively budget your time. Good time management won't put an end to the seven-day workweek or the 14-hour day, but it will help reduce stress levels, so you can stay productive and sane.
• Find the best tools available. There's nothing worse than being in front of your development environment at midnight at the end of a long day, chasing down an intermittent bug that may be traced to some weird timing problem that only occurs on an old version of Windows 98. And, if you've scheduled a venture capital meeting for the next morning, you'll soon figure out that something has to give. Having a set of tools in place to help you quickly work through these problems is a great way to keep your sanity.

With these ideas in mind, I've compiled a list of rules that help me on a daily basis.

Learn to say no
Even in a three-person environment, it's possible to turn down going to a meeting or a networking event. The point of the other two people being in the company is to work on areas where you can't work full timeâ€"marketing, sales, financial, etc. So that means that you don't have to attend every sales and marketing event, develop the financial plans, or meet with each angel investor. If you say -no" to a few things, you can stay better focused on what's really importantâ€"getting the product out the door and satisfying your customers.

Saying -no" is often very difficult for people in roles similar to mineâ€"there's a natural tendency to want to be involved in everything. Certainly, as a founder of my company, I need to be aware of what's going on, but detailed communication isn't necessary in the preliminary stages. I've learned that it's sufficient to be informed of activity early on and then be more involved later in the cycle.

Get help anywhere you can
When I first started developing the software for my company, our product manager commented that our software would require a significant amount of testing on a number of different platforms. When she asked me, -How are we going to get all of that testing done?" I smiled and told her that she needed to learn about software testing. Even nontechnical individuals can be a great help, particularly in places where you won't be able to spend too much of your time.

Everyone in our company chips in testing the software, reporting to our customers, developing documentation, and scheduling and planning. Basically, I find help anywhere I can.

Keep your installation program running
The development of an installation program is often one of the last things accomplished when building a product. The problem with this approach is that it makes it more difficult to get help testing your software. So one of the first things that I do is create an installation program. This makes packaging each software build easy and facilitates distributing the software for testing. My early installation programs are very simple, but they are designed to get the software into the right spot on the target system and set up the environment for running the program. This strategy significantly reduces the headaches usually involved in updating a set of installation instructions.

Build end-user tools that help you debug
While this general rule applies to all software applications, I find this point to be more critical for smaller organisations. The most painful thing in software development is the conversation that occurs after a system crashes. -What were you doing?" the software developer usually asks. -I'm not sure," says the user. When you lack professional development resources (and you're relying on the -get help where you can" rule), this situation gets even worse. It's important to create tools to avoid these awkward conversations.

I usually build a logger tool into each software system, tracing virtually every functional call and branch in the program. While this creates hefty log files, the price of disk space has become far less expensive than the cost of my sanity. When a system crash occurs, I can usually trace out the problem by walking through the log file.

Another utility I recently incorporated into a Windows application is an exception handler. Since Windows applications don't produce core dumps like UNIX programs do, catching a stack trace is often difficult. With an exception handler, you can get an address of where the program failed and then use a map file to discover which function was the culprit. While this technique isn't perfect, it is still more helpful than asking: -What were you doing?"

Document as you go
Building documentation in-line with the software helps add rigor to your software development methodology. There is a huge tendency to not do good design when you work by yourself. Forcing yourself to document as you go helps you develop better code while not sacrificing dozens of hours on documents that don't often get read. Although I usually don't point to specific tools, I've found Doxygen (www.doxygen.org) to be a tremendous help in my development efforts. Doxygen and tools like it help me document my code without writing separate documents. This, in turn, helps me share the system structure with my colleagues in a way that we can all understand.

Allow extra time when you can
When building my development plans, I usually consider only 75 percent of my time to be available for development. While I can't account for details of the other 25 percent, I know that it is likely that I'll be pulled into meetings and conferences and be away traveling. This technique of building your schedules around what is effectively a three- or four-day workweek will have the effect of giving you the extra time to handle surprises and all of the other necessary company activity. If the worst case comes true and you don't actually need the additional time, then you will have underpromised and overdeliveredâ€"usually not a bad thing.

Learn to fill the gaps in odd places
When your day is packed to the gills with software development and other activities, important things like reading technical journals and books tend to get lost. It's important to not fall behind professionally because your time is maxed out in the workplace. Set aside odd timeslots to fill in the gap. For example, I commute via Metro into Washington, DC every day. That 40-minute ride gives me an opportunity to read a technical or scientific book and keeps me on my game. Books on tape or CD can serve the same purpose. While the strong tendency is to use these gaps to -chill," I believe that it's important to take advantage of these odd slots to improve yourself professionally. I've even discovered that I'm more attuned to working after reading something technical on the way into workâ€"my brain cells are all warmed up by the time I fire up my computer.

Being in a small organisation and playing multiple roles can be one of the most rewarding professional experiences. It's an opportunity to broaden your horizons by learning what it takes to really build a companyâ€"and that is more than just building software. But it's also possible to stay sane even with an insane amount of work. It just requires a bit of effort to learn to work a little more efficiently.