a question for y'all:

just out of interest I would like to know:

are you *mainly* working on legacy stuff that is - without a question - just too old? everyone in your corp knows it needs rework but "EfFoRt JuSt ToO hiGh"? Where at the same time, most of dev time goes into maintenance and bug fixes instead of feature implementation.

If yes, do you fear that you're losing relevance on the market by not keeping up to date? What are your feelings about that situation?

did you maybe even quit a job in the past because of such situations?

---

Why do I want to know that?
- Had some beer
- As a freelance dude I often see battlefields right out of hell. I csn easily go, but the dudes working 9 to 5 on that??? Hoe can you oO

I'd say it's a solid 50% brand new code to 50% legacy where I'm at.
Never feel like my skills are dying atm as legacy is everywhere.
I wanna be a legacy specialist. Forever job. Each repo have almost the same issues regardless of language/stack so skills are very cross transferable.
I'm always reading new ways of taming shit code and loving it. Doing "god's work" 😁.
Am drunk atm soz

@MammaNeedHummus 50% old legacy code, 50% new legacy code.

@MammaNeedHummus The others legacy code is making u thougher. after fixing enough legacy problems noone wants to look at u gain respect++ and becoming unstopable

Greenfield dev ftw. I'm maintaining a stable production app which takes about 5% of the time, rest is greenfield Java 17 / SB3 / Kafka stuff.

@electrineer is it legacy if it's driven out with TDD?

@MammaNeedHummus possibly

@electrineer @MammaNeedHummus it is. every code in it's final form ( all known bugs r killed ) becomes automatically legacy code

@We3D As long as its in production, it is legacy code.
Never met a dev who didn't "whats this shit code?? ... lets rewrite everything in java/python/go/rust/c++/kotlin/swift! ... what do you mean shut TF up?!"

@magicMirror yep we can look at it that way too, except for the cases the work is in progress and no dev server arround ;)

It's how I earn my money nowadays.

While I absolutely hate networking, I have an "unintended" network. Mostly old colleagues, people I met on conferences, things like that. I was toying with the idea of opening a kind of desaster consultancy lately, but I think my health isn't up for it.

While I still work 100 % for my company, there's always some side thingy going on... Someone asking for advice, someone wanting tips for presentation, stuff like that.

Most companies are unaware that their tendency to hang onto legacy software is getting them booked for bankruptcy.

Not joking.

Seeing it all the time.

From things like "we don't do internal mirroring and suddenly NPM / pypi / ... dropped packages" to "database collapsed and is in restart limbo since few days" to the classic hardware cannot compensate for severely misarchitected software which is unable to scale.

I did quit a few jobs, but only if I saw repeated ignorance / malfeasance.

If they don't listen, I'm out. A lesson I needed to learn, and a lesson well learned.

Current company is severely anemic of new blood, but they still do their best to keep up the necessary migrations despite severely understaffed.

As long as that is going, I won't pull the plug.

Most companies need intensive care, which is sth. which requires someone to operate outside the normal range imho.

E.g. a sole dev cannot fix problems - they need to have management authority and be a dev and be a bridge to upper management.

If everyone then pulls the string, it's doable to go from stone age (10 years and older) to modern age ...

Otherwise: Nope. Zero chance. Unless we're talking about very small projects or projects which a very short lifespan - e.g. 2 years or younger.

Thank you for your answers :)

I learned that I need to clarify "legacy" for myself.

While writing the question, I was thinking about things like

- outdated frameworks
- bad (unmaintainable) architecture
- growing technical debt
- not following/ not even having code style guidelines
...and so on..

and those things do not summarize under "legacy" but more like "acummulated bad descisions without realizing the direction in which the whole thing is going to"

@nebula I love Michael Feather's definition in their first chapter of their book (aptly) named "Working Effectively with Legacy Code":

"Legacy code is code without tests"

Uncle Bob has a funny description too in the book's forword

Rest of it

@MammaNeedHummus I've seen code that would still be legacy code if you somehow managed to write tests that made any sense. Then you would also have legacy tests!

@MammaNeedHummus the entropy is everywhere... even in some tests some time ;)

@electrineer the idea here is that adding test coverage to legacy requires you to refactor and improve the legacy to make it testable (e.g. breaking it's hard dependencies so you can set it up in a test harness).

You tend to end up with decoupled and shorter code (what I call "tamed legacy") that's not scary anymore and can be refactored without as much thought.

It's served us well so far

@We3D ofc but I'm much more likely to refactor code I can quickly verify still works the same as it did the first day it was written.

Multiply that attitude across the entire dev team and suddenly you have less hellish, and now documented, code

@MammaNeedHummus but one has to account that the tests will change with any upgrade/correction from the initial requirements and that can lead to a missed edge case too, still I agree it is better to be TDD than pure spaghetti. just pointing out that there is no definite solution... otherwise we wouldn't be navigating this jungle of frameworks and best practices which oppose each other...

Oh yeah ofc. Nothing can stop shit head developers from fucking up. No cure for stupidity as they say!

@MammaNeedHummus but then you're also refactoring and not just writing tests. Another way to write tests is by mocking all the interface violations. Then you end up with tests you don't ever want to touch again, doubling the problem.

@electrineer not sure what you mean by interface violations - if you're talking about the problem of "what do I test" when you could technically test a million possible input values for a function then:
You have options.

There are libraries that auto generate all sorts of test data extremes (e.g. Hypothesis in Python) which cuts down on test maintenance costs. There is also a pragmatic decision element to it as well - choosing to write high-value tests that are worth maintaining. Becomes more of an "engineering" problem then a "hard science" for that bit. It's the same for manual testing though

I try to focus on testing things I suspect will cause issues later (e.g. making sure my validation rules are water tight).

It pays to work in a typed language - stricter the better - as that can handle a lot of cases automatically (won't compile)

I feel like we need beer, pizza, a laptop, a good code challenge, and an evening to experiment with what you were saying and see what you think