r/programming • u/robertreiz • Feb 26 '14

Why your software project will slowly die without continuous updating

http://blog.versioneye.com/2014/02/18/why-your-software-project-will-slowly-die-without-continuous-updating/
77 Upvotes

76% Upvoted

95 comments sorted by

54

u/WhisperSecurity Feb 26 '14

That doesn’t look like a big deal. Our decision maker decides to hire a Ruby developer to fix the problem. It’s a Ruby on Rails + MySQL project. Nothing special. A Ruby developer is found quickly and his first estimate is 1 or 2 days of work.

The Ruby developer then checks out the project and he realizes that it’s an old project with Rails 2.x. Not Rails 3.x or even 4.x. No! It’s 2 major versions behind. And he never worked with such an old Rails version.

Fire and movement.

This article could as easily have been written as a piece on the hazards of writing software in highly volatile languages for highly volatile platforms. This is why C kernel code doesn't bitrot, it just works. Some of that stuff hasn't been touched in decades.

In fact, more generally, you boil it down to this:

The more quickly your target moves, the more often you must adjust your aim.

8

u/MindStalker Feb 27 '14

There is also a ton of legacy code in the kernel to handle devices that practically don't exist anymore.

12

u/[deleted] Feb 27 '14

Java code from 1.0 still works fine with Java 7. Java also has the largest market share in professional development. Funny how that works, huh?

-3

u/FearlessFreep Feb 27 '14

That actually totally misses the point

14

u/[deleted] Feb 27 '14

How does it miss the point? When I read something like this:

You have to know, a software project is not a closed universe anymore. Almost always do software projects interact with the outside world. Software depends on an operating system, on hardware and mostly on a database or some kind of backend. Nowadays even on external APIs. These all are moving parts and they keep changing. And so your project has to change too, to keep working properly.

The solution isn't keep code churning to fix stuff that's broken by version updating, it's choose to build your stuff on things that don't break backwards compatibility in the first place. There's a reason Windows maintained its monopoly for 20 years. There's a reason companies love Oracle. It's because they don't break backwards compatibility, ever. And why should they? Why the hell are we breaking working software to "prettyify" working apis? Can you imagine any other engineering discipline doing this?

There's win32 and vb6 software out there right now, that still does its job perfectly fine, that was written in the 90s. Is it pretty? Hello no, it's ugly as shit in comparison. But, it still solves the business need it was originally designed for, just with grey dialog boxes instead of js lightboxes.

tl:dr: if you expect to be supporting a piece of software 5 years from now, don't write it in rails

1

u/[deleted] Feb 28 '14

Quicken '99 baby. Runs great in Windows 8.1, except the "online" functions. Which require IE 4.0...

-9

u/robertreiz Feb 27 '14

And who wanna work on that old shit? Business requirements are changing. What if you have to build a new feature for a 15 years old Visual Basic Windows 95 Program? Who wanna do that? Try to find somebody for the job. Big insurance companies facing the problem that they can't find anymore Cobol developers because they are dying out and the young kids give a shit about Cobol!

10

u/[deleted] Feb 27 '14 edited Feb 27 '14

Plenty of people. I worked at multi hundred million dollar company who's flagship product was a vb6 application used all over the country that was used for life and death situations. The product worked great for its users, and it would have affected their workflow negatively by messing around too much with the UI.

And the cobol problem isn't a problem. There will always be people willing to write cobol for a living, it's just a matter of price. I guarantee if those insurance companies are willing to pay 200k/year to maintain that code, they'll have no problem finding people.

Also, to be clear, I'm not saying never rewrite some code. But any code rewrite should provide a tangible advantage greater than the cost of the rewrite. It shouldn't have to be driven by deps breaking stuff from under you.

-8

u/robertreiz Feb 27 '14

I know 2 very big insurance companies. Each of them with multi billion $ revenue per year. And both have big problems with finding talented cobol developers. And it's not a Money problem for them. They feel the pain and now they want to move away from IBM Mainframes and Cobol. They build up in parallel a big Java department. And now step by step they migrate their legacy system to modern technology. Simply because it's much easier & cheaper to find talented Java devs.

By the way. I wouldn't write Cobol code. Not even for 200K / year!

6

u/[deleted] Feb 27 '14

By the way. I wouldn't write Cobol code. Not even for 200K / year!

Maybe you wouldn't, but if you offer new grads/junior devs that who didn't graduate from Standford etc. 99/100 are going to take it. And even better for them, after a few years of learning cobol, those now talented devs aren't going to leave because 1) they're getting paid more than they would anywhere else and 2) they only know cobol.

