The 10 do's and don'ts of coding (Coldfusion) projects alone

My relation with my work is sometimes a bit of a love/hate-relationship. I love doing large projects on my own, since I can really design a project like I want to and use all my knowledge to the fullest. It's nice taking credit for something big and you just coded in a few days or so.

On the other hand, there is this way of working that makes me really tense, since there is the pressure of making the deadline by yourself and every obstacle that endangers the deadline has to be dealt with quickly and efficiently.

That's why I like to share my list of do's and dont's when you have to code singlehandedly. It's my reference card to make it through a project and come out smiling, happy and richer with knowledge.

1. DON'T lose focus

There is nothing less destructive for a creative journey you're in, than somebody at your desk, a phone ringing, an urgent email that you need to handle... These are breaking facts in keeping your flow going. Every interruption there is, requires you to restart what you were doing and organize your thoughts just the way they were before the interruption happened.

Also there is your mind that at times can wander all over the place. If I'm trying to catch up on blog-posts there is bound to be one or two new ideas or techniques I want to master, which at that time is not the right thing to do.

Unfortunately there is no easy solution to keep focus. What I tend to do is keep one notepad by my side and write all of my action points down to a list: call this person, go and fix this person's bug-report, write down the name of this technique I want to master and visit their website later... etc. This list might become long and add to the tension, but you'll see that most of it takes only half an hour to handle. It's easier to create a long list of chores for the end of the day (say half-an-hour before going home) rather than doing it right then and there, pushing the work in front of you to the background.

2. DO a good assessment of the time needed

If you're new to the web-game it can be hard to figure out how long some bit of functionality is going to take. Even if you have (some) routine in how you code and create projects, it's still hard at times to do a good assessment of what you are going to create.

Most of the time you'll know what you are going to do when you are creating a pricequote. That stage determines for the most part how long you can work at that job at the most. If you create pricequotes like most companies do, you assess the time for a specific part of code, being for example somewhere between 8 and 12 hours. In that case I quote 12 hours, since most of the time the 8 hours aren't met, and you'll end up near the 12 hours.
We hardly create hour-based invoices, most projects have a set price, so we need to be specific and economic. If we work one hour longer on a project, we're working on a loss, if we work one hour less, the boss is happy but the customer overpaid the job... Being exact is what makes it right, and gives you the benefit of competition. Most other web-agencies I'm up against overcharge customers based on a lot of factors.
One of those factors is that they have more people working on one project. Therefore the customer pays for the meetings and debriefings they all have as well. We work directly with the customer at sales-level, so we know what we need and we do not need to debrief anybody, a meeting-report for the boss sometimes, but that's basically it.

Assessing functionality that you can't figure out up-front yet is hard. I tend to think of previous projects that have similarities in the level of complexity and find out how long that took me. That should apply to this project as well, but I'll build in a security margin as well. If you work longer on some functionality, it's an investment for the company you work for. They pay for the extra time you work on this project, but that's invested in knowledge that you probably won't ever lose. You've gained a new level in creating complex code and you'll do the next similar project in 3/4 of the time...

3. DON'T forget to create a planning

The most important thing you can for yourself when working on a project is create a planning. I use Outlook and Excel for my planning, creating blocks of 9-5 activity upfront. My calendar is shared for everyone in-house, so everybody can see when I have time for a meeting, when they best not disturb and what I'm doing (this goes on to do's and don'ts number 4).

I know that working 5 working-days on a row on one project is dangerous. There is more to your daily job than just coding. There are calls, emails, meetings, appointments out of office, etc. that need attention as well. Depending on the number of "interruptions" I have to make, I tend to do the following: I devote 3/5 of a working week to my project, keeping 2 days available for other issues. If eventually I only need half a day for my "other stuff" I can use the extra time to work on the project some more or to organize my work, catch up on the blogs, new techniques, etc. This creates a good balance between project and non-project work and gives a little mind-peace.

So depending on the amount of project- vs. non-project-work you can also devote 4 or 5 days of the working week to your project, keeping the last hour or 2 of a day for the non-project work.

4. DO keep other people informed of what you're doing

Clients keep happy as long as they can see some form of progress and they have the chance to give feedback. I code on public places normally so clients can access a (temporary) URL and view what's going on. I hide pages from the menu that I'm still working on, or only allow them to pages that I choose so they don't mess up their own database.

There is an easy trick you can use in Coldfusion, if your company has a dedicated IP-address like most do. I add this code to unfinished pages which I remove on production.

<cfif cgi.REMOTE_ADDR DOES NOT CONTAIN "80.12.145.156"><cfabort></cfif>

Our clients receive milestone-emails. Those emails show them what has been created during the past day(s) but only if it's something of meaning and that they can visually observe themselves. That way you'll get good feedback while you're still near the code and you can take the new feedback into account. Clients that know what's going on are quite happy and are usually quite understanding when you're up against an impossible deadline.

Next to keeping your clients up to date, it's also a good idea to keep your superiors and account-managers informed. They'll talk to the client also, so they can discuss your status report as well and keep an eye out for things that you've missed out on. Keeping superiors informed is rather important, since they not only control your work but also the people that you have to deal with on a daily basis. If your superior knows you're quite busy they can tell your other co-workers to not hassle you for that all important quick design they need. You can keep focus without having to tell them that you really don't have time.

Talk to your clients in person as well. An e-mail is an easy way of communication, but has a very low treshold and getting a reply with "I don't like what you've created, you need to start over..." is much harder to solve than hearing about it over the phone. E-mail is a technical medium and not a personal one, so some things you might trust to mail don't come out like you've meant. If you're not sure, call the client and then send the mail so they'll know what your intent is.

