QCon 2007 Problems solved and problems unsolved

This post comes partly from my musings on QCon, where one of the main themes was better communication between business people and tech people, and partly from Reginald Braithwaite’s blog, where he remarked:

Am Ideveloping the ideas, technologies, and products today that the rest of the world will be using in ten years?If not, what’s stopping me?

Down a thread of comments, Peter Bell noted:

I also see companies focusing on creating application generators so you can generate an application “in minutes not months”, without realizing that you also have to have a process and tooling to support the capturing of business requirements in a systematic manner to drive your generator otherwise you’ll be generating applications in minutes but still taking months to specify them.

Creating an application in minutes is a solved problem. Rails does it, Grails does it, JBoss SEAM does it, and we’re building an in-house solution to do it using Maven. And that’s all good, and all these solutions can learn from each other.

But it seems to me that the tricky bit, the unsolved problem that is worth solving, is how to capture customer requirements to customize the results as effortlessly as possible. Yes, we bend over backwards to have customers in the same room as the developers, to bridge the yawning crevasse of doom between business developers and software developers (QCon keynote). Yes, we try to get the best software developers working on the problem, so the code will always be clear and readable and easily-maintained.

But suppose you’re dropped into a long-running project, and you need to modify some code. Eighteen months ago there were discussions with the customer that resulted in the current state of the code as the best of three possible ways of doing it. These discussions weren’t part of the functional requirements of the story, nor were they in a bug report, so there’s no easy way to build a shorthand link from a comment in the code to an existing document. The developer pair who worked on it were both moved to another project and the customer is on a week’s holiday. If you’re lucky, there’s a comment in the code explaining “We did it this way because…”. But more likely there isn’t. Again, if you’re lucky, there might have been a small commit limited to this problem, with a useful commit statement, and checking the resource history will retrieve it. Or perhaps there’s a project wiki where these decisions are recorded. But, again, more likely there isn’t, because if we’re agile and top developers and we’ve got the customer on-site, it is easy to believe that the code should be self-documenting and self-evidently the best way to do it. And if the customer wants a list of names sorted one way on one page and a different way on another page, you can and should write a test to assert that that behaviour is preserved through any future changes, and if you’re lucky there will be a comment on the test explaining the business reason why the two orders are different.

But too often, conversations with customers that don’t make it into functional requirements or bug reports or comments in code or tests or commit statements are just lost, scribbled in notebooks that become “write once read never” documents. Even when they are recorded, it can be a challenge to track them down, if it’s in a Word document from 12 to 24 months ago but you’re not quite sure where. For once, I’m not suggesting we develop or use some bleeding-edge new technology: I’m saying that the problem I need solved now is how to build a recording framework so simple that everyone uses it for everything, and nothing gets lost.

Developers can put comments in the code, and with the right extraction tools could automatically produce reports for the business people, but that way the business people have their requirements documents and the developers have code comments and we violate “Don’t Repeat Yourself”. What I want is something that can be linked to the code but that the business people can work with too.

  • Give it an eclipse plug-in so that checking the resource history on a line of code gives me direct access not just to CVS/SVN commit statements but to the requirement documents, bug reports, and any ephemeral documents in between.
  • Give it highly-configurable options for spitting out Word documents so that business analysts in places which have more formal rules for requirements can use it to produce the documents their company requires.
  • Enable it to spit out Excel spreadsheets for QA, which grab a sentence from the requirements, the test which tests that requirement, and the success/failure of that test. (Of course we would need clever behind-the-scenes glue code to make the requirements document “testable”, but from a customer’s point of view, why shouldn’t it be?)
  • Make it incredibly easy and intuitive for non-technical people to use. (Think “intelligent paper”.)

A while back there was an Architecture Office initiative to identify the biggest unsolved problem on each project and work on a solution. This is not a technical or project-specific problem, but I think if we produce something that does this, then all our projects here on in will be the better and the more satisfying both for us and for our customers because it builds better bridges of communication between us and ensures things don’t get lost. And, yes, it looks like the forthcoming Mingle may already do some or all of this, but as with the several flavours of creating-an-application-in-minutes, building another one based on our own experiences so that there were two projects which could learn from each other seems to me to be no bad thing.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply