7 ms·

I often feel lost when reading such articles because they never seem to quite acknowledge how bad legacy systems can be. The following examples all originate fr

by moring 9y ago

I often feel lost when reading such articles because they never seem to quite acknowledge how bad legacy systems can be. The following examples all originate from the same project I have worked with in the past. Example 1: You cannot "favor consistent over new/better" because one of the main problems with the old code is that it is horribly inconsistent already. Example 2: You cannot "favor consistent over new/better" because the legacy style you would try to be consistent with is so bad that you cannot even understand tiny fragments of the code, let alone write new code in a consistent way. Example 3: The legacy system was built in a way that makes it impossible to store the code in any kind of VCS, so being consistent with that means breaking well-established best practices. Example 4: For some part of the system, nobody knew how to make the magic code generators produce code that is consistent with the legacy code (and if you try to write that code without the generators, you are in for a trip to hell). That said, the article helped a lot in that I now know the name for a problem I somewhat recognized but couldn't describe well.

hinkley 9y ago
The legacy system was built in a way that makes it impossible to store the code in any kind of VCS Come again?
- Terr_ 9y ago
  Maybe it's in something like Smalltalk?
  - floaterpig 9y ago
    Another alternative is one of the PICKs where the source code is (used to be perhaps) stored in the database, or I think COBOL on some systems didn't exactly lend itself to flat files from the little I saw (or at least the OS wasn't embracing CVS/SVN/Git in favour of some hugely expensive and utterly inferior product...).
    - Terr_ 9y ago
      Ah, right, or "business logic eval()ed from database text" systems.
      - jupp0r 9y ago
        Or, more commonly - stored procedures.
        Terr_ 9y ago
        Stored procedures are a little easier to handle provided your deployment system does a wipe/replace, similarly to overwriting scripts/executables. I was thinking of a grimmer scenario, where the system has an disquieting aspect of polymorphic, run-time code editing... central to its "flexible" production behavior. There are more things in heaven and earth than dreamt of in sane philosophy.
  - fiddlerwoaroof 9y ago
    Smalltalks (at least Pharo) have integrated version control
- titanomachy 9y ago
  It's not stored in text, or even in files at all. The program exists only in the form of holograms encoded into crystals which can only be altered by singing at a precise frequency.
  - marcosdumay 9y ago
    I've seen: - The program can only be compiled in a particular Eclipse environment, that is copied from one machine to the other. Every attempt to replicate the environment from a plain Eclipse installation fails. - Building the program depends on specific versions of system executables. Those versions are long outdated. - The program depends on specific and very complex system settings for building and running. Those are comparable in size to the source code. And I mostly do not work with legacy systems. EDIT: Oh, and there is the obligatory "90% of the executable source lives on the database" kind.
- Arbalest 9y ago
  Binary formats, such as ladder logic in control systems, as an example. Which also typically can only be edited by a first party program.
- adrianratnapala 9y ago
  VCS requires that projects build from source code that is more or less immutable except when humans really want to change it. But some projects mutate in machine-dependent ways by the build system. Bonus points when said data is binary. I've seen CMake caches and Eclipse project files go wrong this way. Another good one is where your development project is testable only against a real database, and the schema keeps changing. Even if you could revert the schema file, you can't revert the data.
- jrimbault 9y ago
  My experience: a small-ish size php application made originally by 2 autodidacts who didn't dig too far into programming and the tooling around programming (weirdly enough, I found some pretty advanced SQL in there, while it seems it didn't bother them to write the exact same request 7 times 5 lines apart from each other). There were/are files scattered all accross the filesystem with wild include statements both at the top of each scripts and in the execution logic. The scattering was/is so bad with mixed data files with logic files, dependencies (which were not registered as such, and were modified from their original source) thrown between original scripts. I've started versioning a year ago when I got there, and I only got to _good_ state last month, trimming and trimming. Just the fact that files were scattered accross the filesystem, while not constituing big enough clusters to warrant separate repositories, meant I had to make one large repo with weird ignore rules.
- emmelaich 9y ago
  Nothing is impossible of course because it is all bits. But perhaps they are using something like Oracle BI where you assemble some blob in a UI on Windows then upload to the server. You could commit the blob to VCS. Or maybe serialize it to XML (supported in some versions). But try and convince the DBAs doing development to do that commit. Good luck.
