Friday, 26 August 2011

Interview: Overcoming Migration Challenges


Companies across the globe are continuing to allow legacy technology negatively impact their business because they either don’t know what to do or feel it is too risky or costly to modernise their applications. The reality is that there will come a point when they cannot ignore it anymore and they have to do something about their legacy systems.

Using the Legacy Bridge technology, one of our customers carried out a HOOD and Ada83 migration in to UML and Ada95 so that they could enhance existing their safety critical systems. We asked them about the migration and how they used technology to overcome their challenges they faced.  

What was the main reason for migration?

There were three main reasons:
  1. To have a single toolset for both Software Analysis and Software Design work
  2. To reduce the number of toolsets in use on the project (thus reducing maintenance renewal costs)
  3. To move to a company preferred toolset
  4. To increase integration with other company preferred toolsets (i.e. DOORS and Dimensions CM)

What were the alternatives to using Legacy Bridge?

The Rhapsody in Ada inbuilt reverse engineering tools or to develop our own in house migration tools however this was deemed early on to be too expensive.

What was the deciding factor to choose Objektum Solutions and Legacy Bridge to migrate?

Objektum Solutions had already been through similar exercises of migrating from CP-HOOD to UML albeit to a different UML toolset with another organisation similar to ours. Legacy Bridge has the facility to bring across our HOOD artefacts, as well as synchronising the design with the current code.

What time savings did Legacy Bridge bring?

Once it had been proven that Legacy Bridge could correctly analyse our HOOD and our Ada, the process of migration and synchronising with the code took only a couple of hours per model.

And, how was it working with the team at Objektum Solutions?

The support provided by Objektum was excellent, with most problems being resolved with days (if not hours) of being reported.  This enabled us to keep up the impetus of the migration process without have to wait too long for tool updates 
 
Another colleague also commented saying "The turnaround time for problem resolution was exceptional. This has been possible with the tremendous knowledge the team have of the product including HOOD, UML and Ada."

What benefits does migrating to UML give you for the future?

We now have both our software analysis and software implementation models in the same toolset; with both of these models integrated with our requirements database and our configuration management system.  All three toolsets are “current” toolsets widely used across the company and across industries.

Will code generation be a consideration going forward?

Code generation has to be ultimate aim; but for now we are happy that what is in Rhapsody can be shown (via the compare functionality) to be a reasonably accurate representation of the code.


Thursday, 11 August 2011

Tales of the Team Building Day

Now, we’ve already built a strong team that work well together so for us it shouldn’t really be called a “Team Building Day”. It should be called “See-your-team-mates-outside-the office-and-what-they’re-really-like Day”.  Needless to say, we all became closer and it was a worthwhile day to strengthen the team, but boy did we have fun as well. 


We decided to book a day of team challenges and tasks with Priory Events in a wonderful spot in the country in Nutfield, Surrey. Our first task was to keep our fingers and toes crossed the whole of the day and night before, wishing that the torrential rain would clear and that the sun would reign and cast its rays on the fields and rolling hills of Nutfield. Mission accomplished. It was a glorious day. 


We failed on the second task: finding the right place. However, we did ALL end up at the same incorrect spot so in the spirit of the day at least it was a team effort. 


We followed the smell of sizzling bacon and went in our cars on convoy to The Barn where we were divided into our teams and briefed on the day. Rest assured the smell we followed was bacon sandwiches and not a pig rubbing in tanning oil with its trotters and basking in the scorching sun. (I apologise to vegetarians now)

The first (real) task was an icebreaker in which we had to pass each member of the team through a loop of rope. Apparently we could do it in 1 second less than the number of people on the team. So for a team of 5, we should be able to do it in 4 seconds. We deal with complex problems every day, but this blew our minds. How on earth where we going to do it? I know you’re meant to encourage your team members in scenarios, but the first suggestion on our team (and I shall mention no names) was utterly ridiculous. There was no way that if we sat on each other’s shoulders and passed the rope over two people at a time that it would work, especially bearing in mind that we’re a bunch of people working in a technology company and certainly not gymnasts. I didn’t want anyone to die (although this almost happened again, read on to find out how…) and another minor worry was what our insurance would cover and wouldn’t cover if we accidently formed a noose with the rope and inadvertently strangled a staff member. As we’re now in the Magic Circle of Team Building Events, I can’t share with you how we did it but with the whole team working together we managed to complete the task in 2 seconds less than the number of people. 


