A development style

Here’s a style of development I once proposed. I was reminded of it at SDTConf.

The project was to allow scientists to ask questions of a big database. There was a product owner who understood the scientific domain and - importantly - could have used the database to answer the questions (either by constructing SQL queries or by walking someone who knew SQL through query construction - I forget which). There were programmers who knew SQL and Java but were ignorant of the domain.

I proposed that the scientists not worry about programs. They should instead ask their questions of the product owner. They could either email them to her or talk to her on the phone. It would be her job to respond to the scientists with the data they needed.

At the beginning, I envisioned her doing one of two things. If the questions were dirt simple, she could pass them off to the programmers, who would build the queries, run them, and email back the results. Otherwise, she’d have to do that work herself.

So the programmers would be barraged with simple questions that would turn into simple SQL. Being lazy, they’d soon write code to automate query construction.

As the project continued, the product owner would hand off more and more complicated questions to the programmers, who would construct more and more complicated queries. They’d improve their programmatic interface to the database. Who knows? - they might find a need for an object model.

At some point, the programmers would be capable of answering most any query. They would have improved their interface to the point that it would make common queries easy and uncommon queries possible. Except… the user interface would be lousy, suitable only for programmers.

At this moment, the scientists are happy in one sense and sad in another. They’re happy because they can ask questions of an intelligent interface (a human being, rather than a program) - after all, their goal is not to use a program but to effortlessly get their questions answered. But they’re unhappy because the results don’t come fast enough. They have to wait for some human (programmer) to type at a program.

The programmers have become bored entering queries for the scientists. They’ve mastered the domain (of scientifically-relevant query construction) and want to move on.

So now the project becomes one where the programmers try to create a good enough user interface that the scientists will prefer the instant gratification of using it to the pleasantness of interfacing with a smart human instead of a dumb computer.


I liked this approach because it front-loads the important bit — capturing the domain, representing it in code — but it still starts providing value to the end-users really, really early.

Unfortunately, I discovered once again how politically inept I am, so I got tossed off the project without ever trying this scheme. I’ve wanted to ever since.

3 Responses to “A development style”

  1. Steve freeman Says:

    an interesting idea. I suspect the real killer is that the programmers would have to have slack so that they can promptly respond to queries and have time to start to build the tools that would make up the application — and we all know that programmers must be fully allocated…

  2. Stuart Ervine Says:

    As I read this I got more and more intrigued about how you went about convincing the team to work this way, as it appeared to be a clever solution. Then I it the last couple of lines and had to laugh - I hope you get to try this out at some point!

  3. Tyson Says:

    I’ve used this method on several decision support systems for healthcare - build the database, start delivering value to the business via programmer-created queries, then get the user-created query UI in place.

    One benefit of this approach is that the business rules are never fully defined in advance. You’re always discovering edge cases where the business rules as given don’t quite fit. After a few iterations you have a much more complete set of rules in place. By building the database first, you can continue to discover those issues while the front-end is being built in parallel. By the time the users are creating their own queries, the database has been refined considerably, and the users will have an easier time of query construction.

Leave a Reply

You must be logged in to post a comment.