Suboptimal Processes

Many mistakes bring software projects one step further from success, and one step closer to doom. We don’t try too hard to avoid them, because their consequences are often small and hard to foresee.

But they add up.

No nightly build

Ideally we would want to test everything every time we compile something. Or at least, launch that every evening, so the team is quickly warned when anything breaks. Alas, it is of little use when we have…

No automated tests

Or too few of them. To guarantee our software isn’t completely broken, we must perform at least a few tests. Those that require manual work have two effects:

slowing the release process down, which
discourage programmers to set them up in the first place.

The only way out of this mess is to automate those dammed tests. That’s not always easy, for instance with interactive software. This is a poor excuse however for software we build ourselves. Modularity is often all that’s needed to make it automation friendly.

Manual paperwork

Shipping is often not enough. You also have to tell your customer about it. Version numbers, change logs, bills… There’s often a formal process to follow. Failing to automate it again slows the release process down.

One also have to keep track of one’s communication with the customer. Just keeping your e-mail and automatically sorting it in folders often does the trick. Another possibility is doing most communication in the bug tracker, so that everything is neatly sorted issue by issue.

Or you could do both, but then you have to keep your e-mail and your bug tracker in synchrony. Which is especially wastefull when you have to do it manually.

Two bug trackers

This can happen when more than one company makes the software. Now if this is actually two separate pieces of software, this is not that bad, though the customer now uses two trackers instead of one.

Another path is having one tracker being for the customer to view and use, and one more internal one. But then you have to duplicate Bugs reports, and keep them synchrony. Easy if you can automate this. Harder if you keep doing this manually. Spicy if the two bug trackers are totally different.

Manual deployment

In an ideal world, we just have to push a button, and voila, the whole system is installed or patched, or on its way to. Reality is often more messy. We may have to deal with each workstation separately. We may have to install several pieces of software on those workstations. We may have to change user settings. Manually. For each user. On each workstation.

Or we can do our best to automate the installation from the start. Surely, with nightly builds and automated tests already in place, it shouldn’t be too hard to automate most of the deployment. Right?

Slow compilation

This doesn’t seem like much, but slow compilation breaks the flow. We’re tempted to think about other things, to check our e-mail, or whatever. It’s also plain annoying. Now we may not have a choice, but this can also be caused by

Inappropriate programming languages

Programming languages are our most important tools. When not chosen wisely, they put us in a world of pain. They make our programs bigger, slower, more complex, less reliable… Just use the tool for the job. Build it if you have to. And do not overestimate the versatility of your favourite tool. Especially when it’s C++.

Multi combo

You may wonder how much time it takes to experience so much… idiosyncracies. Actually, one project was enough. Still alive and crawling after 3 years though.