The Right Way to start and finish a small-scale software project?

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?

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.

Are there any guides on how to write test cases for GUI-focused software? I often find that a lot of my code can't easily be isolated from the GUI, network or asynchronous events. Most literature on test-driven development seems to ignore web applications or GUI code and instead focuses on the obvious.

Alan 2010-08-22 22:45:26

I agree that source control can help a lot (and I know that I should look more into that), but I would like to improve the planning as well. I often find myself coding in more of a "stream of consciousness" style at first and then refactoring and cleaning up the code in between rather than having a blueprint for the entire application and filling in the details. Spending days on user stories, use cases and UML diagrams just seems overkill when you're short on time and your entire dev team consists of you and a rubber duck.

Alan 2010-08-22 22:52:49

Depends a little on what tools you are using:http://www.opensourcetesting.org/functional.php I really struggled with the whole TDD/BDD approach until I dived in head first with some Rails stuff and focused on using Cucumber. Took a while, but once you reach the first "aha" moment it starts to flow. I found the vidoes on www.tekpub.com really helpful, there are some free ones http://tekpub.com/production/concepts also the railscasts series, while rails focused can open your eyes http://railscasts.com/tags/7

Craig McGuff 2010-08-23 00:31:26

I hear you with the "stream of consciousness" approach, I don't think it's necessary to over-document this stuff, but it is always useful to think in advance :)One tactic I have given others where they start worrying about UML, use cases etc. is just write a paragraph in english as a description of your intent, then write to that. It amazes me how often people obsess over the "best practice" stuff when they can't formulate a simple sentence or two - this is probably all that's needed, think of it as an outline for a blog post to put a different spin on it.

Craig McGuff 2010-08-23 00:35:43

@Alan for non-web GUIs you should look at the humble dialog pattern (www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf).

Rudi 2010-08-25 13:47:34

@Craig Though I don't work with Ruby (I'm a Python guy), I think I'll give those videos a try. I'm not sure about the planning method you propose, though -- do you mean I should just try to describe the intended behaviour of the application down (i.e. high-level pseudo-code) without worrying about the formalities?

Alan 2010-08-26 00:38:23

@Rudi thanks for the PDF. As I use MVC architectures for much of my web code, the article seems somewhat relevant. The only front-end code I write is either JS (web) or AS (Flash), so I'm not quite sure how the pattern would work out there; on the server-side I do have problems deciding whether certain logic belongs in the model, template or controller/view (i.e. glue), however, and the article (though written with continuous UIs in mind) seems to suggest that keeping the test-worthier logic out of the templates (whether by adding to the model or creating a wrapper for it) is the way to go.

Alan 2010-08-26 00:54:24

@Alan - it really depends, I took the tone of your post to be that it was really easy to get stuck in the documentation and not actually deliver anything - especially on 1-man type projects.I guess the approach I'm suggesting is really "If it doesn't add value, don't do it"But, I think the proviso to keep in mind is to assume that the next guy maintaining your work is an 800-pound gorilla who knows where you live :)

Craig McGuff 2010-08-26 02:54:59

ansaurus

tags:

views:

answers:

The Right Way to start and finish a small-scale software project?

related questions