While it’s fun to dump on the faddishness in software development, the rise of unit testing represents real progress in the state-of-the-practice. As an example, in the Django framework where I spend most of my time, I appreciate how much the framework helps me begin writing and running unit tests.
Thanks go to the test-driven development movement for making testing cool and inspiring an ecosystem of automated unit testing tools, even if it turns out that TDD itself provides no measurable benefits (the evidence to date is mixed).
If they can’t even do it in basketball, the prospects for us being able to do it in software development are bleak.
I was glancing through one of the LinkedIn software group discussions, and noticed that the poor state of software development was being discussed. Whenever I hear these laments, the question that comes to my mind is, “compared to what?”
It isn’t obvious that software development is in much poorer shape than, say, civil or mechanical engineering, and I’m not even sure how to make a meaningful comparison. Consider IEEE’s Risk Factor blog. Yes, expensive software failures are still a too-common occurrence. Yet, as I write this, the second Risk Factor post from the top discusses the fatal Washington DC subway crash in 2009 which was due to an electrical circuit failure, not a software defect. While the field of software should always strive for perfection, it isn’t a realistic standard to be judged against and found wanting.
As an aside, here’s a study I’ve always wanted to do: compare cost and schedule overruns for government IT projects versus government construction projects of similar initial budget and schedule projections. The raw data should be publicly available, assuming one knows where to look. Comparing how well the projects met their requirements across the domains would be more challenging.
The Wall Street Journal explains stand-up meetings and agile software development to the layperson.