Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Is Drowning the World

jamesabley.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Software Is Drowning the World

#31

Post by xyzelement »

bsenftner wrote: post #4

I think a real issue we developers face is the management and client attitude that software does not require maintenance. Time and time again, the fact that our completed projects require maintenance or they simply fail with newer systems is greeted with shock, debate and accusation of deceit.

Have you tried explaining it in a different way to them?

Imagine you brought your car for an oil change and the mechanic says "uhh yeah maybe you can get new oil next year but for the next few months we need to... Uh... Address technical debt in your car... So umm... It's gonna cost you thousands of dollars and you aren't going to get anything you perceive as a change"

You'd think they are ripping you off.

Re: Software Is Drowning the World

#33

Post by valenterry »

This is one of the reasons why statically typed languages have a big advantage when it comes to maintenance.

Take Scala for example. There is now mature tooling for keeping your dependencies / libraries up-to-date automatically, using automatic migration-scripts (must be provided by the library author of course).

See here: https://github.com/scala-steward-org/scala-steward/blob/mast...

The difficult part here is of course to write the migrations. This works very well in Scala (and can work as well in certain other languages) because the type-system provides enough information to do automatic rewrites and it is easy to _not_ use unsound techniques such as reflection, code generation, macros etc.

The reason why we don't see such tooling in other languages yet is that they are either dynamically typed, which makes it almost impossible to write migration scripts that pretty much always work. Or they are statically typed but the typesystem is so limited that developers have to fall back on mentioned unsound features.

Re: Software Is Drowning the World

#34

Post by pdimitar »

valenterry wrote: post #33

This is one of the reasons why statically typed languages have a big advantage when it comes to maintenance. Take Scala for example. There is now mature tooling for keeping your dependencies / libraries up-to-date automatically, using automatic migration-scripts (must be provided by the library author of course). See here: https://github.com/scala-steward-org/scala-steward/blob/mast... The difficult part here is of c…

