Question-Driven Development

I wrote my first computer program when I was a freshman in high school sometime around 1970. Contrary to popular belief, I was not banging out code on clay tablets. But I was using punch cards. Even so, I was using a dedicated mini-computer, and just a couple of years later, transitioned to an interactive time-sharing system. I remember fondly a couple of years after that, trudging through hip deep snow, three miles, up hill, both ways, to the college computer center.

It took me more than thirty-five years of writing code to put a name to my personal software process: Question-Driven Development. I find that I am constantly asking questions about my code as it, more or less, magically appears on the screen in front of my eyes. Sometimes the question is what the hell is this? But just as frequently it is one of the following.

How will I test this during development?

• Can I unit test every single code path?
• Do I have error legs that are difficult to exercise?
• Have I checked my code coverage using tools like Cobertura?
• Do I have confidence that taking a rare error leg won't somehow escalate the problem?
• Are there private inner classes that need to be tested independently?
• Have I tested my settors and gettors?
• Do I have reasonable defaults if the settors aren't used?
• If settors must be used, why aren't those settings set during construction?
• Can I have a no-argument constructor, and if not, why not?
• Have I tested my component for memory leaks using tools like JProfiler?
• Have I done static analysis using tooks like Klocwork?
• Is this code thread-safe, and if not, why not?

How will I debug this during integration?

• How can I tell if its a bug my component or another component?
• Are the interfaces between components independently verifiable, and if not, why not?
• Are there independent ways to indict my component versus other components?
• Do I have a reasonable message logging framework?
• Have I chosen the severity of each logged message appropriately?

How will I troubleshoot this during quality assurance?

• Can I quickly indict the failing subsystem?
• Will turning up the log level while under load firehose the screen or the log file?
• Will turning up the log level while under load somehow escalate the problem?
• If performance problems arise, can I determine where the time/space is being spent?
• Do I have a way of independently testing my component in the context of the larger system?
• Do I have a way of testing my component end-to-end with the other components?

How will I support this during customer deployment?

• Can I indict our software versus other software?
• Can I efficiently capture the forensic information I need in a transportable form?
• Can I quickly get the customer's system back up and running?
• What is my priority when a problem occurs: forensic data capture or returning to an operational system?
• Can I quickly determine a plausible story to reassure the customer?
• Is that story likely to be correct or am I going to look stupid later?
• Are development resources available to quickly fix bugs and turnaround a new release?
• Have I given the field support folks the tools they need to get their job done?
• Can the field support folks do their jobs without calling me all the time at all hours?
• Have I chosen the severity of each of my external alarms appropriately?
• What is the cost of raising an alarm?
• Can the system recover automatically or are there circumstances where our field support folks need to roll a truck?

How will I transition this to another developer during my move to another project?

• Will the new developer need to be a subject matter expert like me?
• Do I need paper documentation or is a wiki or javadoc more appropriate?
• Have I left the new developer a mess to clean up?
• Do I have deprecated code that I need to remove?
• How do I know for sure that no one is using the deprecated code?
• Is the deprecated code unit tested?

What other questions should I be asking?