incompatible 9y ago
I get lost with all the Microsoft / data modelling terminology, it doesn't have much to do with software I've ever had anything to do with. What is all this "data-access layer" abstraction stuff about anyway?
- hinkley 9y ago
  Your architecture may say exactly all of the qualities of your data are but when it comes to transferring it into and out of a database some of the fidelity is lost. If you're trying to pull the data into a statically typed language (even one that isn't object based) there's an impedance mismatch and you almost have to trick your language into accepting the data. So you hide this indignity in something called an Object Relational Mapper, and the rest of your app just pretends like you have a database that gives you Objects. There are a million flavors of these with their own jargon but it's all the same stuff, and they are all within an order of magnitude of each other on the awfulness scale (which is why I'm not to enthusiastic every time someone comes up with essentially the same thing under a different name. Like, say, Protocol Buffers)
  - DonHopkins 9y ago
    Agreed, ORMs all suck because what they're trying to do is essentially sucky. But some are better at sucking than others by orders of magnitude! https://www.sqlalchemy.org/ https://www.sqlalchemy.org/
- flukus 9y ago
  It's based on the (false) belief that 2 section of the code base accessing/updating the same data will be performing the same function so it should be in one place. This one place is the data access layer and as more exceptions to this belief more and more "business logic" seeps into the data access layer. Then your business layer is anemic because most of the "logic" is moved to the data access layer and it's just an unnecessary pass though from the application layer. Some places will be very strict about this design pattern and require the application layer make multiple calls to the BLL and DLL, typically resulting in a problem known as n+1, where the application layer is making 10's - 1000's of separate calls to the database per request instead of just doing it in an inner join. Advanced implementations will have these layers physically separated on different machines in the mistaken belief that more CPU will fix this performance problem, modern implementations will call them microservices. Of course nobody measures the impact. By this point any hope of transactionality is lost. So instead of "messy" inline sql or ORM calls you end up with 7 layers doing nothing between you and the database and showing 10 items in a list on a web page takes 54 seconds. And that ladies and gentlemen of the jury, is why I didn't brake when I saw the software architect crossing the road.
mikekchar 9y ago
Ha ha! I went through a phase of my career where I thought it would be cool to write code generators that took input from the BNF in RFCs. Luckily I was just smart enough to declare that code generation was a one time only event. Current me would have been very worried about how to survive young me's creative programming spirit ;-)
theptip 9y ago
> they never seem to quite acknowledge how bad legacy systems can be Isn't that the ground truth that everybody starts with though? My general perception is that everybody "knows" that legacy systems are bad, hates them, and doesn't want to work with them. I view the article as attempting to moderate that base position and inject some caution by highlighting often-unforeseen costs to certain approaches to attempting to replace legacy code. I think the OP would respond to all the cases you're referring to by advocating either a full rewrite (if they really are as bad as your observations above), or leaving the code alone (if the cost of a full rewrite or carrying a partial rewrite is higher than the cost of living with the old code).

by moring 9y ago

hinkley 9y ago

The legacy system was built in a way that makes it impossible to store the code in any kind of VCS Come again?

Terr_ 9y ago
Maybe it's in something like Smalltalk?
- floaterpig 9y ago
  Another alternative is one of the PICKs where the source code is (used to be perhaps) stored in the database, or I think COBOL on some systems didn't exactly lend itself to flat files from the little I saw (or at least the OS wasn't embracing CVS/SVN/Git in favour of some hugely expensive and utterly inferior product...).
  - Terr_ 9y ago
    Ah, right, or "business logic eval()ed from database text" systems.
    - jupp0r 9y ago
      Or, more commonly - stored procedures.
      - Terr_ 9y ago
        Stored procedures are a little easier to handle provided your deployment system does a wipe/replace, similarly to overwriting scripts/executables. I was thinking of a grimmer scenario, where the system has an disquieting aspect of polymorphic, run-time code editing... central to its "flexible" production behavior. There are more things in heaven and earth than dreamt of in sane philosophy.
- fiddlerwoaroof 9y ago
  Smalltalks (at least Pharo) have integrated version control
titanomachy 9y ago
It's not stored in text, or even in files at all. The program exists only in the form of holograms encoded into crystals which can only be altered by singing at a precise frequency.
- marcosdumay 9y ago
  I've seen: - The program can only be compiled in a particular Eclipse environment, that is copied from one machine to the other. Every attempt to replicate the environment from a plain Eclipse installation fails. - Building the program depends on specific versions of system executables. Those versions are long outdated. - The program depends on specific and very complex system settings for building and running. Those are comparable in size to the source code. And I mostly do not work with legacy systems. EDIT: Oh, and there is the obligatory "90% of the executable source lives on the database" kind.
