How much process do you follow on your own projects?

Question

Do you follow a process at all? If so, which ones? If not, how do you manage the development cycle?

Answer 1

I tend to do the abbreviated "Hack -> Ship" process (with a good scm of course)

(this is for smaller personal projects)

Answer 2

Well, I think I'm the only 1 around where I work doing this, but this is the steps I follow:

1. Feasibility/3rd Party check. Is this project reasonable to complete with the resources we have here. Writing an ERP program from the ground up is not feasible. Additionally, is there a 3rd party product that could meet specific needs and be cheaper than developing it in house. 3rd party apps always seem to be a hot topic, but they are supported in my shop.

2. Requirements. Lots of talks with the client to determine what the app must do and how it must do it. I document is written and signed off on so that we have a mutual agreement and it can help curb scope creep since any major changes require a new signoff.

3. Design. Based on what we have in the requirements, a design/architecture document is written up to layout how the application will be done with the technology we have. Sometimes we can use this to help infuse some new technology in (like AJAX or MVC) but ideally this document could be passed on to a different developer and they could write it with minimal intervention from me.

4. Database design/coding. I'm one that likes to view things from the data on up, so I'll generate my tables and stored procedures based on the design document.

5. UI coding. This also includes the business layer logic for the application. I try to go 3 tier (DAL, BLL, UI) for the web apps we have here.

6. Internal testing.

7. Client testing.

8. Migration to production.

Steps 1-3 are often the hardest to muck through, as I always want to write code right away, but it helps in the later stages with the project. Again, sadly there's nothing enforced around here to do these things (especially 1-3), but hopefully I can get some of the newcomers we have on the deck to start following it.

Answer 3

I'll chime in for a personal project, not work related. The project is a small game, taking the spaceship board game from an old 80's RPG (Star Frontiers) and making a program to handle the mechanics. For this pet project I do the following:

1) Requirements - This was pretty easy as it just has to reproduce the game rules (about 20 pages of printed text with illustrations)

2) Rough design - I've done really rough - pencil and paper - mock-ups of the interface I want and many of the dialogs to be used

3) Technology selection - I'm mainly a Linux guy but many of the fans out there interested in the game are Windows only users so I chose wxWidgets as my GUI tool kit for it's cross platform support.

4) Source Control - I have a CVS repository I use to store all the source code and images. Check-ins are done whenever I complete the functionality set I'm working on. Sometimes this occurs daily (if I'm lucky enough to have that much time to work on things) but typically once a week or so. I always check in code that compiles.

5) Testing - Something I'm trying to be better at. Right now I've neglected unit tests and the like and have just been doing manual testing of the program to verify that it does what I think it should be doing.

6) Porting - I do all my development an initial testing on Linux. Once I have a version ready to go out, I switch over to Windows, check out the code, fire up Visual Studio, build the program and test it out to make sure that all the new (and old) features are working properly in the other OS.

7) Releases - I done a few small releases of working versions of the code with limited functionality to get other eyes on the code for usability and functionality suggestions.

8) ToDo List - I maintain a list of all the features and bug fixes that need to still go into the program as they come to mind or people point them out to me. This helps give a bit of focus and remind me what I'm working on, especially when I haven't been able to work on it for a while.

Answer 4

I work in a research lab with no management-mandated development process. The processes you'll find are all ones we developers introduced that proved themselves useful.

A release or two back, we introduced a formal "release checklist" with lists of demonstrations and tests we run before and after release builds. It's proved its worth, so it will stick around.

Source control is obvious. Our project is old enough to have started on RCS. Six years back we migrated to CVS. Finally, a few months ago, we migrated over to SVN. Being able to rename and move files and directories without destroying history information is beautiful.

Bug tracking is done with Bugzilla. Primitive, ugly, but quite usable.

Automated testing has slid in over time too. Originally, the other developers put up the classic "I don't have time to unit test" excuse. On my own time, I put in a CppUnit-based framework in our build tree. My tests started catching other people's bugs and noticeably improving code-quality; that got the rest of the team on board. Now we're introducing automatic validation testing too. (Roughly equivalent to integration testing, but comparing our software's output against real world experiments).

There is no strict coding standard in place. We each have our own styles. If we modify somebody else's code, we do the changes in their style. This has worked reasonably well for us... nobody has been burnt at the stake yet.

There is little in the way of formal requirements. Our lab has contracts stating deliverables. We programmers communicate directly with the sponsors to make sure we meet their needs within the funds allocated on the contract. This too has worked out pretty well overall.

Finally, setting up an internal-only MediaWiki has proved very valuable. It's been used as a collaborative design/planning tool, a documentation system, and a task/project tracking device.