5. DON'T be afraid to break a deadline

This is quite controversial to me: in school I've learn by heart that the customer is always right, and a deadline is a holy thing that can't be broken. That's true, but it depends on the kind of project that you're up against.

I've had projects where I would have a deadline one day before the client took the project into production on some sort of business event. There is no testing time and the client trusted me that the project would work as should which - considering the specs of the project - was kinda hard.
The project was finished on time, but since there was no testing time left, we decided together with the client to create a presentation where we would highlight the main features of the project. It was a succes and saved everyone from a few glitches that were in there still.

Most of the time your planning and routines will let you keep the deadline. But when it happens that you can't deliver on time notify the client as soon as possible. If you explain that you want to delivery quality and not speed they tend to be very understanding and help you out in meeting the project's needs. Most clients don't make a big fuss if you want to stretch the deadline as long as it is in their best interest. If you can get this message across then you're safe.

6. DO create a routine in the way you do your projects

For every project you start you should have a similar way of working. I usually work like this:

1. Discuss outline with client
2. Assess time and work
3. Produce pricequote
4. Product contract if pricequote is approved, and have it signed
5. Send first invoice for 33% or 50% of the total project sum 
6. Create planning & lists of all that has to be done and known to be able to finish this project. A client has to answer and supply all answers before I will start. This is a security measure preventing the client's wishes to wander all over the place as the project goes.
7. Create basic design, send to client for approval
8. Create technical design starting from the user interface
9. Create database-basics
10. Do 1/3 of all project pages
11. Discuss progress with client
12. Create another 1/3 of all project pages
13. Discuss again with client
14. Finish the project, send to client for evaluation
15. Apply corrections and send approval confirmation to customer
16. After receiving approval, send rest of the invoice

I have routines in how I create my database structure ("name the nouns") and the way primary-keys, relations and indexes are set.

I also have a set of rules for how a directory structure should be, so you don't have 60+ files in your webroot.

A routine gives you structure to hold on to, moving from one step to another and providing an organized way of getting a project from A to Z. You'll sleep better at night with a routine, trust me.

7. DON'T skip on lunch, diner, a coffee break, evenings with family or friends

I seldom work outside of office hours. I need my balance for being able to cope with stress, pressure, etc. That's why I almost never skip a lunch or coffee break or diner with my family.

Your work is important and so is the project, but if you outbalance your day, you'll wind up 40 by the time you're 25. It's just not worth it. If you have to work late at each project, there's something wrong with your own planning, or the deadline set by the client (see DON'T number 5).

If I'm working on a project that stresses me, I need the time away from the project at night to charge my inner batteries. It's not that I don't ever work at night. I do research for the next day, or look at the code I created that day and try to post it on my blog or correct it to be smoother. Rarely will you see me working until late at night, just for my own sake, as well as my family.

8. DO try out new stuff when you're going up against time

Whenever you hear about a new technique that you might be able to integrate into your project, try it. If it's an hour lost, it's an hour learned. When your planning is really strict that's something else, but there is always half an hour somewhere that you can benefit from learning new techniques.

This is important because if you work from project to project like I do, you'll never find time to examine this new technique, like a cool javascript, AJAX, SPRY, jQuery, etc... or whatever new technique you can find you want to try.

Can't find any new techniques out there? Subscribe to a feed-aggregator like www.coldfusionbloggers.org or www.fullasagoog.com and you'll be getting creative vibes in no-time.

9. DON'T forget to document every bit of (complex) code

You're in a hurry now, there's this deadline, there's a massive load of work to be done on your project... We've all been there, right?

Now the project has been closed for 4 months, the site is in production and there is this one CFC that just doesn't produce the results the client wants... But wait, this CFC has 30 methods, and they are referenced from 40 or so pages...?! Damn, what was the difference between "getList" and "getListFields"...

You need to drop the <!--- and the ---> like a second nature when you're coding complex functionality. It's one thing you're as smart as you are and you can read code like Einstein does E=mc2 but if you're 4 months away from the project, and you need to correct some functionality, you can read, read, and re-read your code to get into the spirit of the code once again.

I document my code in-page, but of course it's always good to have an external document lying around, describing your intent. Say if some new employee starts to work on fase II of your brainchild, he or she should be able to get on the same creative wagon you were on, the faster the better.

I hardly ever use SQL triggers and stored procedures (I code away from the DB), but I received an undocumented project once from another CF-coder that was full of them. It took me days, even weeks to document every bit of code and still didn't get 25% of the purpose of some of it. It was a financial disaster gaining anything from that project and the client isn't ready to pay for your time looking into the code-mess somebody else had created.

10. DO what you can to keep your work interesting

Like I said before, keep your eyes open to new techniques, and ways to design the interface, content, stylesheets, javascript, etc. Monitor posts on design, monitor other designs and note what you like and dislike about them. Do a "design-of-the-week" like I do: it will force you to look at a site like a marketeer or a customer, which gives you new creative ideas.

It's your job that you have to do by yourself, if you keep disciplined in organizing your work, you will achieve new levels with each project that comes along. The benefit of coding a project singlehandedly is that you will create your own expertise, that's based on the things you like about the web, and other non-interesting stuff can be discarded more easily.
Each project will have your own stamp on it, and this makes the fulfillment of each project much large than it being coded by a (large) team where you just create small building blocks.