A Life of Software Development: C++, Software Artefacts and Project Management
1996-2021
C++ and RDBMSs
Once I joined the new organisation, I had to quickly adapt to the use of C++ as my main development language. I had already started using it at the university and found it to be a good, strongly typed object-oriented language.
I found some missing classes within the Microsoft Foundation Classes (MFC) library and developed extensions to these classes to make them more usable. I did some optimisation in existing codes and developed some algorithms in simulation and some heuristic methods as well. The existing code for the Logistics application I was involved in was developed in C and had mostly been converted to C++ before I joined the team. However, the data layer was using flat files, very inconveniently. I had used the emerging relational database technology previously, but had not really programmed with them. Two team members started converting the application to use relational databases. We also had at least one SQL expert who could optimise queries so that data retrieval could be done efficiently.
As for managing the data that was to be processed, a Powerbuilder application was developed. Powerbuilder was an integrated development environment produced by Sybase. It offered native interfaces to several Relational Database Management Systems (RDBMS) and Sybase was one of the popular relational databases available.1
On the C++ side, we still relied on a simplistic data layer that would create an object map based on queries on the SQL database and the full data set would be stored in memory. This could create some problems occasionally but we did not see memory as a significant problem.
Software Artefacts
Since the team was primarily tasked to support the community with the tools rather than develop the actual teams and there was more pressure to use contractors to build the tools, there was a shift of focus to managing these external teams. In order to be able to manage these contracts properly, we needed to produce software artefacts. One of the more important areas to cover was Requirements Management. Most of the problems after the delivery of an application was about poorly defined requirements that resulted in the application being unusable or not fit for purpose. Extra time spent for this phase of development would minimize the loss of time in the later phases and especially after delivery.
It was also important to properly document the design selected to implement the application. A standard approach to documenting design was the Unified Modelling Language (UML).2
UML had standardised the various documentation approaches by utilising methods from three giants of the field and giving the new method an owner (Rational, which was later bought by IBM). It had many different diagrams and notations to capture different aspects of software. I’ve included a commonly used Class Diagram below.
I had started the development of a new simulation application, but given all the other work that I had to do and the fact that none of the other team members were available, I had to rely on additional manpower coming from outside. We had a couple of very capable developers who also used UML-based documentation regularly.3
We documented everything in the right level of detail, so documentation was done as long as it supported the development process. Since we were effectively designing a simulation language to facilitate the development of a variety of models, we needed some work to be done in parsing and used railroad diagrams (not included in UML) to document the syntax of the language.
In general the results of these experimental developments were positive, but constituted small improvements to existing tools. Of course the Agile Manifesto was not declared until 2002 and Agile methods were not mature, thus formal development was done based on fixed requirements to be fully implemented.
Project Management
When I assembled together small teams to do the development, I also had to manage the schedule, budget and other aspects of these developments. Thus I stepped into a Project Manager role, not formally but de facto.
Of course I had the Project Management (PM) background due to my education in Industrial Engineering. Apart from getting formal education about it, I had developed a Critical Path Method (CPM) based project management application in the early days of my development experience, although it had proven to be difficult commercially.
Our organisation used Microsoft Project as the main development tool and enhanced with Enterprise PM functions. I had used it occasionally, so it was not difficult to use. However, when these tools were introduced in the organisation, there was no formal PM method adopted yet. This would come later, towards 2006 with the introduction of PRINCE 2 as the formal PM methodology to be used.
These small projects consisted of bringing in small development teams and work on prototypes, albeit with maximal software documentation.
After these initial forays into the PM area, I was assigned to manage larger projects, with much greater economic scope and much stricter formal requirements. This increased the necessity to use formal documentation, in diverse formats and richer content.
I managed a project to update the Financial System used in one of the sub-organisations and got introduced to the Oracle ecosystem. Oracle E-Business Suite was one of the alternative financial systems Oracle had produced or acquired along the way and updating this complex commercial-off-the-shelf system was a quite complicated and meticulous process documented by Oracle in detail. This was a successful, short project and would pave the way for several Oracle-related updates n the future.
The culmination of my PM duties came up with the start of a major acquisition project to define the requirements for a Logistics system, award a contract to a development firm through an international competition and oversee the development and delivery of the system to the organisation. This was a multi-million Euro project that would take up to 10 years to complete and would require hundreds of people to complete.
The main contractor put together a multinational team together and started the work with teams programming in Java and C#. Organisational standards required lots of documentation to be delivered and they started delivering. However, as we got closer and closer to the Factory Acceptance Test, the developed software started failing formal tests. It turned out that a major development effort like this could not be carried out with a massive, fixed set of requirements that become obsolete even before it was delivered. It was also obvious that the contractor started falling behind and failing to manage the big team as failures started to accumulate.
At that time, the organisation did not endorse Agile methods and there was a lot of resistance to move away from the document-centric approach to enable delivery in phases. The Agile method relied on a set of requirements that could be prioritised and distributed to separate phases of delivery. Each cycle of delivery would be pre-planned with fixed dates and when development did not go as planned, requirements would be dropped or re-scheduled, rather than delaying the delivery. Development teams would decide on which features to include in which delivery cycle (usually called a Sprint) and on the prioritisation of features.
Nowadays almost all major developers use an Agile approach, but some use a combination of structured delivery and Agile, in order to make sure that some centralised development takes place.
In my latest organisation, I spent around 7 years with hands-on development, then around 10 years with managing small internal teams to do programming, then the next 8 years to manage large acquisition projects. In the later part of this last career phase, I did some hands-on programming as a hobby, to make sure I did not lose my skills. After I retired in 2021, I would go back to programming semi-seriously, catching up with the latest developments in mobile and desktop platforms.
Sybase was bought by SAP in 2010 and products were integrated into the SAP structure. Powerbuilder was converted to an Object-Oriented development environment and still exists today, mostly for developing or updating legacy systems.
A standard modelling approach developed by Rational Software, merging three separate methods, namely Grady Booch’s Booch method, James Rumbaugh’s Object Modelling Technique (OMT) and Ivar Jacobson’s Object-Oriented Software Engineering (OOSE) methods.
This was not always the case since some developers really hated to document the design with these tools.