That was basically my main reason to learn Rust (okay, mega-speed is another but it wasn't the first): no matter the syntax, no matter how hard it is to learn in general, no matter how hard to learn and use all the idioms is, you have a very strict language that makes it that much easier to automatically refactor.

...Or at least I hope that will be the case in the future. But like you, I believe it's much better positioned to do so compared to the dynamically-typed languages.

Re: Software Is Drowning the World

#35

Post by gonzo41 »

jrochkind1 wrote: post #26

> Every time you decide to solve a problem with code, you are committing part of your future capacity to maintaining and operating that code. Software is never done. I am clipping this for use in future internal discussions. I have trouble communicating this point, this sentence does so concisely.

It'd be better to start off project with a depreciation schedule on software. Such as discussing plans for ROI after 5 years etc. Past that point, maintenance needs to be considered new work, and billed as a new project.

We've got to stop thinking about software in agile sprints once a product exists. I'm not saying don't use agile for the build. But we've got to learn as software professionals to think like professions that maintain other expensive assets, such as aircraft, ships, or public works. There's a recognition, that a 50 year dam, needs a tear down and replacement in 50 years.

Re: Software Is Drowning the World

#36

Post by gchamonlive »

pdimitar wrote: post #29
gchamonlive wrote: post #20

I think computation is still converging. It is too new to be expected to abide to universal standards. Cars, for instance have been around for over a century and they are still subject to change in standards, mainly because of safety and efficiency, just like software, but to a different degree. We should, however, have these kinds of discussion because I don't think we should outsource this debate to corporations. B…

The problem is financial incentives. I am not paid to devise such universal tooling. It's also a huge undertaking and much harder than all of my everyday's work. It's exploratory work that has the potential to revolutionize huge chunks of the programming area. And I don't want to only be paid an average salary for it. But... an excellent salary (above-average, maybe even above-high) would motivate me and no, I won't…

I think this is part of the problem, yes, but the root is more fundamental in my opinion.

Even if you had a lot of financial support, how would you go about implementing the standards and transformations described in the article? Who would adopt it?

Maybe in the context of a company this could reap benefits and become a case study. Or in a partnership between many companies there could arise such applications. But they would still be locked to a niche. That is why I think even with financial support, the problem is maturity, or lack thereof.

You could argue that once a large enough group adopted practices that proved to be effective in reducing maintenance time and complexity, that others would follow, but that stops being a matter of pure financial support and starts being a matter of adoption and convergence, pointing once again to maturity of the ecosystem.

And another aspect of maturity, standardization and sanitization is that it comes at a cost to diversity, which in turn has benefits of its own, like new ideas and technology. This is kind of the balance between exploration and exploitation we see in training neural networks. I think software is in the transitioning phase from exploration to exploitation and we are living it.

Re: Software Is Drowning the World

#37

Post by Micoloth »

stupidcar wrote: post #2

Things break down and things eventually need to be replaced. This has been a fact of life since time immemorial. I do tire of programmers acting as if the necessity of maintenance is some novel and unexpected problem, unique to software development, presented with hyperbolic titles like "software is drowning the world". Is physical infrastructure "drowning the world" because it needs to be maintained?

To be fair, I don't agree with this point of view at all.

Things in the physical world break down beacuse they are made of matter, and the entire concept of "working" is a very simplified modeling of their behaviour that doesn't include second-order effects like tear,consumption of materials etc.

Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. The _only_ reason we still don't have a reliable and solid code infrastructure (in the sense explained by the article) is our inability as a community to once and for all define a solid foundation for the principles of computing. Hence all the hacked together languages, tools and frameworks that people have piled on each other over the decades.

If one century of efforts hasn't been enough, fine. But we absolutely can work towards that goal.

Re: Software Is Drowning the World

#38

Post by pdimitar »

gchamonlive wrote: post #36
pdimitar wrote: post #29

Earlier quoted context omitted.

The problem is financial incentives. I am not paid to devise such universal tooling. It's also a huge undertaking and much harder than all of my everyday's work. It's exploratory work that has the potential to revolutionize huge chunks of the programming area. And I don't want to only be paid an average salary for it. But... an excellent salary (above-average, maybe even above-high) would motivate me and no, I won't…

I think this is part of the problem, yes, but the root is more fundamental in my opinion. Even if you had a lot of financial support, how would you go about implementing the standards and transformations described in the article? Who would adopt it? Maybe in the context of a company this could reap benefits and become a case study. Or in a partnership between many companies there could arise such applications. But th…

Oh, I am with you on this as well. My point is that we never get to the point where network effects (or lack thereof) is the problem to solve. Since nobody is financing the work we simply never get to find out if a proposed external tool would be accepted by the community or not. That's the disappointing part. We never had the problem to begin with.

IMO if you make such a tool for something extremely popular like Python or Javascript and then start pivoting upwards from there, people will be coming to you. There are a lot of deficiencies in the everyday work of the programmer to this day.

Re: Software Is Drowning the World

#39

Post by enriquto »

jrochkind1 wrote: post #26

> Every time you decide to solve a problem with code, you are committing part of your future capacity to maintaining and operating that code. Software is never done. I am clipping this for use in future internal discussions. I have trouble communicating this point, this sentence does so concisely.

> Every time you decide to solve a problem with code, you are committing part of your future capacity to maintaining and operating that code. Software is never done.

Notice that this includes using code written by other people (e.g., dependencies).

Re: Software Is Drowning the World

#40

Post by gchamonlive »

pdimitar wrote: post #38
gchamonlive wrote: post #36

Earlier quoted context omitted.

I think this is part of the problem, yes, but the root is more fundamental in my opinion. Even if you had a lot of financial support, how would you go about implementing the standards and transformations described in the article? Who would adopt it? Maybe in the context of a company this could reap benefits and become a case study. Or in a partnership between many companies there could arise such applications. But th…

Oh, I am with you on this as well. My point is that we never get to the point where network effects (or lack thereof) is the problem to solve. Since nobody is financing the work we simply never get to find out if a proposed external tool would be accepted by the community or not. That's the disappointing part. We never had the problem to begin with. IMO if you make such a tool for something extremely popular like Pyt…

This is indeed a massive undertaking. Beyond this point I can only speculate, but it is really interesting to have these kinds of debates.
Post reply on HN