Recently the discussion of a newly published book caught my attention. The book investigated some of the ramifications of the financial crisis of 2007-2008. Specifically, it investigated how a bank received government support. This was done in the form of the government buying a lot of controlling shares in the bank, and also installing a CEO. This CEO was a politician.
In short, the story goes that initially he did a good job, by carefully controlling the bank’s spendings and nursing the bank back to health. However, as time went on, the bank was ready to grow again, and invest in new projects. This became a problem, partly because of the government as a larger shareholder, and partly because of the CEO being a politician. They were reluctant to take risks, which resulted in various missed opportunities. Ironically enough it also meant that the government could have cashed in their shares at an opportune moment, and they would have had their full investment back, and even a profit. But because the government was reluctant to do so at the time, it is unlikely that they will get another opportunity soon, as the current Corona-crisis made the shares drop significantly, and the government would be at a huge loss again.
This in turn led to an internal struggle between the CEO and other members of the board, who wanted ‘real’ bankers, more willing to take risks, and expand on opportunities. Eventually it led to the ousting of the CEO.
What struck me with this story was that I recognize these different management styles in software as well. I’d like to name “Delphi” as a key word here. Back in my days at university, I once did an internship with two other students, at a small company. As a result, Delphi has been on my resume for ages, and I ended up doing projects at various different Delphi-shops. This caused me to realize at some point that you should not put skills on your resume that you don’t want to use.
Delphi is just an example I’m giving here, because I have first-hand experience with this situation. There are various other, similar situations though. But what is the issue with Delphi? Well, for that, we have to go back to the days of MS-DOS. A company by the name of Borland offered various development tools. Turbo Pascal was one of them, and it was very popular with hobbyists (and also demosceners). It had a very nice IDE for the time, which allowed you to build and debug from the same environment. Its compile-speed was revolutionary. And in those days, that mattered. Computers were not very fast, and it could take minutes to build even a very simple program, before you could run, test and debug it.
Turbo Pascal was designed to make building and linking as fast and efficient as possible (see also here). Today you may be used to just hitting “build and run in debugger” in your IDE, because it just takes a few seconds, and it’s an easy to way see if your new addition/fix will compile and work as expected. But in those days, that was not an option in most environments. Turbo Pascal was one of the first environments that made this feasible. It led to an entirely different way of developing. From meticulously preparing and writing your code to avoid any errors, the compiler became a tool to check for errors.
When the move was made to from MS-DOS to Windows, in the 90s, a new generation of Turbo Pascal was developed by Borland. This version of Turbo Pascal was called Delphi. Windows was an entirely different beast from MS-DOS though. DOS itself was written in assembly, and interacting with DOS or the BIOS required low-level programming (API calls were done via interrupts). This, combined with the fact that machines in the early days of DOS were limited in terms of CPU and memory, meant that quite a lot of assembly code was used. Windows however was written in a combination of assembly and C, and its APIs had a C interface.
As a result, not everyone who used Turbo Pascal for DOS, would automatically move to Delphi. Many developers, especially the professional ones, would use C/C++. And for the less experienced developers, there now was a big competitor in the form of Visual Basic. Where Delphi was supposed to promote its IDE and its RAD development as key selling points, Visual Basic now offered similar functionality for fast application development, but combined it with a BASIC dialect, which was easier to use than Pascal, for less experienced developers.
This meant that Delphi quickly became somewhat of a niche product. It was mainly used by semi-professionals. People who couldn’t or wouldn’t make the switch to C/C++, but who were too advanced to be using something like Visual Basic. The interesting thing is that even though during my internship in the early 2000s, I already felt that Delphi was a niche product, on its way out, it still survives to this day.
Delphi as a product has changed hands a few times. Borland no longer exists. Today, a company by the name of Embarcadero maintains Delphi and various other products originating from Borland, and they still aim to release a new major version every year.
While I don’t want to take away from their efforts (Delphi is a good product for what it is: a Pascal-based programming environment for Windows and other platforms), fact of the matter is that Embarcadero is a relatively small company, and they are basically the only ones aiming for Pascal solutions. Compare that to the C/C++ world, where there are various different vendors of compilers and other tools, and most major operating systems and many major applications are actually developed with this language and these tools. The result is that interfacing your code with an OS or third-party libraries, devices, services and whatnot is generally trivial and well-supported in C/C++, while you are generally on your own in Delphi.
And that’s just comparing Delphi with C/C++. Modern languages have since arrived, most notably C#, and these modern languages make development easier and faster than Delphi with its Pascal underpinnings. Which is not entirely a coincidence, given that Anders Hejlsberg, the original developer of Turbo Pascal and the lead architect of Delphi, left Borland for Microsoft in 1996, and became the lead architect of C#.
Back to the point
As I said, the use of Delphi can generally be traced back to semi-professional developers who started using Turbo Pascal in DOS. For the small company of my internship that was certainly the case. Clearly, being dependent on Delphi is quite a risk as a business. Firstly because there is only one supplier of your development tools. And development tools need maintenance. It has always been common for Delphi (and other development tools) to require updates when new versions of Windows were released. Since development tools tend to interact with the OS at a relatively low level, to make debugging and profiling code possible, they also tend to be more vulnerable to small changes in the OS than regular applications. So if Embarcadero cannot deliver an update in time, or even at all, you may find yourself in the situation that your application can not be made to work on the latest version of Windows.
Another risk stems from the fact that Delphi/Pascal is such a niche language. Not many developers will know the language. Most developers today will know C#, Java, C/C++. They can find plenty of jobs with the skills they already have, so they are not likely to want to learn Delphi just to work for you. The developers that remain, are generally older, more experienced developers, and their skills are a scarce resource which will be in demand, so they will be more expensive to hire.
This particular company was so small, that it was not realistic to expect them to migrate their codebase to another language. The migration itself would be too risky and have too much of an impact. With the amount of development resources they have, it would take years to migrate the codebase (even so, I would still recommend to develop new things in C/C++ or C# modules, which integrate into the existing codebase, and whenever there is time, also convert relevant existing code to such C/C++ or C# modules so that eventually a Delphi-free version of the application may be within reach).
However, over time I also worked at other companies that mainly used Delphi. And I’ve come to see Delphi as a red flag. The pattern always appeared to be that just a few semi-professionals with a Turbo Pascal background developed some core technology that the company was built on, and moving to Delphi was the logical/only next step.
Some of these companies ‘accidentally’ grew to considerable size (think 100+ employees), yet they never shook their Delphi roots, even though in this case the risk-factor of developer or other resources would not apply. All the other risks do, of course. So it should be quite obvious that action is required to get away from Delphi as quickly as possible.
Politician or entrepreneur?
That brings me to the original question. Because it seems that even though these companies have grown over time, their semi-professionalism from their early Turbo Pascal/Delphi days remains, and is locked into their company culture.
So the people who should be calling the shots, don’t want to take any risks, and just want to try and please everyone. The easiest way of doing that is to retain the current status quo. And that sounds an awful lot like a politician. Especially if you factor in that these people are semi-professionals, not true professionals. They may not actually have a proper grasp of the technology their company works with. They merely work based on opinions and second-hand information. They are reactive, not proactive.
Ironically it tends to perpetuate itself, because when that is the company culture, the people they tend to hire, will also be the same type of semi-professionals (less skilled developers, project managers without a technical background etc). Should they ‘accidentally’ hire a true professional/entrepreneur, then this person is not likely to function well in this environment. Those people would want to improve the company, update the culture, and be all they can be. But that may rub too many people the wrong way.
With a true entrepreneur it’s much easier to explain risks and possibilities, and plot a path to a better future. They will be more likely to try new things, and understand that not every idea may lead to success, so they may be more forgiving for experimentation as well (I don’t want to use the world ‘failure’ here, because I think taking risks should not be done blindly. You should experiment and monitor, and try to determine as early as possible whether an idea will be a success or not, so that you minimize the cost of failed ideas).
I think it’s the difference between looking at the past, and trying to hold on to what you’ve got, versus looking to the future and trying to gauge what you can do better, using creativity and innovation. A politician may be good in times of crisis, to try and minimize losses. But they will never bring a company to new heights.
And my experience in such companies is that they still use outdated/archaic tools, and tend to have very a very outdated software portfolio. Still selling products based on source code that hasn’t had any proper maintenance in over 10 years. Constantly running into issues like moving to Windows 10 or moving to 64-bit, which is not even an issue in the first place for other organizations, because they had already updated their tools and codebase before this ever became an issue (for example, C# is mostly architecture-agnostic, so most C# code will compile just fine for 32-bit and 64-bit, x86 or ARM. And since the .NET framework is part of Windows itself, your C# code will generally work fine out-of-the-box on a new version of Windows).
Being reactive only is a recipe for a technical debt disaster. I have experienced that they would not do ANY maintenance on their codebase whatsoever, outside of their projects. So there was no development or maintenance on their projects, unless they had a paying customer who specifically wanted a solution. Which also meant that the customer had to pay for all maintenance. This was an approach that obviously was not sustainable, since you could not charge the customers for what it would cost to do proper maintenance and solve all the technical debt. It would make your product way too expensive. The company actually wanted to have competitive pricing of course, even trying to undercut competitors. And project managers would also want to keep things as cheap as possible, so the situation only got worse over time.
I think Microsoft shows a very decent strategy for product development with Windows. Or at least, they did in the past 20+ years. For example, they made sure that Windows XP was a stable version. They could then move to a more experimental Windows, in the form of Vista, where they could address technical debt, and also add new functionality (such as Media Foundation and DirectX 10). Vista may not have been a huge success, but there was always XP for customers to fall back on. The same pattern repeated with Windows 7 and Windows 8-10. Windows 7 continued what Vista started, but made it stable and reliable for years to come. This again gave Microsoft the freedom to experiment with new things (touch interfaces, integrating with embedded devices, phones, tablets etc, and the Universal Windows Platform). Windows 8 and 8.1 were again not that successful, but Windows 10 is again a stable version of this technology.
So in general, you want to create a stable version of your current platform, for your customers to fall back on. The more stable you make this version, the more freedom you have to experiment with new and innovative ideas, and get rid of your technical debt.
I just mentioned Delphi as an obvious red flag that I encountered over the years, but I’m sure there are plenty of other red flags. I suppose Visual Basic would be another one. Please share your experiences in the comments.