Interwoven flows of activity, not a PERT chart
By Dave Snowden · June 3, 2009 · Reflections
I enjoyed the two London sessions to day, talking in seminar form about version 3.0 of SenseMaker™. It was good to be able to open each session by showing a series of actual projects rather than a set of principles. Its a lot easier to understand semi-constrained signifer structures (illustrated and patent pending by the way)with real examples. Version 3.0 is for me a labour of love, and the development team didn't just share by original OO vision but took the idea further and made it better. Hopefully we will get some of this written in journals over the next few months, if we ever get anytime.
Now I've been involved in software development for many years, this will be the third application product I have taken to market from scratch, although the first time with my financial future at stake! You learn through that process, and I was reflecting on that learning on the train home this evening. For what its worth I've summarised that below, in no particular order!
- You need to be paranoid about compromise on the basic design principles. SenseMaker™ is a four tier architecture and its object orientated. The database is separate from the business object layer, which is separate from the application layer, which is separate from the presentation layer. This gives considerable flexibility when you are building new modules, or interacting with other applications or capabilities. The danger is that doing this right takes a long time and people don't see the final product until the end of the process. The temptation to get something out fast without getting the basics right can be overwhelming. In version 2.0 as a result of both client pressure, and the natural ideology of the developers we didn't have the luxury to do this, which meant lots of bespoke work to handle developing requirements.
- Educating people without experience of OO type development is always neglected (I made that mistake for the third time in my career). Most people without an IT background tend to judge what is available by what they can see. Now in the sort f development we are doing, you only really see the screens at the very end of the process. Testing is also different, if you know an object works then you can move forwards. You don't need a full cycle test across all modules before you deploy others. If the objects test out, if the assembly in that module writes data to the database then its ready to roll. I think we finally made the point last week when we set up five new projects (all XML driven) in a couple of hours (nearly all editing time) while each version 2.0 system took a day or so. Of course that same script also creates the iTouch versions as well as the web capture, and will in turn drive Signifier a personal and organisational productivity tool that will be released into Beta later this year.
- You need to trust people without constant communication. In a small team, working intensively (all of us have done all nighters in the last few months and worked most weekends and evenings) you have to assume that if you have thrown a ball other members of the team will catch it. You can't expect lots of progress reports, checklists and controls. Good development is a series of interwoven flows of activities, not a PERT chart. At times you just have to focus on one thing, and you often work at an intuitive level. I remember some 20 years ago spending a 28 hour stretch at a WANG computer writing a routine to handle the most complex organisational structure I had come across (the Vesty Group), fed by coffee and bacon sandwiches by a sympathetic security guard in the Smithfield Office where I was working. It took two other members of the team a week to deconstruct what I had done and document it - I couldn't, but it worked. These days I no longer have the knowledge or skill, but I see the same phenomena in other younger people.
- You need to realise that good application design is a synthesis of technical skill, the designers vision and to a degree the user's need. It remains a truism that people generally specify a system based on what they do not like about what they have, a few things they have seen elsewhere that they fancy and the odd idealistic statement or two as a fall back. One of the things you find when you are programming is that different ways of doing things, including major innovations and novelties come to you as you are doing the work. Any design parameters need to be flexible enough to allow this, nay they need to encourage it. This is especially true of an application product where you are designing it for users and applications of which you have no current visibility.
- Small teams work, large teams don't. Short and sweet, but oh so true.
Now I am sure there are more, but that will do. One of the things you see when you adopt this approach is that as you reach the end of the process you have more capability than you originally designed. We already have one company looking to use our frameworks to develop their new product. They save time and effort (and also have integration to our survey and KM tools), we gain proof of something we hoped for, but now know that we have achieved, namely that SenseMaker™ V3.0 provides an integration architecture for social computing in an organisational context.