It’s All An Excuse
As a thought experiment, I recently looked at various programming methodologies to see if I could find common ground between them.
I looked at the following methodologies:
Ideas such as literate programming were ignored from the list, as any of the processes listed above could also be done in conjunction with literate programming.
Here’s my list with explanations. I reckon that all of the methodologies are all an excuse for doing the following:
Think about what your code does before you write it.
“Of course you should do this!” I hear you screaming. However, even the obvious needs to be included in a methodology. For something so obvious, there were quite a few different ways of handling this idea.
The Joel Test, for example, asks “Do you have a spec?” This is similar to the Rational Unified Process, which demands a large up-front Elaboration phase to be mostly complete before any coding begins. These are up-front and monolithic methods of designing products, but it is difficult to argue with the success of either Fog Creek or IBM.
On the opposite end of the spectrum we have Scrum and Extreme Programming, which take release planning on a much more granular scale. At the beginning of the project iteration, you meet with the customers and decide what and how you will attempt to do over the iteration. The difference between Extreme Programming and Scrum is the length of the sprint iterations. Scrum requires that you meet with customers at the beginning of the sprint (15-30 days), and then freeze the requirements over the course of the sprint. Extreme Programming, on the other hand, sets this at about a weekly basis.
Make sure your own code works.
Extreme Programming and The Joel Test are both in-your-face in this regard. The Joel Test specifies that there is a bug database as well as an effort to fix bugs before new releases. Extreme Programming is a test-first methodology, so your code starts out failing the tests (as your code is not even written to begin with), and your task is finished when your code passes all of the necessary tests.
Testing is also a specified phase in the Rational Unified Process, which hints that there should be some form of an automated testing script. Scrum, as a methodology, does not explicitly have a testing requirement, but every single day the team is required to talk about their progress, as well as any roadblocks that they encounter. This is a good encouragement to make sure that the code works, as you will be talking about it on a daily basis.
Frequently check to see if code works.
This was one of the most common ideas between all of the methodologies.
The Joel Test specifies that the programmer should both be able to have a one-click build as well as be able to have access to daily builds. Extreme Programming and Scrum both focus on tiny releases. The IBM Rational Unified Process specifies that you should be able to “demonstrate value iteratively,” which does mean to have frequent builds — once you transfer from business-ese.
Have someone else make sure your code works.
This was another string thread through all of the different methodologies, and nowhere was this more evident than Extreme Programming. First off, Extreme Programming dictates that programming is done in pairs. While you are typing away at the keyboard, another programmer is behind you, making sure that everything you write is a) valid, and b) in the spirit of the rest of the program. Unit tests also provide an independent verification (if the tests are correct).
The Joel Test strongly emphasizes this point. It specifies that the programmers are supposed to not only have testers, but are supposed to be able to easily do hallway usability testing. Your code is getting worked on from two different angles: not only are all of the module interactions being tested by the testers, but your interface is also being vetted by your fellow programmers.
Scrum and XP also have the results of the project placed in front of the customer frequently to see that what is being produced is ultimately what the customer would like to see.
The Rational Unified Process encourages the iterative development to bring the customers in on releases in order to allow them to weigh in on progress. It also has a specified testing segment, which encourages large teams to form individual testing units that examine the interactions between modules.
Fine Code Granulation
By fine code granulation, I mean that the code should be broken down into the smallest possible functional units. The Rational Unified Process, Scrum, and Extreme Programming all actively encourage participants to have refined iterations with deliverables at the end of each iteration. Granted, this does not necessitiate that the code is modular, but it certainly encourages it. The Joel Test specifies that there should be a daily build that can be tested and monitored for correctness.
In my own personal experience, this is one of the most important aspects of finishing a project quickly: it’s easier to figure out why a function named “determinant()” is failing than it is to figure out why the determinant section of a function named “matrix_inverse()” is failing.
My Question: Is this a list with all of the necessary and sufficient items?
Should source control be on the list? Probably, but some of the successful projects treat it as a fundimental assumption as opposed to a requirement. Is it always necessary for developers to have flawless working conditions, as Joel claims, or is it sometimes necessary to have the end-of-project crunch?
Popularity: 8% [?]