Question

There are lots of texts on how to plan software projects (with user stories, etc), but they usually assume you have a large budget, liberal timeframes and/or a real dev team available. While they sound fantastic, they never seem to account for solo devs working on a short deadline.

There is also a lot of talk about test-based methodologies where you write a test case for every method before you implement it, but I feel that these are difficult to impossible to apply if your software is GUI-focused (e.g. (server-side) web programming or Flash/ActionScript).

Although I try to make heavy use of refactoring to improve my code whenever I have finished a section of it, last minute hacks and additions tend to make this incredibly frustrating and I often feel that there should be a way I can utilise at least some of the planning theory that’s apparently meant to help large dev teams and developers of software libraries first and foremost.

What is The Right Way to go about writing small-ish applications as a solo dev and how do you prevent last minute changes from making your code worse?

Answer 1

There is no “Right Way” unfortunately, however, there are a lot of better ways. I think there is no real distinction between small and large projects – the same kind of things need to happen, it’s just the depth of those things that changes.

In your situation – working to a short deadline, preventing last minute problems – the same old tried and true methods are going to work:

• Use source control effectively, develop last minute changes in a separate branch so you can drop them easily if required.
• Test, test, test. If your tests cover the intent of what you were trying to achieve properly then last-minute changes can be measured.

I suspect you need to look seriously at some different types of testing and tools – there are plenty around that will help you manage these issues.