Then it was the Nuclear Reactor challenge. The aim of this activity was to place the highly sensitive core (plastic tube) inside the nuclear reactor (barrel). The core’s alarm was triggered if moved suddenly or tilted too far. The layout of the activity has an inner, & an outer square. And there are items the group can use to get the core into the nuclear reactor. 


Right, they told us all that information beforehand. What they didn’t tell us was that when you’re in the outer square, building the contraption to somehow deposit the core into the reactor in the inner square, you’re blindfolded. So, only two people were in the outer square at one time in the dark and the rest were guiding them. Now the lesson learnt here was that it is very hard to guide someone when no-one knows what the solution is. There were so many items to choose from yet we knew there was a simple solution. That was the most frustrating thing. That and the fact that most children succeed in this task but only a small percentage of adults do. The time was up and we were on our way to building Sputnik but the core still sat next to us. The simple solution incorporated two pieces of rope and an elastic band that has been tied to a jug. Most adults think that the elastic band and the jug have to be used as one. As soon as we were told, there was a Mexican Wave as everyone lifted their hands and smacked their forehead. 


A few slurps of tea and we were back out in the fields. This time we were building bridges. We all thought we build Bridges as our business, albeit migration Bridges, and if there’s any task we should be able to succeed in, this was it.  Turns out, it wasn’t so easy. I won’t go into the details of the task, but this really showed us that we had to decide on a plan of attack as a team and then if the plan was revised, it had to be communicated to the whole team. Something I know we do in the office, but in the field, literally, it all fell apart; as did Team 2’s bridge. Team 1 was slightly better but a little unsteady. Confidence knocked and worrying that if the floods came we wouldn’t even be able to build a bridge never mind an arc, we went back to the barn for lunch. 


There was sense of determination in the afternoon as we gathered for the brief on the next activity: The Satellite Challenge. Great I thought -we’d already built Sputnik in our previous task. We were in our two teams and armed with sat-navs and a list of waypoints and sent off into the Surrey countryside to find different clues and collect various items on the way including something beginning with K, which kept me thinking “K, K, K…” the whole of the task. I desperately wanted caterpillar, cone, clump-of-mud all to begin with K. Team 1 had a lovely stroll over the meandering hills and down country lanes finding the different clues. I’m sure at one point butterflies were dancing round us. It was a peaceful walk to walk off lunch and we chatted and laughed. The only moment we really sped up was when we discovered we’d walked onto the shooting range. It only felt like a slight twist in our Famous Five adventure and then we were back on track. Team 2’s, who had slightly different waypoints, trip was less like an Enid Blyton novel and more like something out of Lost. 

Treacherous terrain, nettles grabbing at their ankles, hiking up and down hills, mysterious bits of rope leading them to the clues… It was amazing that we all got to the same area at the same time, looking for the penultimate clue.  Both teams kept quiet about finding our clues as we walked surreptitiously back to the car park – the known end point. We could see Team 2 across the field and the turened to walk behind a dividing hedge. They were slightly ahead and so we seized the opportunity to gain some ground and so we started running back to the car park. But they spotted us as they emerged into the clearing and started running too. The race was on. Team Building? Screw them, we were getting in first. Sprinting over the fields, the Chariots of Fire music started only interrupted by shouting on at our team mates to run faster (I can only apologise, I was caught up in the moment). Team 1 won the task and gained a head start on the next task but it didn’t help us at all as Joe explains… 


The funniest part of my day was the transport up the hill section where we had two sets of huge ski-like paddles which had foot loops and handles. Each team had 5 members on the skis and we had to march our way up the slight hill. I found this hilarious due to the fact the Ajay on the other team was falling over every couple of seconds and the fact that me laughing was putting Fiona off. The more she shouted at me to stop laughing the harder I laughed. I ended up laughing for the whole duration of the task but of course we still won! Needless to say Ajay spent more time on the floor than he did on the skis.

