karniv0re's Journal: Things Learned From the Scheduler Project

The report scheduler project I have been working on for the last 6 months has taught me a LOT about the software engineering process.

1. Gather concrete requirements at the beginning and stick to them. Give customers solid, realistic dates for each one. This way, if a requirement changes, the added time in refactoring code is their fault and they have to suffer for it, not you.
2. Test Driven Development. This is my new mantra. Test All The Fuckin' Time. TATFT. LIVE BY IT. Design your product. Write your tests. Write your product in small increments, making individual pieces work and work well. The sum of these well-oiled parts will become (typically) a well-oiled whole - as opposed to you getting fucked in your not-so-well oiled hole. Sorry, was that too much? IT'S TRUE! TDD! TATFT!
3. Task Lists. If you have trouble staying on task (like I do), task lists with hard deadlines on them could help. It can also keep you organized and lets you prioritize your tasks, which can make a huge difference in what gets done and when. Plus, it's nice to see all the stuff you've checked off as a measure of progress.

This is just a small list of things I wish I had done. Overall, my code was done very well, but the lack of testing really hurt the process. I used a lot of cool encapsulation techniques, such as an MVC architecture in ColdFusion, and kept all the pieces in their place. Database writes are done in one place and one place only (Model), the ugly JavaScript glue is kept in one place (View), and the Ajax calls are made to and handled by a middle party (Controller). And I have it email me on errors so I know what's going on at all times.

The good news is, my list of "wish-I-had-dones" is getting smaller, so I'm learning from old mistakes. I just need to apply more to the software engineering side of things and take it more seriously. Especially when it comes to dealing with customers.

Documentation first

[tqft]

One project which I worked on worked really well - the user documentation was done before to some extent the backend coding was finished. The project also had serious backing from senior management.

I was writing the doco and testing.

What should it do? What use cases? What will people do with it? All these questions are in the user doco.

Almost every other IT project I have been involved with has not had user documentation produced other than seemingly random screen dumps and a promise of RSN - and they mos