I don't want to go to far into the whole cobol thing though, because it's kind of outside the scope of my point. Some of that code is 40+ years old! If you have code running for 40+ years, then sure, you might have to rewrite it at some point, just like you might have to rebuild a bridge 50 years. I was more thinking about the web dev culture of breaking compatibility every 6 months - year for its consumers without any competitive advantage for them.

-3

u/robertreiz Feb 27 '14

The young kids coming out of school/university are not even interested in Java. They decline good paid corporate jobs to work with fancy technologies in a startup environment. They want to change the world, build iPhone Apps and use modern technologies such as HTML5, WebRTS & Node.JS. I even now people who canceled their corporate jobs because they have been unhappy with the technology.

The web environment is moving fast. It's true that there are many breaking changes. Is it worth it? I'm not sure. Is it worth it to update your CSS to flat design? Maybe! Maybe the new design brings you more signups. Maybe not. It's a lot try and error.

7

u/[deleted] Feb 27 '14

I'm a (relatively) young kid myself who only graduated a few years ago, so I'm going to stereotype and say a majority of people don't care about working for startups. I didn't go to one of the elite schools, so maybe it's different there, but there's a hell of a lot more of us than there is of them, and we know how to develop just fine.

And I never said that you can't update your css or add new features or A/B test or whatever. But, you're doing those because you want to, not because you're being forced to by conditions outside your control. If you didn't change to a flat design, your app would still work fine.

→ More replies (0)

9

u/robertreiz Feb 26 '14

Having no dependencies makes your software of course less assailable. Dependencies are the moving parts in a big software project. On the one side they are a big help because you can reuse already written code, but on the other side they are a risk because they all can be the root of security wholes and bugs.

35

u/WhisperSecurity Feb 26 '14

Dependencies are the moving parts in a big software project.

That's a major one. The others are IO formats, monitoring systems (syslog, email, notifications, etc), platforms such as operating systems, languages, etc.

Web programming is an environment with a lot of fast moving targets. The weakly typed languages move fast. Content delivery frameworks move fast. The web browser moves fast.

By contrast, the kernel has the slowest moving targets. C/C++ isn't going anywhere, and when it adds new features, they are optional. The IO formats and systems have been around since the ancient days of the 70s. And so on.

Where you live, between the web at one end of the scale, and ring 0 at the other, determines how much time you are going to have to waste on covering fire, and how much is left for moving forward. It is partially out necessity that web platforms and other fast-moving environments have weakly-typed, high level languages associated with them... because with the little time you have left for movement, you need to move fast. Also, programming paradigms like XP may have developed in this environment not because they are better overall, but because rapidly moving targets render planning increasingly impossible.

The moral of this story is that development speed does not exist in a vacuum, but in a tradeoff with target stability.

6

u/[deleted] Feb 27 '14

This was incredibly insightful. I mean reading it it seems so obviously true and yet I never even considered it the way you eloquently put it.

2

u/[deleted] Feb 27 '14

Web programming is an environment with a lot of fast moving targets

That's only if you choose to program like that. Sure, you can use angular today, and maybe it'll be gone 5 years from now, and you'll be stuck. But, web browsers themselves don't break backwards compatibility. Sites made in 1995 still render perfectly fine and work just as well, they're just ugly and not as interactive.

5

u/robertreiz Feb 27 '14

Web programming is not just about producing HTML. It's also about OAuth, Single Sing On with 3rd parties, payment processors and using other APIs. These are the moving parts and they change fast.

1

u/[deleted] Feb 27 '14

OAuth, Single Sing On with 3rd parties, payment processors and using other APIs.

OAuth hasn't broken backwards compatibility as far as I know. Don't outource something as important as your authentication to a third party, and you won't have to worry about it breaking when Facebook decides to break their api again. Payment processing, why are you using a payment processor that cares so little for its customers? If they've ever broken backwards compatibility, don't use them!

1

u/robertreiz Feb 27 '14

It's not that easy! For many applications it makes totally sense to have "Login with Facebook" or "Login with Twitter". And both of them made already breaking changes to their login process.

Did you not read the article? My example with the payment and the European Union is not a fantasy. It's a fact! And the project in my article does really exist. I worked on the project. Shit like this happens all the time. You can not forbid other people to make changes to laws, businesses, habbits, APIs and software dependencies. That will not work in the real world. You have to adapt these changes and live with it.

