Welcome to the new year! And welcome to my first T-SQL Tuesday contribution of 2024. Reitse Eskens is our host, and he invites us to think back of a project that failed or was abandoned, and reflect on lessons learned.

I love learning from mistakes. I often say that it’s important to learn from mistakes, so that we can make exciting fresh new mistakes the next time. That is, after all, way more exciting than constantly repeating the same mistakes over and over again.

In this blog, I will reflect on not one but two abandoned projects. In one case, I joined the team that was formed to build on the ashes of the failure. In the second case, the project was fully and completely mine.

The New Loans System

This was either my first or my second “real” job, depending on how you look at it. You see, my first “job” was one and a half years of mandatory community service, as a replacement for military service that I had refused based on conscientious objections. The work I did during that period was all IT related, so in a sense, it was simultaneously not a real job and my first IT job. You can make up your own mind on whether or not it counts.

But once that period was over, I found a job working for a large bank, in a team responsible for maintenance and incremental development for the central loans system, running on an IBM mainframe. The code was written in a mixture of PL/1 and Assembler code. Most of the code was over 15 years old, and maintenance during the last years had been minimal. Why? Because, for several years, a large project team had been working on the New Loans System.

Yes. Several years.

Now, those were the days of the waterfall model, so long project plannings were not unheard of. But multiple years was insane even by the standard of those days. And then, one day, after investing insane amounts of money in the coveted New Loans System that would make Everything Better™, a daring manager took it upon himself to write the memo that ultimately resulted in the death of the New Loans System, the dismantling of the product team, and the formation of a new project team, tasked with catching up on maintenance of the old loans system, and perhaps over time gradually implementing improvements.

So, what exactly had gone wrong with the New Loans System project. How could it have failed in such a spectacular way that the only viable option was to simply abandon it and start from scratch?

Based on what people told me back then, the biggest issue seemed to have been a project manager who listened to too many stakeholders. Due to internals of how the bank itself was organized, there were many stakeholders. Each with their own wants and needs. And each of them knew to contact the project manager, when they had a new wish, or when they feared an existing wish would not be implemented in the New Loans System. And the project manager would then nod, agree, and tell his team to change the design, to adapt to this new wish. Over and over again. Even when it meant throwing out the work already done in the weeks or months past.

The project manager of the new team made sure to learn from this failure. A new team was formed, elsewhere, not within the IT department. That team was responsible for collecting all wishes and demands from stakeholders, reconciling them, and then communicating the consolidated requested functionality to our team. The spokesperson of that team was not officially part of our team, but we were in frequent contact and he attended many of our team meetings. He was the only contact outside of the project team that team members were supposed to talk to. All stakeholders had to go through his team, and only the vetted results of their internal discussion reached us.

We had a year planning. Several releases were scheduled for each year. A delay of a release was only accepted if a last-minute critical bug was found in the release. The four (I think) weeks before each release date were a freeze period, reserved for testing and bug fixing. No new functionality was allowed during that period. Even if an error in the specifications was discovered during testing, we would not change it, unless it would break the system.

In short, you could say that our manager had invented and implemented agile two decades before the world started agile. All from analyzing the root causes of the failure of the New Loan System project.

The code generator

From 2004 until 2013, I worked on an idea, a dream that another man and I shared. A CASE tool for the NIAM methodology of information analysis, plus our own methodology for process design. Now, NIAM has, as far as I know, never been widely published and never found much adaptation outside of the Dutch language area. A short description of NIAM would be a notation for data models that closely resembles ORM (Object-role modeling). No wonder, since the founders of ORM and NIAM worked together on the basics for several years. The main difference between the two is that NIAM adds a formal method to perform the information analysis that, when followed to the letter, virtually guarantees that the results completely and accurately reflect answers given by domain experts, using methods that are designed to overcome issues caused by jargon differences or other misunderstandings.

We wanted to build a CASE tool that would not only store the results of this information analysis. We also wanted to add a method for process analysis, based on the same principles as NIAM to prevent communication errors. We also wanted to add versioning (something missing from almost all CASE tools in those days), complex relationships between versions, and a code generator that could not only produce the database schema and all code to implement the data model and process model, but that could also produce change scripts to bring the database schema from one version of the model to another, without data loss. And that no data loss guarantee went beyond just keeping the existing data in a table. Our CASE tool recognized when, for instance, a column was moved from one table to another, when a table was split into multiple new tables, or when multiple tables were merged into one. In all those cases, the change script would contain everything needed to preserve the data, or to abort without error loss if the preserved data would violate a new business rule.

That other man and I had founded our own company, for this dream. The division of labor was clear. We both recognized that I was the more technical of us two, and he was better at sales. So I sat in my attic and developed the CASE tool. While he took on contract work to fund the development. And once the CASE tool was in a sufficiently advanced stage that we could start to use it, or perhaps even think about selling it, he would take the lead in marketing our ideas to the world.

