Hurry up and Stop

One of the most frustrating things about doing third party work is that often you are in a hurry up and stop situation. Clients seem to always be in a rush to get things done. This is to be expected. What confuses me is the same client who is rushing you to get on things seems to continually do things that slow down progress. I am not sure why this is the case, but it probably largely is the result of people still having no clue what programmers actually do and how software development works. Considering how important computers and computing devices such as iPhones and Android phones have become, this really is inexcusable. Here are some of the pet peeves that I have had in the past.

When material is needed before programming can begin, then not getting that material to the programmer is going to delay the project. This is especially true if the required thing is legal documents. Programmers are probably more anxious to start work then you are, but I don't start work until all the legal matters are (or appear to be) settled. Assets that the project depends on are almost as vital. While it is certainly possible to work around missing images or databases, this generally requires more work on the programmers part. First, temp artwork or data has to be created. Second, when the real materials come in, the real assets then have to be integrated and far too often this requires changes to the code due to the fact that often clients don't follow the specs that were sent to them.

Real programming is very mentally taxing. Sure, there are a lot of "programmers" who just assemble other peoples code together, but if you are actually creating code it requires a lot of thought. Having someone wanting to phone you or message you every half-hour is a sure way to kill productivity. When a programmer is in the middle of coding or debugging, any interruption breaks their train of though. This train of thought takes time to recover, so you are costing the project at least 5 or 10 minutes, possibly more, every interruption.

Changes are to be expected, but when a build is sent to you to evaluate, have the courtesy to actually look at the build asap. Waiting months to tell the programmer about a problem is beyond stupid. The longer a bug is in your code, the harder it is to find. Likewise, if you are not actively working on code, it takes longer to get back in the mindset you were in when you wrote that code. And worst of all, adding features to a project when the deadline isn't increased is just asking for a project to enter doomed status.

I could go on, but I think that I've stood on the soap box long enough.