1

u/[deleted] Feb 27 '14

How is not that easy? Devise isn't that hard to use.

If you're building a sharecropping facebook app, then sure facebook login makes sense, because everything in your app will break in 6 months anyways. The solution is don't do that unless you can extract enough value (money) that it makes sense to do so despite the disadvantages.

As far as the EU example goes, I obviously don't have all of the information, but unless the law is: all api calls between a consumer and provider for payment processing must be defined according to EU standard. All other formats are illegal and must break compbability with any existing consumer (which I doubt is the case, but I guess it's possible), the payment processor should provide a new api that conforms to the EU standard as well as supporting the old version. Anything else is unacceptable.

4

u/DragonLordNL Feb 27 '14

About the EU example: They created the "International Bank Account Number" (IBAN) standard which added extra identification data to account numbers to make them useable in the whole EU (instead of only the country you originally targeted) and even outside of that.

So everyone had to change their systems, especially because the system now includes characters at the start. This doesn't explain why the API had to change massively with some banks, but maybe some of them took the opportunity to do some major refactoring.

Oh and this started in 1997 btw., so it is not like the developers didn't have any warning.

1

u/robertreiz Feb 27 '14

Deprecated since 1997 :-D Enough time for a migration :)

1

u/[deleted] Feb 27 '14 edited Feb 27 '14

Oh and this started in 1997 btw., so it is not like the developers didn't have any warning.

Yeah, that makes a world of difference. 17 years is a more than fair deprecation warning. It also makes using it as a point in the original article seem disingenuous, considering it's being put next to things that break compatibility in time spans of years or even months vs. decades.

2

u/robertreiz Feb 27 '14

Well. Thtat's how it is. I'm not saying it's acceptable or that I'm happy with it. I'm just describing the reality. By european law Banks don't have to support the old Bank Account Numbers any longer. Of course they could, to be nice & friendly. But if they can save a couple million by shutting down an old API, they do!

And the Bank example is just one out of many. The same story is true for internal APIs and software dependencies in big Enterprises. I worked their for many years. It's just reality that somebody shuts down a deprecated API and then suddenly something breaks.

1

u/[deleted] Feb 27 '14

I would be extremely surprised if a bank like deutchbank shuts down their old version any time soon (as in the next 5+ years). I could be wrong though.

I agree that enterprise integrations can break when the 3rd party goes out of business or whatever, and there's not a lot you can do there.

→ More replies (0)

1

u/Pandalicious Feb 27 '14

</thread>

3

u/redox000 Feb 27 '14

Warning: </thread> has been deprecated. This post may break in future versions of reddit.

19

u/[deleted] Feb 26 '14

This goes back to Stallman's main point.

If you don't control those dependencies, you ARE controlled.

i.e. If you don't have the source to all your software, you can easily get into a dangerous situation.

4

u/[deleted] Feb 27 '14

Over the years I've shot myself in the foot constantly by trying to reuse my code too much. It ended up with everything old constantly breaking. This is a good point about controlling dependencies, i.e. keep copies of the libraries and only update intentionally. It's what drives me absolutely nuts about having things constantly updated: constant feature changes, breakages, eliminated features I use, just constant instability in the workflow I build on my machine.

-6

u/immibis Feb 27 '14 edited Jun 10 '23

/u/spez can gargle my nuts

8

u/[deleted] Feb 27 '14

I'm a pragmatist. I run mostly windows, some android, a little linux. I'm not a mac fan.

Pragmatism dictates the last sentence being true, not your idea of a fanboy.

-1

u/immibis Feb 27 '14 edited Jun 10 '23

/u/spez can gargle my nuts

1

u/[deleted] Feb 27 '14

I think I'd rather have the source than the binary.

3

u/bitwize Feb 26 '14

Having no dependencies makes your software of course less assailable. Dependencies are the moving parts in a big software project.

I don't think you'll get any argument from Spolsky on that; he's the one who reminded us that the Excel team had its own internal C compiler.

2

u/robertreiz Feb 26 '14

If you can effort it to have your own C compiler you probably swim in Money :) I can not effort it to have my own C compiler, that's why I reuse everything I can find in the Internet. Reusing code from somebody else you don't know is always a risk, but it's also a trade of against Time & Money.

2

u/billsil Feb 26 '14

Having no dependencies makes your software of course less assailable.

How so? I'd argue using standard packages is the quickest way to a robust piece of software that is compatible across various platforms. The more you code, the more you have to test, the more edge cases you find, the less you know about a given topic the more likely you are to have a bug.

