Assuming that you are already sold on the notion of automated testing, it can be useful to put a little thought into how projects will be setup. There are many approaches to this; my approach is based on experience, the wisdom in xUnit Test Patterns, and standard coding best practices. I will try to keep this language agnostic, though my examples will be in C#.
This past Wednesday I was proud to take part in a banquet event on the theme of "Embracing Unity," sponsored by the non-profit Grand Prairie Unity Coalition, of which I am a new Board member. This was the 7th such banquet, which brought together people from many like-minded organizations, local / county / state politicians, and most importantly, around 40 students and family from the local school district. The organization's mission is to provide education and opportunities for cross-cultural association to the Grand Prairie community, and that mission was admirably pursued with Wednesday's event.
"The best way to attack the essence of building software," Dr. Brooks writes, "is not to build it at all." (p222). With this he introduces a brief discussion of the importance of code reuse, and of its challenges.
Lately I've been wondering if the Keystone Pipeline isn't more of a NIMBY than anything else. NIMBY stands for Not In My Backyard, and is typically a reference to well-off individuals and communities decrying the building of some unwanted facility "in their backyards" — that is, just down the street or in the general vicinity. For example, in St. Paul, MN there has been an outcry over plans for an electricity-generating incinerator (dead link removed; SF 2025 removed) on the edge of the neighborhood in which I used to live. Now, that is a blue collar neighborhood, not particularly well-off. A classic NIMBY situation is where the well-funded are able to fend-off development, pushing it to some location where the project's opposition are not so well funded. Thus, the NIMBY-effect becomes a matter of eco-justice: the poor end up saddled with the polluting plant, though the rich derive at least as much benefit from the project.
Recently I began carving out some time for using CruiseControl.Net in earnest. The book Continuous Integration in .Net was, and I'm sure will continue to be, of great help. Nevertheless, I think it will behoove my own memory, and perhaps help a few others, to record some notes on a few practical details.
I've started a new project on CodePlex, called Reggie, and posted the initial working source code. Reggie's goal is to be a simple developer tool for writing and testing Regular Expressions. It is inspired by the venerable Regulator tool and will be created in WPF using the MVVM pattern.
In the chapter titled "Plan the System for Change," Dr. Brooks again lays out the foundations for Agile software development. His was an era of dumb-terminals and highly scheduled availability. And yet, here he is saying, "plan to throw one away; you will, anyhow." When RAM wasn't cheap, and good programmers even more rare than today, how does a project manager or architect justify throwing out the first design on purpose? By recognizing that "[t]he only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers."
Overclocked, Stories of the Future Present, is worth buying. But you don't have to, thanks to the fact that Doctorow made it available under a Creative Commons license, and you can download it for free. These are incredible short stories, standing up with the best of Bradbury and Gaiman (my favorite short story authors). When Sysadmins Ruled the Earth was gut-wrenching, at least for this former sysadmin. I, Row Boat manages to beguile and frighten you at the same time. What's more frightening than an angry, conscious, coral reef? Pared up with a row boat working through existentialism? Print Crime is a beautiful call to the indomitability of the human spirit, and Anda's Game is all kinds of biting and insightful commentary wrapped up in the thrill of virtual victory. I, Robot and After the Seige round out the brilliant set of stories.
Many of the recommendations Dr. Brooks makes in this work can seem outdated at first glance; however, it does not take much to bring them into today's software development environments. Take the telephone log for example:
"One useful mechanism is a telephone log kept by the architect. In it he records every question and every answer. Each week the logs of the several architects are concatenated, reproduced, and distributed to the users and implementers. While this mechanism is quite informal, it is both quick and comprehensive." (p69)
Aside from being a fascinating inside-look at some of the challenges faced by the mainframe programmers of the sixties, The Mythical Man-Month presents many lessons-learned that are no less applicable today. This is the second article in a series exploring some of these lessons, in particular: conceptual integrity.