Now, the finale task was the most adventurous. The stakes were great and the risks were high. We were the Pirates of Priory and we had to reclaim some treasure which was the other side of the large pond. Yep, it was the good ole raft building challenges where teams pull together the skills they have learnt from the day to build a raft and then fly their flag to the other side of the pond get the key and come back to a hero’s welcome as their team claps and woops them in so that they can run to the treasure chest and open the box. Soo, didn’t quite work that way for us. 


Both teams worked out a plan. We communicated ideas and bound the barrels and wood together to make a raft. I was chuffed when the instructor told us ours looked “structurally sound”. Turns out, it’s not the quantity of rope you use, it’s how tightly you tie it. We put our raft in the water and Ajay (who eventually realised he had put on a child’s lifejacket) and I were the nominated and willing members of Team 1 who followed the raft into the pondweed and sludgy waters. We were on the raft for about 4 seconds when it started to dismantle. Now, if a Team Building day doesn’t bond you to your team mates, untangling them from rope as they see their life flash before their eyes will do. So moral, of the story – bond with your team mates but don’t bond them to the raft. 


Meanwhile, the other team had put their raft into the water. Fiona, our Product Delivery Manager for training, showed a different side by firmly telling our apprentice Joe not to be a wimp and get his trainers wet.  Alex and Derek had jumped in and mounted their upside down raft. It seemed to work but not as buoyant as one might expect a raft to be.  So instead of a dash to the key, Alex and Derek punted over to other side at such a pace, their team member’s sitting on the bank almost forgot about them. Team 1 built an “emergency raft” (no emergency biscuits available – The Apprentice fans will get this) with the help of the instructor which was finished just as the other team came back to “shore” and opened up the treasure chest. All that hard work for nothing; I took the raft out for a spin anyway. 


A couple of people wet, a few burnt and all smiling. It was a brilliant day and although not a model team building day, we definitely grew closer as a team.

Thursday, 4 August 2011

The Journey Continues – Developing a Work Process

We needed to re-structure our website and make some drastic changes. Taking on the challenge, Joe, our webmaster and apprentice, worked with the rest of the team and learnt a lot on the way.... 

After spending the last two weeks working on transforming our website’s overall look as well as improving the descriptions of the products and services that we deliver, I have learnt rather a lot in a short amount of time about working with CSS and ASP. For example, making classes in the CSS to change the way images are being shown and where they are positioned as well as how text is being displayed. 

I have been working alongside Todd, our software engineer and Catherine, who’s responsible for marketing, to bring the new look of the website and the new content together. My knowledge for Dreamweaver has increased vastly in this short period of time as I have had to do things that I had never done before, from things that I have learnt from starting to learn programming I have been able to complete a lot of the processes that I have needed to do a lot quicker. I am now able to look at a web page in code form and know exactly what lines of code are doing certain things. I now understand how our database is connected to the website and how it deals with queries and what it is doing to return the correct results.

I spent the first 3 days constantly asking questions “How do I do this?” “How do I do that?” I’m not sure how I didn’t drive anyone crazy! After listening carefully and a bit of trial and error I picked up on where I was making my mistakes such as in CSS forgetting to put a semi colon at the end of a line and then wondering why the new class I had created was doing absolutely nothing! These small mistakes have helped me a great deal and have made me create a mental process to go through every time I need to make a new class.

There are valuable lessons like this which have made working on the website a massive part of my journey to learning how to program. I have been shown that there is a logical answer to everything, and that if I spend a bit of time and put in the effort the answer is not always as far away as I once thought.

Friday 22nd July was an interesting day. This was the day the website went live with all the new changes that had been made. Meetings were had to discuss what was left to be done and who was going to do it. I am lucky enough to have the role of implementing all of the work everyone else is doing such as writing the content. This means that I don’t have to sit there copy writing, which I don’t particularly like doing.

