BitwiseOR

You know what I find fun? Coding.

Not planning to code, not testing by hand, but pure coding from scratch and then untangling the mess I made by debugging it. That’s why I don’t care for certain methodologies. The Waterfall method specifically.

Don’t get me wrong; when done correctly coding models work beautifully. In fact, it was the Waterfall model that I just used recently on a small program that worked so well to show me how much I despise.

First, we start with the requirements. Make a list of the major requirements in the project, now break those down into manageable pieces, break those down into finer details, keep breaking down each item in the list until you have one specific requirement for each bullet point. Now your list is 30 pages long and 15 levels deep.

Now that we have a list of requirements, “design” your program. Don’t code it; “design” it in psuedocode.

Next, create your test data. Make sure you have a test for each and every requirement. Also make sure that each branch in you design is tested somehow. Be thorough; test edge conditions, test invalid input. Verify that every possible input is going to be tested. Now test your design by hand. I know this sounds like something a computer can do better than a human, and in fact, it is. However, you would have to code your design in order to test it and that part comes later.

After killing yourself by pouring over each line of code with every item of test data you are now ready to code your program. Lucky for you, you’ve managed to create a perfect design after all that testing by hand, so this is actually the easy part. No thinking involved other than dealing with the minutia of the language itself (but you probably hinted at that in the design anyway).

Now do your actual testing in order catch your coding mistakes. Run all the test data through and compare it with the output from earlier. It all works great right? Great!

You’ve just managed to do so much work in advanced that the actual coding and debugging has become the shortest part of the process. The rest of the time you spent doing boring tasks that put you to sleep.

Now, not all methodologies are like this. Variants of the Agile method are more oriented towards the needs of the programmer instead of the needs of a corporation. These other methods make the time line of a project seem uncertain and risky, but in my experience, the final project has a higher quality and you’ve made your programmers happier at the same time by working with them instead of demanding deliverables.

So, long story short, the Waterfall method is a great way to make a working program, as long you think coding and debugging is the most expensive or least important part of the process. I, on the other hand, love to code. Requirements and designs are necessary, sure, but not in such detail. Lets get to the coding and test from there. Don’t make me do so much work that I will only do poorly because I hate it so; just tell me what you want, and I’ll code it for you.