The Evolution of Code Generation

Derek, our Technical Director, has been working in software development over the last 25 years and set up Objektum Solutions over 10 years ago. He reflects in our latest post about whether we have learnt from the past with regards to code generation...

 When I started my software career, it was common place to develop code in low level assembler languages such as Z80, 6502, 68000 etc.  We had little or no design methods, development tools or strict processes to follow. Ensuring we met even what requirements we did have, was difficult and code reviewing was a labour intensive task that often resulting in a “ticking the box” exercise?  

I remember working for a company that introduced Ada83 for the first time and being involved with the compiler vendors, helping to pick the bugs out by looking at the assembler being generated.   I remember people saying “I don’t trust this code generation” way of doing things; that seems so long ago nowadays we trust the compiler put in front of us.

As software systems become even more complex, there is an increasing need to find alternative development techniques compared to the traditional low level methods and high level programming languages we have become used to.  This is necessary to ensure we maintain quality, adhere to requirements, increase productivity and do not increase the workload of project managers. 

Model Driven Development

Model Driven Development (MDD) is the next step of abstraction in writing software applications which are traditionally written in programming languages such as Ada, C++ and Java.   If we look back in the history of software development, we will find that each higher level of abstraction adopted has offered improved productivity and ease-of-writing complex applications i.e. moving from assembler to high-level programming languages.

MDD focuses on creating models, or abstractions, more closely related to domain concepts rather than computing (or algorithmic) concepts.  Typically models are constructed to a certain level of detail, and then code is crafted (even sometimes by hand!).  With the introduction of the Unified Modelling Language (UML), MDD has become very popular today within many industry sections such as Telecommunications, Finance, Defence etc. and there are now a wide variety of practitioners, supporting tools and processes.

• The advantages of MDD include:
• Improved communication of the design(including to the customer)
• Increased understanding of design elements
• Enhancing the consistency between design and code
• Traceability within the software design
• Increased productivity through efficiency 

Code can be generated from the models, ranging from system skeletons to complete, deployable products.  However, I am experiencing déjà-vu. Once again I can hear people say “I don’t trust this code generation”.  I wonder if in ten years we will simple trust the code generators put in front of us.

I have been working with UML for the last 10 years and in the subject of code generation and reverse engineering intensively for the last 5 years, and I’m looking forward to writing my next post and sharing my experience in developing reverse and roundtrip engineering tools. 

Derek

The Long Term Consequences of Short Term Solutions

In the first official post of our new blog, Alex, one of our Systems and Software Engineering Consultants and Lecturers steps up to the mic to share thoughts he had after going to IBM Rational's Innovation 2010 event... 

Shows and exhibitions form part of any industry so it’s hardly surprising that the software and systems engineering community has so many of them. I’m not usually a fan of these events which seem to involve an excessive amount of currying favour and flogging products – which really isn’t my style. 

Once in a while, however, I find a reason to attend a show and am pleasantly surprised by the outcome. It was to see a presentation, by a customer that I’ve been working closely with, that I attended IBM Rational’s Innovation 2010. I was interested to see how he would present the work we’ve been doing in applying a model based approach to systems engineering (a subject of intense interest to me at the moment). 

As expected, the presentation was both entertaining and informative; to the point where I felt compelled to restrain myself from adding the occasional joking heckle from the front row (something I’d been light-heartedly threatening all morning). Even when the presentation glossed over some challenges in the chosen methodology (something that we’re still working out with the client) I kept mum although I did comment on my observations during the team ‘post mortem’.

It was during that discussion that we were approached by a software engineer who wanted to learn more about how we had overcome the challenges of introducing modelling within the company. It transpired that the company of said software engineer had introduced object oriented software development and had invested money into a tool without providing any process, methodology or training in the use of UML modelling. Naturally this approach was not as successful as was hoped and they were starting to doubt the approach.   Having invested considerable personal time and resources to training himself, the engineer in question was bordering on becoming distraught, fearing that his company would see OO as inappropriate and that he would be trapped in a world of functional decomposition for the rest of his career.

When asked my opinion on how to prevent a failure to move forwards I was reminded of the Agile Manifesto which states, as one of its tenants, “we value individuals and interactions over processes and tools”.  It has made me wonder how many other organisations believe that throwing money or technology at a problem is a magical cure all and fail to understand that it is investment in training and the correct application of methodology that is the key to success.

In this era of economic uncertainty and cut backs it is easy to understand how people adopt a quick fix approach to problems but someone has to spread the word that investing in improvement now will reap rewards in the long term.

Alex

Permission to Launch

Cat, who looks after all our marketing, kicks off the blog with our first post...

 Firstly, I have a confession to make. I am the least technical person in Objektum Solutions. To give you a gauge on this, I got overly excited the other day when I was able to map a network drive to my computer without having to call out pathetically for one of the team to help.  So yes, it is a little strange that I should be writing the first post in The Technical Diaries, but whilst the rest of the team are coming up with ground-breaking, never-done-before, problem-solving technology and solutions that make clients say (and I quote, verbatim) “It’s like all my dreams have come true”, I look after the communications for Objektum. 

Now, over the last month our internal communications have gone pretty much like this:

Cat, “Derek, you need to get involved with this discussion on LinkedIn, its right up your street”

Derek, “Yes, alright, I’ll do it later.”

Cat, “You said that last time I asked. Do it now.”

Please don’t feel sorry for Derek. I’ve been picking on everyone.  Slowly but surely, everyone has started to see the value of LinkedIn. As much as I was excited about mapping that network drive, whenever somebody now uses the word “connecting” in the office they look over at me and smile as if to say “Get me talking this marketing lingo!” 

It wasn’t easy to explain to a group of very practical people that we needed to be “spreading the message” and you can imagine the blank expressions when I mentioned “thought leadership”. But there was a turning point that shocked me to my very core. After a training session we had on Search Engine Optimisation and Marketing, Alex and Derek turned round to me and both said in perfect harmony “I think we should start blogging”.  I asked them whether they would actually write the posts. They said yes. I asked them whether they would be committed to writing interesting content even if they were really, really busy. They said yes. I asked them if they would resent me nagging them about it. They smiled. This is obviously yet to be discovered but I’ll let you know... 

As indicated in the name of the blog, The Technical Diaries, this will be a collection of posts and stories for those in the technical world. I’ll try to make sure that it is not too dry and it will cover a wide variety of topics including more human factors.  If you subscribe to our RSS Feed you’ll be able to see when there’s something new to read and comments and suggestions are most welcome. 

Thank you for reading the blog thus far. 

Cat