[HN Gopher] Legacy Software Systems: How to Live with Aging Soft...
___________________________________________________________________
Legacy Software Systems: How to Live with Aging Software
Architecture?
Author : mgl
Score : 41 points
Date : 2023-03-05 18:28 UTC (4 hours ago)
(HTM) web link (stratoflow.com)
(TXT) w3m dump (stratoflow.com)
| GartzenDeHaes wrote:
| Having been involved in 3+ $8-figure legacy replacement projects,
| this article seems to be missing business, management, and cost
| perspectives. In particular, "non-compliant with recent
| standards" is the least important reason to consider rewriting a
| working system. Often, chasing whatever is popular at the moment
| is the root cause of maintenance problems in the first place.
| hinkley wrote:
| The sad fact of software projects is that some part of the work
| is always a bit of bribery to keep skilled labor engaged.
| You're always throwing them bones, letting them work on a few
| things that don't really need to be done but make them happy.
| That's lost sometimes when I'm lamenting NIH or wheel
| reinvention, but it's a matter of degrees. Let them have one
| big thing and a bunch of small things.
|
| Companies go off the rails and get trashed talked when they
| clamp down and go for zero fun, 100% financially justifiable
| task lists.
|
| As a tech ages out you can't find anyone good to work on it.
| And when you make them, morale craters.
| djbusby wrote:
| From my perspective, there's loads of this legacy/boring crap
| (lots of PHP&Rails). As a "old" coder, I love those legacy
| apps that folk can't/don't give to their internal team - it
| becomes consulting work for me :)
| kevinmhickey wrote:
| Wish I could upvote more than once. What I call "Resume Driven
| Development" creates fractured architectures and reduces
| quality in stable systems for the sake of "the latest
| standard". Not the best spend for the business or
| users/customers.
| cratermoon wrote:
| On the flipside, when your website only works with Internet
| Explorer 11, forcing your customers to keep an unsupported
| browser around, it's time to reconsider the aversion to
| keeping up with changes in the technology.
|
| It's doubly bad when your website is designed for software
| embedded in kiosks and the like.
| nucleardog wrote:
| Keeping your software up to date as dependencies age and go
| out of support or the platform you build on evolves is not
| resume driven development. There's a business and
| engineering case that can easily be made for that.
|
| Of course there's no real dictionary we can go to for this,
| but I'd define RDD as "chasing technology trends without
| business or engineering justification".
|
| Why are we switching to JS-Framework-De-Jour? Why are we
| using this graphdocumentjsondistibutedimmutablelog database
| all of a sudden? How does this improve the business? How do
| see a path to a positive ROI from this decision?
| Buttons840 wrote:
| 80% of the time the answer is "find out if the owners of the code
| are supportive of improving the code", and when the answer is
| "no", just put in your hours and collect a paycheck.
| leidenfrost wrote:
| Dunno, I successfully refactored some legacy services. Some of
| them even were a big index.js spaghetti files.
|
| You have to start with the smallest and most conservative to
| the most "refactory" ones:
|
| - figure out what enters and what exits from the program, and
| create a test suite that reflects every known combination
|
| - move parts of main() to funcions
|
| - figure out what variables can be converted from mutations to
| returned values
|
| - move thr ifs(){} to maps, early returns and such
|
| - figure out the database schemas from newly written data
|
| - infer model relationships fro further writes
|
| - attempt to implement some pattern design, even if its just
| dummy variables
|
| Sometimes you even have to do it at the last stretch of time of
| your workday, and slowly the mess will become clearer, your
| test suit more exhaustive and comprehensive.
|
| And at some point it will achieve feature parity with the
| legacy service
| mixedCase wrote:
| The GP is referring to the political costs of changing bad
| code, not the technical challenges which are almost always
| manageable by any experienced programmer. Egos, however.
| cratermoon wrote:
| Until the friction of working in the terrible code becomes bad
| enough to slow down development to the point that the code
| owners complain about why it's taking so long to get work done.
| Of course they still won't support improving the code, but at
| least you have empirical evidence that never taking out the
| garbage turns makes the system look like a house in an episode
| of _Hoarders_
| bberrry wrote:
| If you start a rewrite or a large refactor, for Gods sake, follow
| through and _finish_. Otherwise you have made things even worse.
| I can't tell you how often I've come across the remnants of such
| projects, abandoned with some sliver left. I make a point to
| never leave it like that.
| cratermoon wrote:
| Few places I've worked ever put improving the system in the
| plan. It's almost always said that "we'll work on it later,
| when we have time". Later almost never comes, of course. On the
| rare cases when there is a little time, the team will start
| something but have to abandon it when inevitably the business
| needs change and they get drawn to other work. Remnants of
| incomplete attempts speckle the codebase like bird droppings on
| a car parked under a tree for 6 months.
| bberrry wrote:
| I think that's part of our responsibility as engineers to
| ensure that technical debt doesn't pile up. Business will
| want to focus on pushing new stuff and engineers have to be a
| counterbalancing force. It's literally your job.
|
| This hasn't been a problem in the places I've worked. Perhaps
| I'm lucky or it's the fact that I don't live in a very
| hierarchical society (Sweden).
| mgl wrote:
| #1 Keep track of the most important updates
|
| #2 Don't rewrite what you don't have to
|
| #3 Maintain good documentation, gather the necessary knowledge
| ramraj07 wrote:
| #2 is not universal. There's a lot of legacy software with
| outrageous workarounds and sometimes it's simpler to rewrite
| part of the system than to even maintain it for a month. It's
| all about good judgement.
| anonuser123456 wrote:
| Until you find out there is some essential complexity you
| missed that's encoded in the convoluted logic... and then
| your rewrite doesn't function and you look foolish.
| Dalewyn wrote:
| Rule 0 in Engineering: If it ain't broke, don't fix it.
| indymike wrote:
| > it's simpler to rewrite part of the system than to even
| maintain it for a month.
|
| This is often a career limiting decision. Rewrites are often
| much more difficult, particularly when you are dealing with a
| system that is not fully understood. This often leads to what
| should be a quick re-write taking > 3x more time and money
| than projected. In the end no one will remember why the
| technical reason for the rewrite, but they will remember who
| made the decision.
|
| I've made this mistake a few times in my career, and I always
| thought, this project, it is the exception to the no-rewrites
| rule.
| goto11 wrote:
| Yes but before you can make that call you need to have a
| reliable estimate of how costly it will be to rewrite the
| system. This in turn requires a through understanding of the
| current behavior of the system, which means you will have to
| study and understand the code anyway.
| SoftTalker wrote:
| That's often the first impression but in my career I've never
| seen a rewrite work substantially better or save any money.
| Sometimes they are necessary for other reasons but those two
| are the arguments usually made and they don't really hold up.
| switchbak wrote:
| I've got experiences in both camps. Well managed rewrites
| (typically portions of a system) can fix a lot of problems
| in one fell swoop, but you have to really know what you're
| doing and actually have concrete plans for improvements.
|
| If not, all you've done is just replaced a bad system with
| another bad system. I've also seen that lately. You're
| right that often it's just "different" and not better, and
| that makes it hard to sell the case when a rewrite is truly
| needed.
| jt2190 wrote:
| I feel like I'm reading a rough draft, not a deeply thought out
| piece of writing. There are some nuggets of good sounding
| information in here, but the author doesn't really go very deep.
|
| Chad Fowler had an interesting slide in one of his talks (circa
| 2009 I think) where he had a graph of something like frequency of
| errors produced by working code versus number of changes to that
| code. Code could end up in one of four quadrants:
|
| - frequent changes, lots of errors: suggesting that the domain
| was still being discovered or there were quality issues
|
| - frequent changes, few errors: suggesting the domain was
| changing or growing but quality was good
|
| - few changes, lots of errors: suggesting that the code was not
| adequately maintained or even understood, perhaps poor quality as
| well
|
| - few changes, few errors: this is the "legacy" code that works
| hard and costs less to keep running
|
| Clearly it's a good thing to have that "legacy" code, by this
| definition, but I remember that he listed some downsides as well,
| but _not_ the downsides that the junior dev who wants to rewrite
| then whole system comes up with.
|
| Edit: I think it might have been "Measuring & Analyzing Things
| That Matter When You Have Too Many Things To Keep Track Of"
|
| At 36:00, he talks about a ruby gem called for Rails "Turbulence"
| that measures code complexity against number of modifications
| https://vimeo.com/38252887#t=2160s
|
| He also references this article by Michael Feathers: "Getting
| Empirical about Refactoring"
| https://www.stickyminds.com/article/getting-empirical-about-...
| cratermoon wrote:
| The best source for this kind of emprical measurement of code
| complexity is _Your Code as a Crime Scene_ by Adam Tornhill.
| See also http://www.adamtornhill.com/code/codemaat.htm
| jt2190 wrote:
| Very cool! It looks like that's evolved into a company called
| CodeScene. Interesting demo by Adam:
| https://youtu.be/SWFwPkgLcpo?t=10
| miohtama wrote:
| The legacy software works very well in a static world: when
| nothing ever changes there is no need to update the software.
|
| Of course, this is not the case. The problems arise when the
| software updates are not budgeted. Especially the finance sector
| is notorious for underinvesting in R&D and instead of spending
| money on stock buybacks - stockholders appreciate.
|
| However this cycle is broken when the world actually changes. If
| there is no proper maintenance, usually in the form of software
| R&D, the legacy software change cost has gone prohibitive high
| and the parent company is unable to do anything. This change is
| often Schumpeter's creative destruction. There is a new
| technology. A new startup raises as a competitor, using more
| efficient software where they can do changes, and execute their
| core business, with much lower cost, outpacing the established
| competitors.
|
| Some industrial, like early mentioned finance, are however very-
| well protected due to barries of entry like the cost of initial
| capital and regulation. Thus, you are going to see more legacy
| software in industries where there is never need for a change.
| nickpeterson wrote:
| The thing about never doing that big refactor, is your team loses
| the _ability_ to do it. Only maintaining legacy codebases results
| in people who can't build things.
| lll-o-lll wrote:
| This is a big, big company problem in my opinion. If you have a
| dev force mostly just adding to an existing system, they never
| learn design skills.
|
| Those that built the system inevitably leave over time, and now
| you're stuck unable to attract talent because "old tech stack",
| and without staff that could build something new.
|
| Don't stay at a company that's gotten into that state. If your
| young, try and gain a mix of experience so you can actually
| gain those design skills.
| chrisweekly wrote:
| In this space I highly recommend the book "Kill It With Fire".
| marsven_422 wrote:
| [dead]
| luciusdomitius wrote:
| Well, the car analogy is very good I think. A 35-year old
| Mercedes-Benz W124 that has been taken care of during its entire
| lifetime is actually usable and could be reliably maintained. A
| 10-year old Hyundai with 50k km old oil is meant to be scrapped
| though.
|
| In the same way, there is legacy software and legacy software. In
| a decade of contracting I have seen both pieces of crap with 50%+
| of dead code which are inmodifiable beyond adding/removing fields
| from some CRUD entity, and 15+ year old J2EE competently
| designed, maintained and documented systems, where the only
| difference to a fancy new project is that there is xdoclet
| instead of annotations and a ton of plumbing code around.
|
| The big difference is in telling them apart in advance - with
| cars you know that some brands are more maintainable than others
| as you see them on the road and as all of them share the same
| components/weak spots it doesn't take long to figure out if it is
| an oldtimer or a piece of junk. With software it is much more
| complicated.
| 908B64B197 wrote:
| Telling non-technical people about UNIX is often eye-opening.
|
| Development for UNIX started in 1969. It was done in a
| documented way, using well defined APIs (that later became
| standard) by world class engineers.
|
| The original code (in C) is still readable. Running it on
| modern hardware would be a challenge, since computer
| architectures changed quite a bit, and modern CPU architectures
| were simply not invented yet! But it's not legacy code; the
| interfaces, ideas and libraries from 1969 have been improved on
| and are the foundation of the modern computing landscape.
|
| Yet spaghetti code from two years ago, written by "best value"
| programmers in a language that's 100% still supported is very
| much legacy code. Unintelligible comments, no tests, copy-
| pasted code, inline queries, the list goes on. Often simpler to
| just re-write.
| alexott wrote:
| 10 years ago I've attended a talk from one of German car
| producer - they talked about 25+ years of software maintenance.
| You invest into tools 5 years before release to market, and
| they should work 20 years after release. So companies need to
| plan the whole cycle not only code maintenance
___________________________________________________________________
(page generated 2023-03-05 23:00 UTC)