Some problems that we came across were simply due to different browsers not liking our changes which of course is always a pain when you have made a change that works perfectly in one browser then you test it in another and it comes out completely different. Todd had this with one of the changes he was making that even in the same browser but on a different machine he had different results! A nightmare to figure out but as always, he found the solution.
When the pressure to get something done is there the day always seems to fly and Friday was no exception to this. Before I knew it, the end of the day was closing in and everyone was concentrating hard trying to get their last bits of work done ready for the website to go live.

I had spent the last two weeks learning ASP and CSS almost non-stop while developing the website into its new state. The difference in my knowledge of ASP and CSS from the start of the two weeks to the end of it is unreal. One of the main things I have learnt from these couple of weeks has been not to ask every time that I come across something I don’t know, spend some time and work it out for myself because I actually know more than I sometimes think (not always though!)The answers can be found rather quickly if I think about what I am trying to find out. I have surprised myself with the amount that I have been able to get done in this short amount of time as some of the changes that have been made to the website are huge. 

I believe that this has been a great achievement for us and I know for a fact it wouldn’t have been achieved if the team didn’t work so well together and each and every one of us was dedicated to getting the job done. A big thanks from me to the team!

Our website changes are all live and you can find out more about our products and services here: www.objektum-solutions.com 

Thursday, 21 July 2011

The Start of a Programmer’s Journey

Joe Gates has kick started his software career with us at Objektum Solutions and in this post he tells us how it all began…

I first came to Objektum Solutions with next to no knowledge of software or programming. I spent the last year working for a small web design and development company building different type of websites for clients. I moved to Objektum Solutions with the intent to learn and further develop my skills in web design and development.

This took a huge turn when I spent the first week at Objektum Solutions surrounded by programmers and software engineers.

My interest for programming started from there. I was amazed with everything that they were talking about even though I had almost no idea what they were on about! I had a conversation with Derek, our Technical Director, about what I was going to do over the coming months and I mentioned that I was very interested in learning a programming language and would love to get involved with it. He had no hesitation in giving me his personal books and said where to start. Since then I have been continuing with the web design and development but also learning Visual Basic.Net. So far in my first month I have learnt how to make small but functional programs such as a program that simply adds numbers together, to what I learnt today was my first recursive program. I was given the task of creating a program which would work out and give the result of the factorials of a number.

Derek then gave me a short but very beneficial lesson on numeral systems, teaching me the basics of how binary and hexadecimal systems work. Derek and I believe that knowing how these systems work is a fundamental part of my learning and knowing how to use them will be extremely beneficial later on in my journey of learning how to program.

Friday, 8 July 2011

Obsolete Programming Languages

Fiona provides us with another insightful post on programming and where we go next once a language has become non-existent....



With technology changing and advancing so rapidly, the programming languages which sit behind the gadgets we love are also evolving and changing. Languages often become out-dated and begin to cover less and less of technology’s needs, for example the widespread use of the web has led to the influx of new web languages which have differing features than the languages developed in the 70s through the 90s. So what is the lifespan of a programming language? When does a programming language become obsolete? And also where do we go next once a language has become non-existent?


Currently, it seems that Pascal, Turbo Pascal and VB6 have been completely written off as redundant. The languages which could presently be described as in decline or progressing towards another language include C, C++, Perl and Delphi and perhaps even Java maybe losing pace to Ruby. So why when languages are in decline do we still find developers vigorously maintaining and coding using the same languages? Well a manual software migration process is costly and time-consuming to say the least. In fact it is the laborious and repetitive task of rewriting lines of code which frustrates developers and prevents them from programming in the language they truly desire. 


So let’s explore the likely advantages of an automated model driven approach to language to language software migration. Aside from the previously mentioned cost and time involved in a full manual migration there are often other issues and failings with this type of process. The scope of the project is difficult to contain, new requirements often present themselves replacing existing requirements, and eventually the new system differs from the existing legacy system. An automated approach enforces rules and consistency which will preserve the quality of the code.

However, a move to a model-driven development environment is an effective alternative to this process. Using this environment will result in faster software migration which may well show which languages are actually redundant and lead to future obsolescence of languages at a much faster rate. Perhaps, this will radically change the way we view programming languages as they become more progressive and adaptable. Will we begin to see the days of teams of programmers battling with boundless lines of code as an ancient practice? Watch this space…