4 ms·
I’m mid-30s, working for a finance megacorp and we have a few production codebases older than me. Some observations: * Sadly, as others have said, these are pr
by jl6 6y ago
I’m mid-30s, working for a finance megacorp and we have a few production codebases older than me. Some observations:
* Sadly, as others have said, these are proprietary internal systems and members of the public won’t ever be able to see them.
* Although the codebases have ancient lineage, the code doesn’t stay static and has been extended and patched over the years, and sometimes transplanted wholesale to a different technology using automated tools (e.g. mainframe to .NET, although that particular one was an unmitigated disaster for maintainability).
* Ancient code usually persists in production for reasons unrelated to its technical qualities, and usually in spite of them. For example, an insurance company managing a closed book of pensions has very few compelling reasons to change its technology because the product it supports doesn’t change, and regulatory changes can be handled by tweaks and auxiliary reporting systems.
* Having said that, ancient code was usually written with a great deal more discipline than modern code, and I believe this stems from the division of labor between Programmer and Analyst, which no longer exists. By having two people involved in every part of the system, you had all the benefits of rubber ducking, peer-review, documentation, and the simple act of talking to another human about what you are doing.
* Ancient systems tend to be very rigorously tested for functionality that directly supports business activity. Ancillary functionality such as management information reports, less so. These systems change infrequently enough that the major defects have all been flushed out and fixed, over the years. There is very little feature churn, which does wonders for stability.
* The code at the heart of these systems usually wasn’t designed with a modern threat model in terms of security. Security is often bolted-on by isolating these systems behind other systems, and they get a lot of mileage out of obscurity too.
* The code is often the least interesting thing about ancient systems anyway. Few are performing rocket science tasks - they are usually just doing batch data processing and green screens. More interesting is the ecosystem of infrastructure, interfaces, job schedules, copybooks and data models, resilience features, and documentation. These are the things that make the system really work. Lines of COBOL are usually unilluminating.
- est31 6y agoRegarding your point about ancient systems having higher quality, maybe there has been a selection effect? The systems that were crap might have been rewritten years ago before you even came to the company.
- Pamar 6y agoOr more probably the company using them folded...
- user5994461 6y agoThere's a very strong drive for quality. When you handle payments or trading systems, having 1% of transaction disappearing doesn't cut it. It's the environment around critical systems. When shit hits the fan, it's really bad and there's a feedback loop to developers/managers/companies. Software is ironed out over time. Bugs are removed and things are very stable in finance. Software that really doesn't work (and can't be fixed) might be killed or never see the light of day. The result of failure is too bad and too visible. It's way more than that. There's all sort of strange incentives. Like you don't get dinged for fixing a bug instead of making a new features (frequently there's no new features to make, it's largely maintenance work).
- Spivak 6y agoOf course but that’s kinda the point. If you have a 20 year old system still kicking odds are good that it lasted because it’s quality. If it wasn’t it would have been replaced ages ago.
- goatinaboat 6y agoHaving said that, ancient code was usually written with a great deal more discipline than modern code, and I believe this stems from the division of labor between Programmer and Analyst, which no longer exists. Shotgun compiling wasn’t a thing and programs were planned on paper (flowcharts) before any code was written. Modern day programmers scoff as they crank out another web app which will be thrown out and totally rewritten in the fashionable framework of the day in less than a year.
- Pamar 6y agoI am old enough to have started my career exactly in such an environment (COBOL in automotive industry). You are right, there was more discipline, and systems, no matter what size they were, were painstakingly described on paper first, then implemented (programmers had very little chance to come up with neat tricks), then tested. Infrastructure was very "primitive", but on the other hand you basically never had obscure bugs manifesting in your database, or your batch scheduler etc. On the other hand (I am talking of the late 80s) systems had already grown to a behemoth size, and unfortunately you could already find stuff that was messy and poorly documented. Take also in account that IT (at least in Europe) had a boom between 70s and 80s... but this also meant that lots of people started working in IT with almost no formal education and without any "craft experience": exactly the same mistakes and cul-de-sacs were independently made and discovered all over the place, and there was basically no way for developer X to know that someone else had already solved those, even if the other person was sitting across the street or two floors above.
- marmaduke 6y agoThat last point might be applicable to any software system.
- totemandtoken 6y agoThis comment (I think, from my limited experience) really does capture all the context around my question really well. Of course not all old code is immediately well-written by mere virtue of its survival - a lot of it is, as mentioned here and else where, sustained because of internal company politics or financial reasons, in flux and a living codebase, etc. But I am interested in the stuff that survives because of how well-written it is. To your point though, the context and ecosystem of these codebases is as important, if not more so, that the code itself. A lot of comments are pointing to the linux kernel which is a tour de force in and of itself, but also really interesting for the community/communities its inspired.