Poison meetings and secret innovation

The day-time project I’m currently on is developing new software to replace an old application, which is in too bad condition to maintain (or so they say). So they had to make some research into what the new requirements are, as the current system is used fairly diverse in different parts of the huge corporation. In order to gather requirements and prioritize them, one of (!) our project managers held a whole lot of workshops at a cost of about 75 kUSD. Like any waterfaller can tell you, these requirements are just scratching the surface, and nothing to hold on to when the development storm arrives.

So I asked for a small meeting, involving four people, where developers could gain a better understanding of the problems that the end-users close to the core of the business face. The project manager wasn’t happy when I asked for this meeting; she even blamed us for not having extracted enough information from the 25 workshops she held! Interesting that she didn’t praise herself for wasting 75 kUSD...

However, I got the meeting. It was good, we learnt I lot, and I came up with a small idea. The users have to sift through huge chunks of information, but it’s hard to find all the ways that they want to filter the data, as it varies between roles and departments. One thing that is pretty obvious though is that almost all of them export data to excel to do their own filtering. So my idea is simply to allow the user to write a custom filter. In secrecy I spent 5 hours writing a small parser and executor that can be used to filter data rows. This currently-tiny DSL is very easy to expand on (currently 300 LoC), but only has nine operators. It looks something like this:

        (fg = 7 or fg_sfx = 8) and item != bolt and item_no != 5112

I went for simplicity instead of strictness (think Excel), so it’s case insensitive, no quotes needed for strings. Typing is strict though.

We also have a red-tapist on the office, who thinks that inventions never should take place unless asked for. We would still live in caves if that point of view would prevail, so I’ll take it directly to 1) an end-user and 2) to requirements people and 3) to the business side.

This small idea makes it possible to repeat the same filter across a number of different datasets (lamers: think GUI tables) without risk of manual error. It even ails me to think about the current blunt ideas proposed, when this could supersede many of them. In 300 lines of code!!! I feel confident that this will/would save Volvo millions, the only issue left is to get the project people in the way to understand The Power of it! Wish me luck...

PS. If a game could say it all, it'd be this one: Middle Manager of Justice.