Showing posts with label DSM. Show all posts
Showing posts with label DSM. Show all posts

Wednesday, April 2, 2008

SPA2008 - some final thoughts


It is now 2 weeks since the end of the SPA 2008 Conference and I have finally finished writing my notes. (Yippee!) So what are my final thoughts and what I am going to take away for exploring in the next few weeks and months?

I thought the conference was excellently run with a good mix of software practitioners attending. I was spoilt for choice in selecting the sessions to attend but there are some good notes appearing which summarise the sessions I didn't attend. There are also a number of articles appearing on various blogs. The dialogue during and between sessions was also stimulating and I hope to continue this when time permits.

Technically, I am particularly interested in following up the following topics:

I also learnt a lot about me. The conference confirmed that generally, the work I do is pretty well in line with what the rest of the software world in the UK is currently doing (or tyring to do!). There are differences but these appeared to be related to the domains, size of developments and team dynamics.

Tuesday, March 25, 2008

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.