If software is the answer, what's the question?

In the last post there was a really interesting observation I noted from a user group meeting: "Customer come to you with solutions, not problems". In fact this weekend at an architecture meeting we spent the whole day talking about questions rather than solutions. Its such a fundamental observation and so much could be said about it. I thought I would share a story to elaborate this point. 

Almost ten years back I joined a team mid-way through the project. After speaking with the team I understood what the project was about and I was assigned a module to work on.

The basic requirement was this: there would be a stream of events, it needs to be processed to generate a specific report. 

Sounds simple enough? Coincidentally, the customer was quite tech-savvy, possibly with a IT or ICS degree, and he gave us a lot more than this basic requirement. He told us he wanted it to be cross-platform, highly-available (5 minutes downtime in a year) and highly-reliable (zero information loss).

The team was composed of super-star developers, all competent at their jobs. I knew most of them and had great respect for their technical abilities. This was the perfect project for them. They had written great code to raise the whole structure from the ground.

At the time when I started working we were half-way through in retrospect but already over time from its initial estimate. We had implemented 90% of the functionality and we were even doing our own version of Netflix's "Chaos Monkey". Although, we were the monkeys in this case, killing processes, restarting machines, monitoring how quickly our system healed itself.

The only problem was: the numbers weren't correct on the report.

The system was continuing to throw exception cases and every time we received another one, we put in some code to handle that case. It was like duct tape over duct tape and it did not feel right.

So I asked my team lead to put me in touch with the client and I sent him a list of questions based on my analysis. As the emails went back and forth and we started to elaborate on the problem, I realized that all other things were great to have but it was the numbers on the report that was the customer's real problem. 

He had given us a 1000 page technical document that described each and every system event. I then sat down to read all of it, along with the appendices, and through sweat and tears arrived at a model for processing the events. I had to rewrite the guts of the processing module but when it was done the numbers looked very different and it could account for all the cases.

It seems that the real requirement got buried in the numerous peripheral requirements and encyclopedia of a system documentation. No one wanted to go there and a bit of "bike-shedding" took over. 

When the customer arrived on his next quarterly visit, fourth in the series, we gave him a demo by running a simulation and he finally said, "This is what I wanted!".

Postscript: If you are not a hardcore computer scientist, you should stop reading here for your own sanity.

The problem with the processing module was that it interpreted the string of events as a Type-3 language, also known as "Regular Expression". When in fact it was a Type-2 language and required a "Deterministic Pushdown Automaton". And for obvious reasons we had numerous exception cases. I never thought I would use "Automata Theory" we learnt at university, ever, in a real-life project. I thought they  were all JavaScript and RDBMS projects. Guess it was taught for a reason.