Even though we ultimately failed, I still consider it a success story. We started with only the conviction that what we wanted should be possible. But also that there would be countless technical hurdles to overcome. We overcame all of them. We built a system that did all it needed to do, at a minimum viable product level of supported functionality. And then gradually added more functionality. And we always passed what I call the litmus test of code generators: can it generate itself? Our code generator did. No manual code at all was used to implement build 2 of the system. It was generated by build 1. And next to several small tests I always ran, my main test was to let build 2 generate both the script to create build 2 from scratch, as well as the change script to migrate from build 1 to build 2. I would then compare both to the corresponding scripts as generated by build 1. I kept creating more builds this way, step by step, over time. The system always generated itself, and always remained its own largest and most complex test case.

Over time, I had to solve myriads of problems, from small to huge, from simple to extremely challenging. I learned a lot. Every problem solved was a lesson learned. But none of these are relevant for this blog post, because they were lessons learned from an ongoing project, not from an abandoned project.

The last build I used was build 23, which, if I recall correctly, completed the 0.5 version. It had full support for all elements of the information model as well as all elements for the process model, all of them with correct implementation in the generated code. It also supported multiple versions, but with a basic model for versioning, rather than the complex versioning we wanted to implement (and that was planned for versions 0.6 and 0.7). And it also, and this was perhaps the biggest omission, totally lacked anything even resembling a graphical user interface. All of my own work was done in terms of the NIAM information model, and our proprietary process model. But getting the results in the database was a complex system of putting analysis results in documents with strict layout requirements, and then running VBA macros to extract SQL statements to store the results. If I wanted to review the details of the data model, I ran SQL queries on the database itself. If I wanted to visualize it, I manually drew the model on a sheet of paper. So in short, there simply was nothing even resembling a usable human interface. Recognizing our own weaknesses and limitations, my business partner and I had decided to postpone the user interface to version 0.8, hoping that by then we would perhaps have enough budget to hire people with the required skills.

And yet, despite calling it a success story, this is now clearly an abandoned project. Build 23 stems from April 2013. Build 24 was never completed. So, what went wrong?

• Attempts to generate interest for our CASE tool had not had any success yet. We had had a few chances to showcase our work. But because of the lack of a user interface, all that the people holding the money saw was a bunch of tools that nobody in their right man would work with. Our presentations might have appealed to technical people, who might perhaps have been able to look past that. But those were not the decision makers and budget holders that we had to convince.
  From this I learned the sad but correct lesson that it is easier to sell an idea based on a simulated prototype that looks cool, than based on a fully functioning system that does not have an appealing front end.
• Attempts by my business partner to attract paid work that we could use our CASE tool for had thus far failed. The tool was, at that time, incomplete but sufficiently functional that it could be used. What functionality was lacking could be worked around. Well, except for that front end of course. But I we had found a project, then my business partner and I could have used our own crappy tools to work on it and deliver code, faster and better than was possible with conventional methods in those days.
  I wish I could say that I have learned from this as well. But that is not really the case. Sure, I could say that I have learned not to trust someone else to do sales for me. But I know all too well that I myself suck totally at sales. I would definitely not have done better.
• The contract that my business partner worked in order to fund our company had ended at the start of 2013. He had not told me this, because he was convinced that he would find something new in time. I had not noticed this, because I was used to payments being several months late. (There were multiple intermediaries between end client and us, each adding their own payment delay). By the time my business partner finally had to come clean and admit that we were without income, there was insufficient time left for me to try to find paid work to help save the company. Not long after my business partner told me about the situation, we had to make the choice to effectively stop the company. (It technically still exists, but has effectively been a dead company for the past ten years).
  From this I learned the importance of communication. If my business partner had told me about the situation sooner, I might have had a chance to help, now there was not enough time. And if I had not made the same mistake my business partner had made, if I had not tried to hide the situation from my wife once the situation became clear, I would have lived through one less severe marital crisis.
• And finally, there is the matter of timing. When we started our project, many of our ideas were groundbreaking and unique. But as time passed, the world developed. Database support in Visual Studio (originally called “Data Dude”) and generation of BACPAC files meant that our support for generating code to take a database from one version to the next was no longer unique. We still did a better job, but “does it better than Microsoft in some specific edge cases” is a much harder sell than “no other tool does this”. Developments in software design methods introduced other ways to reduce the risk of miscommunication between end users and domain experts and the IT staff. New software development tools reduced the cost of writing code, and hence the benefit of using code generators. And with the latest trends in AI, this will certainly only accelerate.
  I still believe that there are cases where our system could add value. But they will be harder and harder to find and to use as a selling point in a presentation. So realistically, if we were unable to raise customer interest then, we will certainly not raise any serious interest now.
  The lesson learned here is simply that the world is in constant motion. With hindsight, I now wonder whether my business partner should not have decided to pull the plug and stop investing several years sooner already, when there were already market developments that started to reduce the added value we could offer. But we did not look, we never consciously reviewed our ideas in a changing market, and just kept going. Until we were stopped by a wall.

Conclusion

So there you have it. Two abandoned projects. One that was failed by a project manager who budged to every whim of every stakeholder, and then was fixed by another project manager, who sort of invented agile long before agile was invented. And one that technically was a project, but never made it to market and never would have made it to market even if we had not stopped, simply because we were never any good at showing our added value, and then that added value also diminished over time as the world moved on.

Thanks, Reitse, for making me think back of those interesting years from now a long time ago!