Arbalest 9y ago
Binary formats, such as ladder logic in control systems, as an example. Which also typically can only be edited by a first party program.
adrianratnapala 9y ago
VCS requires that projects build from source code that is more or less immutable except when humans really want to change it. But some projects mutate in machine-dependent ways by the build system. Bonus points when said data is binary. I've seen CMake caches and Eclipse project files go wrong this way. Another good one is where your development project is testable only against a real database, and the schema keeps changing. Even if you could revert the schema file, you can't revert the data.
jrimbault 9y ago
My experience: a small-ish size php application made originally by 2 autodidacts who didn't dig too far into programming and the tooling around programming (weirdly enough, I found some pretty advanced SQL in there, while it seems it didn't bother them to write the exact same request 7 times 5 lines apart from each other). There were/are files scattered all accross the filesystem with wild include statements both at the top of each scripts and in the execution logic. The scattering was/is so bad with mixed data files with logic files, dependencies (which were not registered as such, and were modified from their original source) thrown between original scripts. I've started versioning a year ago when I got there, and I only got to _good_ state last month, trimming and trimming. Just the fact that files were scattered accross the filesystem, while not constituing big enough clusters to warrant separate repositories, meant I had to make one large repo with weird ignore rules.
emmelaich 9y ago
Nothing is impossible of course because it is all bits. But perhaps they are using something like Oracle BI where you assemble some blob in a UI on Windows then upload to the server. You could commit the blob to VCS. Or maybe serialize it to XML (supported in some versions). But try and convince the DBAs doing development to do that commit. Good luck.

incompatible 9y ago

I get lost with all the Microsoft / data modelling terminology, it doesn't have much to do with software I've ever had anything to do with. What is all this "data-access layer" abstraction stuff about anyway?

hinkley 9y ago
Your architecture may say exactly all of the qualities of your data are but when it comes to transferring it into and out of a database some of the fidelity is lost. If you're trying to pull the data into a statically typed language (even one that isn't object based) there's an impedance mismatch and you almost have to trick your language into accepting the data. So you hide this indignity in something called an Object Relational Mapper, and the rest of your app just pretends like you have a database that gives you Objects. There are a million flavors of these with their own jargon but it's all the same stuff, and they are all within an order of magnitude of each other on the awfulness scale (which is why I'm not to enthusiastic every time someone comes up with essentially the same thing under a different name. Like, say, Protocol Buffers)
- DonHopkins 9y ago
  Agreed, ORMs all suck because what they're trying to do is essentially sucky. But some are better at sucking than others by orders of magnitude! https://www.sqlalchemy.org/ https://www.sqlalchemy.org/
flukus 9y ago
It's based on the (false) belief that 2 section of the code base accessing/updating the same data will be performing the same function so it should be in one place. This one place is the data access layer and as more exceptions to this belief more and more "business logic" seeps into the data access layer. Then your business layer is anemic because most of the "logic" is moved to the data access layer and it's just an unnecessary pass though from the application layer. Some places will be very strict about this design pattern and require the application layer make multiple calls to the BLL and DLL, typically resulting in a problem known as n+1, where the application layer is making 10's - 1000's of separate calls to the database per request instead of just doing it in an inner join. Advanced implementations will have these layers physically separated on different machines in the mistaken belief that more CPU will fix this performance problem, modern implementations will call them microservices. Of course nobody measures the impact. By this point any hope of transactionality is lost. So instead of "messy" inline sql or ORM calls you end up with 7 layers doing nothing between you and the database and showing 10 items in a list on a web page takes 54 seconds. And that ladies and gentlemen of the jury, is why I didn't brake when I saw the software architect crossing the road.

mikekchar 9y ago

Ha ha! I went through a phase of my career where I thought it would be cool to write code generators that took input from the BNF in RFCs. Luckily I was just smart enough to declare that code generation was a one time only event. Current me would have been very worried about how to survive young me's creative programming spirit ;-)

theptip 9y ago

> they never seem to quite acknowledge how bad legacy systems can be Isn't that the ground truth that everybody starts with though? My general perception is that everybody "knows" that legacy systems are bad, hates them, and doesn't want to work with them. I view the article as attempting to moderate that base position and inject some caution by highlighting often-unforeseen costs to certain approaches to attempting to replace legacy code. I think the OP would respond to all the cases you're referring to by advocating either a full rewrite (if they really are as bad as your observations above), or leaving the code alone (if the cost of a full rewrite or carrying a partial rewrite is higher than the cost of living with the old code).