What was the issue?
A senior software developer in an airline company has been asked to design an application he is not used to working with. This developer is a long time COBOL programmer. He runs an IBM AS/400 I5, and he’s a master of it. As far as he is concerned, the AS/400 is the best bit of kit in the world. Totally tried and tested; he knows it inside out; knows it’s not going to fall over or let him down.
The airline needs to modernise. Legacy skills are getting harder to find, and the company has to move to a modern platform to stay competitive. The ultimate business issue is how does this developer get used to a new software environment?
What benefits were delivered?
We don’t start off on the computer. We start off at a table with a piece of paper. I want to start him with the basic architecture of the application. This is a point that it is absolutely crucial for managers and executives to understand. Software architecture is not just some insubstantial technical concept: it has absolutely concrete and long term financial implications for the company. We’ll come back to this later.
Together we drew out the general structure of the application. We put a box for the AS400 on one side of the sheet, and one for the SQL server on the other. And in between we sketch the layers of the application that we’re going to be writing.
How were they delivered?
Agile design strategies: The adaptor pattern
SQL was going to be changing, and the architecture had to take this into account. So we build the layers around the /adaptor pattern/. [Link: Adaptor pattern: Think of adaptors just like the travel adaptor you bring with your laptop on holiday. It plugs in between the laptop and the local power supply and allows you to use the laptop without having to modify the laptop itself (i.e. without having to change its plug). Adaptors provide flexibility.]
Adaptors provide flexibility. The adaptor knows the schema for the data at the AS400 end and the SQL end, and if the application later has to be modified, the modifications can be confined to the adaptors, not the actual engine of the application. It allows you to make an application with a long operation future, despite the fact that, for example, SQL might change. This is a basic principle of agile design.
Applied learning in action
This guy was totally on board with the architecture. He completely got what we were trying to do with the layers, and he completely understood the benefits of the architecture.
So then what we had was a diagram of the overall structure of the application. Our next step was to turn each of the layers into a project in Visual Studio and start to write code. We’d made a start on that before it was time to stop for lunch.
<diagram> informative caption and description
Introducing object-oriented programming
In the afternoon we wrote some real code, and put in place the interfaces and methods that the application would need. The DB2 adaptor needed a Method Test. When we sent it the instruction “get batch data” we would tell it the batch number and it would bring back the data in a very flat format – the batch is a collection of rows, and each row is an invoice. We needed to represent these as batch objects containing a list of invoices where each invoice contains a list of invoice lines. I explained to him that this was object-oriented programming. This was a significant learning point for him, since his knowledge-base is in COBOL. But he’s a very bright guy: he got the idea immediately.
We used a class to build a data structure. Because we didn’t have all the sample data, and now wasn’t the time to address this problem, I was able to show him how to use a /mock method/. A mock method is a temporary placeholder which indicates that we don’t want to deal with this problem right now, and that it can wait for later, or for another team to do it. This is classic agile design, building modularity into the application design. Although he doesn’t have much object-oriented experience he could see this was a good way to work.
What were the results?
Applied learning: A day’s work
Achievements in one day:
- delivered an architectural template that can be used for years
- provided a working methodology for the current problem
- reduced the risk of the project going off the rails later on
- passed on best practice, and provided a lead for further investigation of mock methods and adaptors, and the idea of object-oriented coding
This was a classic example of applied learning.
In this case the guy I was working with was particularly good. As he said himself, if the task had been in COBOL he could have done it all himself. But any developer outside their comfort zone needs the scaffolding of applied learning to break through a barrier. The structured approach that Storm uses will help anyone.