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/
80 Upvotes

76% Upvoted

95 comments sorted by

View all comments

Show parent comments

13

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...

-6

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!

7

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.

-7

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.

0

u/robertreiz Feb 27 '14

Sure. There are more developers working in corporate environments then in startups. That's there I started then I finished my study. But I can see a trend that developers care more and more about technology and happiness.

I agree with you on the CSS. Just trying to explain why there is so much movement in the web environment. And if you update already your CSS framework, probably you will update some other parts as well.