Sunday, September 24, 2006

Two Software Development Methodologies That Everybody Can Use

There are many different kinds of development methods from waterfall to circular, but in the past few months I have found-out about two which I wasn't taught at school, yet everybody can use. From large development teams to lone developers working on personal projects, both of these methodologies work and are very effective.
  • Test Driven Development
    The core of this methodology is to create an automated test method that will actually give you a green light telling you wither your application works or not. This is very useful when you are writing an application that needs to conform to an input specification or automates a task that is difficult to check by human means. Large teams can use software on their build server to run use-cases against their codebase that provides feedback, but lone developers can use test driven development just as effectively.

    As an easy exsample, when I wrote my table compression algorithms for my Compilers Class I needed to know wither the data stored in the compressed table matched what was inputed from the source table. Obviously if the data retreived from my compressed table did not match the source table then there was something wrong with my algorithems. I tried checking by using my own eyes, but I was dealing with tables 1024x1024 in size so I soon rearlised that I needed to automate the task.

    I created a button on my form called 'Test'. This button called a method which in turn methodecally called every cell in both the compressed and uncompressed tables and looked to see wither what was returned from both matched. Obviously there was nothing wrong with the sorce table so any mismatches where the result of a bug in one of my algorithems. Thought creating this I was forced to spend an extra two weeks trying to get all the bugs out, but that is because I could find bugs quickly simply by the press of a button (I also had t create a lot of different test data, but that is a another talk).

    When I wrote my last Tic Tac Toe game I also added a test button which took the place of a player and played random moves against my AI for 100,000 games a time. Because of this I know that my AI is unbeatable.

    The trick is to have your test method provide useful feedback. In the case of my Tic Tac Toe game when the test method which is making random moves wins against my AI, the test method will append every move made in that game to a text file so I can easily replicate the game and see where the AI made a mistake.

  • Burn Down Graphs
    In order to create a burn down graph you must first create a list of features that you want to include in yourr application. This should include all necessary and desirable features. Then each feature should be broken down into tasks and a time alloted to each task. This will give you a list of features, how long it will take to implement each one and indeed the entire application.

    With a burn down graph you don't need to choose how long you want to work on your application each day like with a gant cheart, but it is important to update the graph regularly otherwise it won't track progress. Update the graph daily, weekly or however often you feel is appropriate. This will form the time scale that runs along the bottom of the graph.

    Image Hosted by

    So along the bottom of the Burn Down Graph you have a time sale running from when the project was started to your desired deadline. And up the left side you have hours until completion. As features are completed, added or removed the graph will reflect how many hours you have left to work on your application against your progression to your deadline. And over time you will see a nice line appear that will give a very good indication as to wither you need to put more hours in to complete the project on time, move the deadline or cut features to meet the deadline.

    In the picture above you see a nice smooth line, but real burn down graphs aren't like that. There will probably be a few occasions when the time needed to complete the project will increase as difficulties are encountered, that is ok because the graph will always communicates clearly where you are, where your deadline is and by looking at the line you can clearly judge wither you will meet your deadline or not by the work you have been doing.
So there you have it, two methodologies that even a lone developer making an application for themselves can find useful.