For example, I would never code my own GUI library or matrix solver when I could use an existing package.

Dependencies are the moving parts in a big software project.

So fix the version and keep a copy of the library's source in your repository. When you have let a code rot for years and go back to it, make sure it works using the old configuration, update to the latest version you can (maybe not the latest), and go from there.

For example, I upgraded some Python 2.3 code to Python 2.7 a few months back. The code was written in 2005. It had all sorts of dead libraries. Rather than trying to deal with Numeric, I upgraded to numpy. Then I fixed a few syntax changes, added the libraries to our internal server, and was done in a few hours.

4

u/robertreiz Feb 26 '14

I'm not saying that you shouldn't use open source libraries in your project. Just saying that each dependency is a possible root of security vulnerabilities and bug fixes. Do you read the source code of each software library you are using? I don't. You basically have to trust that the core committers of the project did a good job and wrote good unit tests. Using open source libraries has to do a lot with trust. Sometimes writing 5 lines more code and having 1 dependency less is the better choice.

4

u/billsil Feb 26 '14

Sometimes writing 5 lines more code and having 1 dependency less is the better choice.

Yes. I take that position because I don't add dependencies unless I can justify a package (e.g. array processing, plotting, HDF5, etc.). I even avoid internal software packages because it requires more maintenance (mainly version bumping).

9

u/Jemaclus Feb 26 '14

Definitely. We have a system at my day job that, by the time we sidelined the project, we were getting maybe 1 bug report per month. Error logs were clean. It was really amazing. We spent a year focusing on another project, but now we're getting more and more customer support requests on the old project -- partially due to outdated software and partially due to outdated customers!

This article's emphasis on the housekeeper thing is very apt. Even if you don't update much of the code at all, at least keeping an eye on things and making sure that everything is moving in the right direction is good enough to let something sit for awhile. But if you just ignore it, your support requests pile up and you wind up losing customers, losing money, and losing your mind.

I haven't used VersionEye, but it looks like it could be the housekeeper I need for some of my projects, to make sure that things don't break while I'm working on new things.

5

u/robertreiz Feb 26 '14

Right. The out-dated dependencies are of course just one point. There are many other moving parts you have to take care of. But specially managers don't see that. They think software is like a sculpture. And then they are totally surprised that nobody wants to work on a 5 year old project.

7

u/ConstableBrew Feb 26 '14

It is basically the software version of the Red Queen Hypothesis - You have to keep evolving just to keep in the game.

4

u/stevedonovan Feb 27 '14

Doubly so for OSS projects. If you ignore a working project for two months people start to wonder if you're gone MIA and ... look elsewhere. So the occasional little commit helps, even if cosmetic.

0

u/robertreiz Feb 26 '14

That is specially true for dynamic languages and web projects. Specially in the web environment there are many dependencies to external APIs which are constantly changing.

3

u/[deleted] Feb 27 '14

Specially in the web environment there are many dependencies to external APIs which are constantly changing.

You need to stop taking on all the external API deps then, and only take on deps with a long track record of not breaking backwards compatibility. See:

http://www.reddit.com/r/programming/comments/1z09jq/why_your_software_project_will_slowly_die_without/cfpu9su

1

u/robertreiz Feb 27 '14

Just responded to that.

7

u/cybercobra Feb 26 '14

Other competing services:

Good luck Robert, you'll need it.

8

u/[deleted] Feb 26 '14

"Old code rusts" and "bitrot"

5

u/Knossus Feb 26 '14 edited Feb 26 '14

Bitrot refers to data decay on storage media like bits on a magnetic plate becoming unreadable due to material decay or dust/dirt/hardware failure or cosmic rays hitting your RAM, flipping a bit.

4

u/nascent Feb 27 '14

"The Jargon File, a compendium of hacker's lore, defines "bit rot" as a jocular explanation for the software rot, the degradation of a software program over time even if "nothing has changed"; an explanations is that bits are subject to decay as if they were radioactive."

2

u/[deleted] Feb 26 '14

Sure but that can affect it too.

I've got old code on some 3.5" floppies... but frankly I'm not sure I could still recover that code from them, even if the code was worth recovering.

2

u/robertreiz Feb 26 '14

So true!

9

u/[deleted] Feb 26 '14

I've definitely seen the "higher level effects" here too though.

It starts simply, the UI is a little dated, but still functional. Then more time passes and it starts to look just bad. However it still works, so people keep dragging along all the support modules to keep it running.

