Really Cool Things

A friend of mine from college recently sent me this article by Tom DeMarco (co-author of classic book Peopleware) about rethinking the importance of controlling projects. http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r.

Some of the more relevant passages:

• I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to control them, no matter how assiduously we apply ourselves to control.
• Your job is to go about the project incrementally, adding pieces to the whole in the order of their relative value, and doing integration  and documentation and acceptance testing incrementally as you go.
• I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.

If I read this correctly Mr. Demarco is accepting that there is a class of software that can evolve incrementally with minimal downside.  When Controlling Software Projects was written in 1982 they way software was written was very different.  There was an Internet but it was a very different place.  Software was invariably written, tested, and shipped mostly on diskettes and tape.  Today with the advent of the web all but the most isolated systems can be updated on the web.  This means that the price to patch software is much lower.  This obviously works very well for web-delivered applications where the customer typically does not need to install anything.  Indeed there are a class of applications (safety critical, analysis, machine control to name a few) where the old way still makes sense.

Moreover, the development tools (Visual Studio, Eclipse) and languages (C#, Rails) we have at our disposal today are much richer than what was available 27 years ago.  The reality is that object-oriented programming has fully taken hold.  For example, I can query query a database, apply business logic, and bind the results to a page today in an order of magnitude less time than it would have taken in 1982.  The reason its so much easier is that all of the components to do the plumbing have already been built for me.

I am personally a big fan of Agile, however, I’ve seen a tendency to cut corners particularly on the documentation end in the name of expediency.  Its always a good idea to get alignment between the developer and business owner.  That doesn’t mean that a 50 page specification needs to be written but there should be that contract.  I’ve seen business requirements be captured well in PowerPoints, emails, and photos of white-boards.