I’ve found that a small amount of mathematical rigor reduces the size of most complex code by a few orders of magnitude.
It has the effect of short circuiting the complexity of the problem, because it defines all the corner cases in a compact form.
Interface with sloppy spaghetti systems can usually be hidden away at the edges of the system. The main problem is that less experienced engineers invariably come in and say, “A ha! I have a special corner case that doesn’t fit the abstraction.” and then try to add copy paste methods, boundary violations, and so on.
As long as there’s someone that diligently guards against such things, it works out OK. Results vary wildly after those people leave.
HP printer drivers are a famous example of the sort of complexity reduction I’m talking about. They used to copy the entire source tree for each printer (font rasterizer, dithering algorithms, and all), then assign a full time team to maintain it.
Eventually they had many thousands of full time engineers maintaining the result, and print quality was still terrible across the product line.
The open source drivers reverse engineered the printers, and factored out as much common logic as possible. The printer specific code was then reduced to just implementing the wire protocol and device geometry stuff. At that point, they had better output than HP, with 1% the developer resources.
Someone at HP did the same thing internally, reimplemented all the drivers in a unified way, and was promptly promoted to the executive team.