> The software crisis has been fading from view, because it is psychologically extremely difficult to remain in crisis mode for a protracted period (more than 20 years). Nevertheless, software – especially real-time embedded software – remains risky and is pervasive, and it is crucial not to give in to complacency.


@clacke I dunno, I'm seeing a LOT more engineers talking about the need for some serious ethics in our industry.

@feoh @clacke One of the reasons the "Software Crisis" has been fading from view is that nobody can agree on a common definition of what that crisis actually is.

@feoh @clacke In the 70s, it was a real concern over whether PLs can scale to larger software systems. In the 80s, it was cost/schedule overruns. In the 90s, it was distributed systems and independently marketable, reusable components. In the 00s, it was that every 5 years, programmers doubled in number, so there was no transmission of experience or wisdom from old to new generations of coders. In the 10s, it's exploits and their remediation, both hw and sw. Etc.

@vertigo @feoh The software engineering crisis is that software engineering isn't engineering, it's still art and craft.

@clacke @feoh That's a major contributor, but I've been able to successfully schedule and budget software development in past projects before. So, engineering practices are known to work.

I think it goes much deeper than this, and Uncle Bob Martin nailed the issue on the head.


@clacke @feoh
Civil, electrical, mechanical, et. al. forms of engineering have bodies of knowledge that change over decades, possibly centuries. Software engineering has a BOK that changes every 5 years. You *can't* evolve an engineering discipline from a field that is this volatile, *unless* you deliberately restrict your software (development) choices to well-known, well-proven sub-disciplines and tooling. The "crisis", then, seems to be its volatility, much more than its craftiness.

@vertigo @clacke I've gotta respectfully disagree. The volatility is inherent to our industry and can't be avoided. I'd argue that having a set of agreed upon ethical boundaries isn't coupled to how volatile the tech we work with is.

@feoh @clacke I think we're arguing different, non-exclusive things. So far as I'm aware, conforming to a code of ethics doesn't imply your practice is an engineering discipline. Nor the converse.

The topic was the phrase, "software crisis", a phrase that's been in the computing literature since at least the late 60s, as I recall. However, nobody has ever bothered (to my knowledge) to define what that crisis actually is.

@feoh @clacke Your emphasis on ethics is a good one, but only provides more credence to my earlier point.

With each decade, some new interpretation emerges, and it further dilutes what I believe to have once been the computing industry's first example of click-bait. Articles about the "software crisis" never solved any real problems, but it sure did sell magazines.

@vertigo @clacke That's very true. The click-bait-y articles obfuscate the real issues, but there are thoughtful people having real discussions about this. See an interview we did with "Glyph" from the Python community on the podcast I used to co-host:

@feoh @clacke To me, this is a separate, but nonetheless terribly necessary, requirement. I wouldn't've wanted to study ethics when I was younger, but I absolutely see the need for it today.

Not only ethics, but perhaps also civics as well, as those skills can be useful when running open-source projects, or any other project where you're interacting with large numbers of potentially opposed parties.

@feoh @vertigo I agree that software is inherently volatile. In civil engineering there aren't too many layers above physical and chemical limitations, and we've explored those layers for thousands of years.

In software the foundations for building your software is more software. To some extent, physical limitations offer constraints, but mostly the constraints are mathematical and the potential variations inside those constraints are mindboggling.

Part of the reason we get anything done in software at all, is that we apply artificial restraints, mostly caused by arbitrary historical happenstance, and don't explore and change those foundations every time we build something new.

Sometimes brave souls do explore and recreate parts of the foundations, and then the whole craft needs to be re-evaluated again.
@Shamar It's when people are brave and reevaluate the foundations, or just some middle-layer, that we get this volatility. That is what happens every month in Node. People using Node are very brave.

Not everything changes how creating software works, of course, a lot of it is just shuffling chairs. But some of it changes how we work and how we can combine pieces of software to new software, and that may sometimes affect our processes and best practices.

Once upon a time Object-Oriented Analysis and Object-Oriented Design were all the rage, and that wouldn't have made sense if we hadn't been writing object-oriented programs using object-oriented libraries and languages.

So yes, if we want to have the best foundations possible, we need to constantly push the envelope there, but our ability to do that is what's creating volatility.
@Shamar But if we want to achieve tried and true practices, we need a stable foundation. If we want to get stuff done in terms of solving actual non-software problems instead of navel-gazing, we need a stable foundation. There's a tension there.

That's why sometimes worse is better. Sometimes you're just building a toaster, not doing basic research on the temperature properties of wires with electrical currents.

So no, we should not always be brave. But I hope at any given time, there is always some non-empty set of people being brave.
@Shamar I don't think anyone means "the software crisis" in any other sense than "we don't quite know how to make software". That's the decades-old ongoing crisis. It's not a rationalization. Maybe it's a euphemism. I just consider it shorthand.

As for the point @vertigo makes, that the term "software crisis" seems to mean different things different decades, I think that's just us solving parts of the puzzle and encountering the next obstacle on the way to understanding how to make software.
Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!