Cost of fixing bugs at different stages of the software development process

It is generally-accepted common knowledge that the cost to fix a bug increases exponentially throughout and different stages of the software development process.  But what is the basis of this belief?  This author tried to track down the source data:  An apology to readers of Test-Driven iOS Development.

Nominated for Outstanding Java Spec Lead

I have been nominated (again!) for the "Outstanding Spec Lead" award that is presented by the Java Community Process (JCP), the organization that oversees the evolution of the Java language and platform. The JCP asked me to reflect on my co-leadership (with Alex Buckley of Oracle) of JSR 308, which extends Java's annotation system. Here is what I wrote.

JSR 308 (Type Annotations) has the ambitious goal of changing the Java language.  It provides a platform for developers to express and verify correctness and security properties that currently remain implicit, or are documented and checked in error-prone and ad-hoc ways.  As with any language change, it must integrate smoothly with existing features and tools.  These goals required meticulous and sustained effort.  Here are some principles that guided our work.

Don't give up, despite any adversity.  I first implemented a pluggable type system for Java in 2002, over 10 years ago.  I pitched the idea of expanding the Java programming language to Sun in 2004.  JSR 308 was formed in 2006.  And the feature will finally appear in Java 8, in 2013.  Related to not giving up, don't get started unless you really believe in the goal.  Only passion will give you the stamina for the long haul.  It's worth it!

Get help from others who will help you do great work.  In a sense it's unfair to offer an award to just one person such as me.  I have been tremendously helped by many people, notably Alex Buckley and Werner Dietl, but also the JSR 308 Expert Group, Mahmood Ali, Jonathan Gibbons, Brian Goetz, Doug Lea, Matt Papi, and many others (too many to list them all here).  I thank them all for their significant contributions.  The real winners will be Java programmers.

Run your project transparently, in the open.  This is the best way to get lots of valuable feedback.  Your passion will help you to withstand the criticism that is inevitable in an open project when not everyone's desires can be met.  Be straightforward in admitting this, and offer explanations and principles that explain the reasoning.  JSR 308's mailing lists, FAQs, etc. are linked from http://types.cs.washington.edu/jsr308/.

Balance innovation and risk.  Innovative ideas that change how developers work often come from academic research.  This was the case for the type systems that motivated JSR 308.  But, the motivation must come from real problems that arise in practice, during developers' daily lives.  JSR 308 omitted many features requested by academics because they have not yet been sufficiently tested in the field.

Work fast to meet product deadlines, but don't succumb to pressure to cut corners.  It's better to seek a cleaner solution than to saddle Java programmers with an ugly design forever.  You will end up with something, like JSR 308, that you can be proud of.