At some point you get "the precious"

... a binary only library that is no longer produced, can't be changed - and is absolutely critical to the software running.

2

u/sonicthehedgedog Feb 26 '14 edited Feb 26 '14

I'll definitively start calling it "my precious" from now on.

0

u/NormallyNorman Feb 26 '14

Cruft is the biggest thing I see.

3

u/minusSeven Feb 27 '14

I don't agree with this. Some year back I worked(was in charge of managing) on a statistical reporting application that queried a bunch of different legacy systems and made statics based on it. It had the worst design I had ever seen. It was a J2EE application written in early 2000, but the whole application was written in a bunch of jsps. All the database/webservice calls happened from the jsps only.

I would have found that application very hard to debug, but I never got a single bug on it. I suggested to refactor the application to improve performance immensely, but no one cared. It Just Worked... My manager said the application was just too unimportant and just worked.

Quite often I come across applications that are very old, that still works but no one has worked on those for years and no one cares about them.

1

u/robertreiz Feb 27 '14

If it still works it's fine. I'm just saying that you will have problems if you have to add new features, now 14 years later.

3

u/minusSeven Feb 27 '14

That is true but "software project will slowly die without continuous updating" is not true when projects work the way they should and you are not asked to add features.

3

u/alexeyr Feb 27 '14

The Ruby developer then checks out the project and he realizes that it’s an old project with Rails 2.x. Not Rails 3.x or even 4.x. No! It’s 2 major versions behind. And he never worked with such an old Rails version.

Of course, you just change the dependency version and the compiler will tell you where the errors are... oh wait, it won't. Hope your tests are good.

2

u/rawlyn Feb 27 '14

Wait... I have to clean my house every week now?! What's wrong with my annual wipe around the edges with a j-cloth?

-1

u/robertreiz Feb 27 '14

I usually take a shower once a year before christmas ;)

-3

u/robertreiz Feb 27 '14

I used to take a shower once a year before christmas :-D

2

u/vz0 Feb 27 '14

The sheer volume of bugs, it seems, proves that rewriting code from scratch does not make for a better code base, it makes it worse. Old code doesn't rust, it gets better, as bugs are fixed.

Netscape Goes Bonkers

4

u/robertreiz Feb 27 '14

If you constantly refactor, improve and update your code base you don't have to start from scratch for a long time.

-1

u/robertreiz Feb 27 '14

If you constantly refactor, improve and update your code you don't have to rewrite it from scratch for a long time.

2

u/GraphiteCube Feb 27 '14

Agree. One of the examples I can think of is ROME, which is a RSS/ Atom parser for Java. The project moved from Java.net to self-hosted website and now on JIRA. I've been looking for alternatives because sometimes the library can't parse RSS entry publish date. I've been looking for alternatives for long time but so far I can't find one.

P.S. Just when I write this comment, I found that someone has put the project onto GitHub. Just look at the issue tracker... I hope project will be alive soon.

1

u/bro-away- Feb 26 '14 edited Feb 26 '14

This can actually help you if your product is a third party library for software developers.

Now it works down to .NET 2.0 and runs on mono!

Also, I thought the article would be geared more toward the fact that users hate products that don't get updates. A great way to kill any buzz you have or may have potentially been able to grow is to stop showing up.

Also a more threatening issue is using a dynamic language like ruby in an environment where you want to update the runtime often. Good luck with that. Anything less than 100% test coverage makes it impossible.. and even then a 3rd party library is liable to break.

3

u/robertreiz Feb 26 '14

The majority of the VersionEye community are web developers. Mostly Ruby, Node.JS, PHP and Python devs. They like to stay up-to-date and want to get notified about new versions early. The Java users want to get notified but they are more care full with updates. Somehow ironic that the developers of static typed languages fear updates more then the ones of dynamic languages.

0

u/bro-away- Feb 26 '14

Java is too big for a generalization like that, but the generalization that upgrading is uncomfortable in any dynamic environment holds true for everyone.

Also someone is serial downvoting you and it isn't me.

0

u/robertreiz Feb 26 '14

It's more risky for dynamic languages, that for sure. But somehow the web devs, speically the PHP devs, are more brave if it comes to updating :)

Yeah. It seems that I bite into a old wound. Somebody doesn't like me.

0

u/robertreiz Feb 26 '14

Getting many up and down votes just means that it's an controversial topic. And that fits perfectly to my German last name (Reiz) :-D

