The Power of the Door

I have just read an interesting presentation on the rules of productivity. It presents 8 rules to determine the most productive number of hours per week (40), the type of office environment (team rooms) and how a team should be located (non-siloed - multi-disciplined). In most cases the results are possible counter-intuitive to most management but each of the results are backed up by sound evidence.

It made me think about my experiences on numerous development projects and I would tend to agree with the recommendations outlined in the presentation. I remember when I was working long hours AND studying for a post-graduate degree trying to write some very simple Eiffel code and failing to get it work after 2 hours of staring at a simple logic problem. I simply couldn't solve it at the end of a 15 hour working day. I went home and came back a few days later, refreshed. I solved the problem in 5 minutes. The lesson was clear to me then - you need sleep, not heroes. This was admirably demonstrated in an overnight session to get a demo working and after 8 hours through the night of being in a no better situation than we were when we started!.

As organisations have changed over the years, office space has become at a premium. The 'power of the door' was demonstrated when I was a young engineer doing a major retargetting exercise. I remember we had to convince our manager of the benefit of having our own server to work on this exercise - he agreed provided we could reduce the schedule by 6 months. This we did easily, not just because of having our own server but because we had a large wooden door on our small team office. If it was shut (which it was normally) people just walked past so you didn't get disturbed. I would guess that if we reverted back to small offices, the software industry would be much more productive than it is today. I wonder how many project  managers have the power or insight to challenge the office environment and make the necessary changes that will increase the chance of project success and increase team morale. 

How DSM can improve productivity

At the SPA2008 conference, I attended a session on Domain Specific Modelling given by Juha-Pekka Tolvannen from Metacase. I increasingly believe that the use of full code generation can lead to significant improvements in productivity, and if appropriately managed, code quality. I was therefore interested in Juha-Pekka's assertion that productivity increase is achieved not by using particular high-level languages such as C#, Java or Python or design approaches such as UML, but by increasing the level of abstraction. There have been some attempts through the use of frameworks, patterns and libraries which can help the abstraction level provided that the artefacts are used appropriately.

However Domain Specific Modelling (DSM), which is creating a language for specific purposes with automatic code generation, can lead to bigger gains in productivity when compared with normal development practices (claims of up to 30 times the productivity) with the code generation resulting in 50% less bugs than manually written code. The productivity gains need to be considered with the cost of the creation of the specific DSM and the number of times the DSM is to be used.

The cost of the DSM development (typically one or two developers together with a number of domain experts) and the number of applications over time can then determine whether a DSM will deliver the required productivity gains.

The examples which were cited clearly demonstrated the power that DSM has in producing production quality code quickly and efficiently. It is clear that for some large development projects, there would need to be many different Domain specific models created to support the development, and that it is highly unlikely that a whole development could be completed entirely using DSM. Clearly some further research is required to determine the categories of applications for which DSM should be considered - off to visit the DSM Forum.