It's kinda dumb but I do like this children's book retelling of software development
It's not dumb. Some of the most impactful stories are fables. You may also like Java Koans.
The little legacy code that could: a fable of software ownership
31–40 of 76 posts
Re: The little legacy code that could: a fable of software ownership
#32I am currently rewriting a 10 year old VB application, which is in web forms. That application communicates with AS400 DB2 database. I get to use as400 here and there. My application is in .NET Core 2. There are some issues as anything IBM can be a pain in the ass to work with. Also, the as400 dev and me have a tremendous knowledge gap. I know everything new such as unit testing, proper source control, dependency inj…
I worked at an AS/400 shop out of college (this was in the 2000's, though). The other programmers there did NOT have a better understanding of low-level programming than me. In fact, it was hard to call them programmers at all.
Yeah, a lot of AS/400 programming is actually pretty high-level (comparatively speaking). COBOL in general was meant to be accessible to end users (or at most power users) such that they could readily define business logic without having to resort to something like assembly or PL/I or what have you.
Re: The little legacy code that could: a fable of software ownership
#33>The initial development cost of software rounds to zero when compared to operating costs in perpetuity. Mostly a good article, but what is with this quote? Aside from being factually wrong from a dollars and sense standpoint, doesn't it contradict their point that legacy code doesn't get enough love?
Author here. I don't think it's wrong in most (nearly all) cases. The cost of running software, keeping it updated, changing the HW it runs on, keeping it compliant, etc over time costs much more than the dev time to build it. Unless your service is completely replaced every couple years, I'd venture operations cost more than development. (even if dev handles the ops). The point of the statement is designing for oper…
This seems like moving the goalposts though. "Much more" is not "rounds to zero". Software is just expensive, period - to build, and to maintain.
Re: The little legacy code that could: a fable of software ownership
#34> Legacy means it worked. No and shame on you for pushing this idea, is my first reaction. "worked" doesn't mean anything. Positing this redefinition of Legacy (and implying what "worked" means) rubs me the wrong way, especially when tying it to the idea of code ownership. Maybe I just have a warped perspective, except that I've run into these scenarios. "worked" might mean "it was easy to fix and it broke a lot", "i…
Author here. Code doesn't become legacy if it didn't fulfill some purpose. If it didn't work, it wouldn't be legacy, it'd be source code in somebody's home directory that was never deployed. All working software is not legacy software. All legacy software (still running) works, for some definitions of works. That's not to say your points aren't also really correct. Software is built with current requirements and know…
I know of at least three projects (with huge budgets) right now that are spawned from the corpses of old, failed projects that never worked. Those old projects make up the legacy of the current effort and can’t be easily thrown away.
Re: The little legacy code that could: a fable of software ownership
#35> Legacy means it worked. No and shame on you for pushing this idea, is my first reaction. "worked" doesn't mean anything. Positing this redefinition of Legacy (and implying what "worked" means) rubs me the wrong way, especially when tying it to the idea of code ownership. Maybe I just have a warped perspective, except that I've run into these scenarios. "worked" might mean "it was easy to fix and it broke a lot", "i…
> Legacy means it might be working, depending on your CURRENT needs. Your current needs change, even when the code does not. No working should mean "It fulfills the requirements". If the requirements change then the code should change. The other things you have mentioned are important but they aren't necessarily requirements e.g. Uptime / Reliability / Performance might be requirements but without stating what they s…
> If the requirements change then the code should change.
That's the nature of the term "Legacy", that you are using. It met requirements that are not the same today (sometimes it's just standards of coding). It didn't change, hence it's legacy code.
Re: The little legacy code that could: a fable of software ownership
#36This is one of those interesting paradoxes that I haven't figured out yet. Owning the legacy software that runs the business tends to provide job security at your current job, but can hinder your professional growth at both your current job as well as any future jobs. Getting on to projects that are intended to replace legacy software tends to get you a lot of positive visibility politically and the ability to learn…
> Unfortunately there's just not a lot of value to being able to put on your resume that you're an expert at an older language that nobody has heard of, built on an in-house framework that will never be used outside of your current company. I think this is, fortunately, only approximately true. Most of my career to-date has involved exactly this kind of work and it's certainly not true that there's no value in it, ev…
Most of my career has been working on legacy projects (or fixing broken ones), I like greenfield well enough but I’ve no preference for it over maintenance.
There is as much pleasure in making something broken work properly as creating the thing (imo).
It’s a steady career as well, most programming is maintenance outside of the fail fast world of startups.
Re: The little legacy code that could: a fable of software ownership
#37I really like how they tell the story at the beginning, I felt sorry for an hypothetical piece of legendary code
Re: The little legacy code that could: a fable of software ownership
#38This is one of those interesting paradoxes that I haven't figured out yet. Owning the legacy software that runs the business tends to provide job security at your current job, but can hinder your professional growth at both your current job as well as any future jobs. Getting on to projects that are intended to replace legacy software tends to get you a lot of positive visibility politically and the ability to learn…
It is indeed a conundrum. Working in maintaining and supporting legacy software is both an absolute necessity for the business and a possible career dead-ending move for you. You're at the same time doing important work -- if not particularly interesting or groundbreaking -- and signalling to your employer "I'm not marketable enough that you must raise my salary or risk me leaving". Working on legacy software can als…
The upside of being a COBOL jockey is that you have a steady job and basically just work a runbook. Some people dig that!
Re: The little legacy code that could: a fable of software ownership
#39I think its very interesting to think about this article in the context on the open source projects that relied upon by the vast majority of major applications and companies. Specifically OpenSSL comes to mind here. That library has been used/leveraged in so many ways to build empires. Yet it's currently struggling to find dedicated engineers that will work on its core logic. It's an unfortunate situation and while y…
Re: The little legacy code that could: a fable of software ownership
#40"Why is there unclear ownership?"
Because Extreme Programming (and other agile practices?) make Shared Code-Ownership a "value".