Enterprise software is the hardest software to write. Period.

There is a perception that building enterprise software is easy.

I’ve worked for an aerospace company, I’ve worked on computer simulations and mathematical optimizations, I’ve built computer language parsers, written device drivers, etc. Without hesitation, I would say that working on enterprise software is the hardest.

Why? To examine this, we can divide software into four different types (these are rough categorizations, as software is hard to pin down):

1. Scientific and engineering software: This covers aerospace programming, process control systems in power plants and electrical grids, and engineering analysis to design bridges, buildings, and dams. I’m also throwing AI, robotics, 3D printing, and voice processing in here as well.
2. Packaged software: The most prominent example of packaged software is Microsoft’s Office suite. This category also includes graphic art programs such as Adobe Illustrator and Photoshop. It includes business software like QuickBooks and a myriad of other programs that are purchased in some manner by users.
3. Cloud software: This software works in a browser. Basically, we’re talking about HTTP requests that result in bundles of HTML, CSS, and Javascript being sent to the browser. The software is a combination of the Javascript on the browser and the back-end code that runs on the server.
4. Enterprise systems: Enterprise systems are software that are integrated into the operations of an organization. The most common ones handle general ledger, financials, payables, and receivables.

Why is enterprise so much harder than the other three?

There are three factors that greatly influence how difficult it is to develop software:

1. Control over features: Does the project team have the final say when it comes to features and changes? Do they have to consult with an outside constituency?
2. Generic or constant test data: How do you generate test data? Is there a lot of existing test data or do you have to try to construct it? If you have to construct it, how much coverage do you generate?
3. Change over time: Does the software have to change its logic over time, yet still preserve existing information? And are there changes during development?

Let’s examine each type of software with respect to these features.

Scientific and engineering software

When I wrote software for a radar imaging system, I could take some archived satellite data, run my software, and look at the results, continuing until it gave me seemingly correct answers. Then, I could process the image and check the fidelity.

It was totally repeatable and predictable.

Testing was also straightforward: I could grab any part of the satellite data and image it. Analyzing the image indicated how accuracy in antenna positioning improved the resolution of the image. This meant that there was a massive amount of data that I could use for testing.

In technical/engineering software, decisions on changes almost always rest with the project team, with very little input from external sources.

Finally, these kinds of software are also used for a single case at a time, for one particular situation. If it needs to be modified, a new model is produced.

All of this makes scientific/engineering systems less difficult than they might seem on the surface.

Packaged software

In the 1990s, I was an owner/partner of Paradigm Development Corporation, a contract-software house that did a lot of work for Microsoft, among other software companies. One project we had was to remove unused lines in the Microsoft Word code base, which was high entropy (aka a code base that has large technical debt).

You may be thinking, “But Microsoft Word works well.” That’s true. It’s stable and gets the job done without a massive amount of computer errors. So, how does a high-entropy code base result in a stable product?

Cloud software

Enterprise systems software

Summary