Rethinking Software Development, Testing and Inspection
Michael Fagan first found software inspections yielded a massive productivity improvement when working for IBM in the early 1970s. Now, 35 years later, we need to ask certain key questions: Are the dynamics of software development the same, are Fagan's findings still relevant in today's world of agile development and "extreme programming"? And, if so, what should your organization do about it?
Wed, February 01, 2012
CIO — Setting the Scene—Where Formal Inspections Were Born: The early 1970s were a bit like the old Monty Python Skit "The Four Yorkshiremen," having a reel-to-reel tape drive was "luxury" and most people still had physical punched cards. Robert C. Martin, a co-author of the Agile Manifesto, described this era in his book The Clean Coder
These tapes could only be moved in one direction. So when there was a read error, there was no way for the tape drive to back up and read again. You had to stop what you were doing, send the tape back to the load point, and then start again. This happened two or three times per day. Write errors were also very common, and the drive had no way to detect them. So we always wrote the tapes in pairs and then checked the pairs when we were done. If one of the tapes was bad we immediately made a copy. If both were bad, which was very infrequent, we started the whole operation over ...
We edited the tapes on a screen ... . We would read a "page" from tape, edit the contents, and then write that page out and read the next one. A page was typically 50 lines of code. You could not look ahead on the tape to see the pages that were coming, and you could not look back on the tape to see the pages you had edited. So we used listings. Indeed, we would mark up our listings with all the changes we wanted to make, and then we'd edit the files according to our markups. Nobody wrote or modified code at the terminal! That was suicide. Once the changes were made to all the files we needed to edit, we'd merge those files with the master to create a working tape. This is the tape we'd use to run our compiles and tests..
Think about the consequences of a compile error in this sort of environment. You'd need to find the right tape, set it to the right point, edit the page, resave the tape, then run it into the machine ... only to find the next compile error and start the process all over again. With a dozen compile errors, you might lose a few days of productivity; if your team was using punched cards that were compiled in an overnight print run that might be a few weeks.