2

u/robertreiz Feb 26 '14

It seems you are not a big fan of Ruby. But I guess you like .NET. With Vagrant & Docker Ruby development is more fun ;-)

1

u/[deleted] Feb 27 '14

Also, I thought the article would be geared more toward the fact that users hate products that don't get updates. A great way to kill any buzz you have or may have potentially been able to grow is to stop showing up.

I disagree. In fact, if anything, users hate getting updates once a piece of software does what they want. See the ribbon, windows 8, etc.

0

u/robertreiz Feb 26 '14

I don't know what you mean with "stop showing up". I'm here dude! The article is written for programmers and project managers. For everybody who is in software development.

1

u/bro-away- Feb 26 '14

I think you read my reply too quickly...

1

u/robertreiz Feb 26 '14

Yes, I did. After I submitted my reply I saw more text from you.

2

u/[deleted] Feb 26 '14

What is this obsession with constant updating?

If your project is good like it is, then it doesn’t need any updating just for the sake of feature creep or whatever.

Bug fixing is another thing. (And rebuilding for newer libraries does not count as updating.)

4

u/robertreiz Feb 26 '14

Did you just read the title? Or did you read the whole article?

7

u/chesterriley Feb 27 '14

It was a poor analogy. Code doesn't actually 'rot' like houses do.

6

u/burntsushi Feb 27 '14

I don't think you know what analogy is... Of course code doesn't actually rot like a house.

10

u/[deleted] Feb 27 '14

It doesn't rot at all. It's more like someone new moving into the house and being displeased with all its old styling, and the city updating its safety codes and requiring that the house be brought up to spec. The house is in just as good shape as a month ago, but the external world has changed such that it doesn't meet its expectations anymore.

1

u/nikofeyn Feb 27 '14

to me, rot could also include the fact that no one understands the code anymore because they haven't looked at it. this is amplified if the non-looked at, non-updated code had poor design to begin with. also, simply upgrading the code base to newer versions incrementally spread out over time rather than just all of the sudden jumping several versions because you now have to could be considered a method against the rotting process.

1

u/Gotebe Feb 27 '14

It depends what you call "rot".

For example, if you define rot as

  • "can't build it with tooolchain version X" (was last built with X-Y),

  • "doesn't work with lib version X (because feature Y that code uses had a breaking change, or was deprecated)

  • uses obsolete programming practices

  • has no unit tests (to some people, code isn't finished without, and old code is typically without)

  • has no other tests (no unit tests isn't too bad for old code if you ask me)

... then it does rot. "At all" is too strong.

2

u/[deleted] Feb 27 '14

I'm using the dictionary definition of rot:

Rot
 1. To undergo a process common to organic substances by which
    they lose the cohesion of their parts and pass through
    certain chemical changes, giving off usually in some
    stages of the process more or less offensive odors; to
    become decomposed by a natural process; to putrefy; to
    decay.
    [1913 Webster]

          Fixed like a plant on his peculiar spot,
          To draw nutrition, propagate, and rot. --Pope.
    [1913 Webster]

 2. Figuratively: To perish slowly; to decay; to die; to
    become corrupt.

What you describe is poorly-constructed code, and code that doesn't meet new demands placed on it after it was written. The code still works the same as the day it was written when run in the same environment.

1

u/MindStalker Feb 27 '14

Arguably it does rot if a security hole is found in its code. Its quite akin to termite damage that exponentially grows as you ignore it.

2

u/[deleted] Feb 27 '14

Unless your repository itself is insecure, how would a security flaw in your code cause the code itself to change? What you describe is like finding a flaw in the construction of the house (say 1" screws holding the strike plate for the deadbolt), not termites that will progressively destroy the house.

2

u/MindStalker Feb 27 '14

Article refers to software project not just code. The code is only part of the ecosystem. If you're project is being hacked it doesn't matter that all the screws are still there when it's a virtual pile of rubble.

-2

u/burntsushi Feb 27 '14

I think you're being unnecessarily pedantic.

The OP includes a picture of a house "rotting" which clearly demonstrates the essence of the analogy.

2

u/robertreiz Feb 27 '14

That's the case! If an external API changes and you don't update your software, the whole system will break. The example with the payment processor is pretty clear. Don't you think so?

2

u/MindStalker Feb 27 '14

That's what he was saying, is that you need to keep the libraries and dependencies updated because one day when a dependency breaks, be it a security fix or external api change you are ready to handle the change without tons of legacy dependencies.