Not that there's anything inherently wrong with these technologies, but when your language seems to be based on that way of doing things ... I think the 1990's called.

... but don't expect to find a job. Nobody actually uses Linux in Bellingham. Sorry. :)

Yes, people can always roll their own solution ... if they want to.

The developer agreed to deliver software that did X. They did not do so. Thus, they are in violation of their agreement and must make amends. Simple as that.

As to why things are often not done this way, in my experience, it is because developers desperately want the software business to be different. They don't want the traditional rules of industry to apply to them. They want to be special snowflakes, and management is letting them.

... and realizing that dicking around with what is ultimately a tool is an impediment to getting useful work done. That's the realization I had. I used to delight in building my own computers from parts ordered online, rebuilding kernels to be lean and mean, compiling all software from source, tweaking things endlessly, etc. But somewhere along the line I became more interested in what I could do with the machine rather than the machine itself. Now I just want to plug something in and go.

Being good at general scientific reasoning requires a firm understanding of scientific philosophy. This is not a subject many people encounter directly unless they're on a scientific track at a university. Very few, if any, will pick it up just from engaging in scientific activity.

Anyone can learn to program, just like anyone can learn to build a house or drive a car or bake a cake. But not everyone can learn to do these things well. The lower an industry's barrier-to-entry, the more crap people one will find working in it. Just look at the software business.

... I'm speaking of Microsoft

API-documentation comments can be a good thing. General commenting within the code itself, not so much. If one's codebase requires such comments to understand it, they've got problems.

Your entire post reeks of bad management. Anyone who initiates a project without basic boundaries is a moron. Anyone who cannot decompose tasks is unqualified to lead. Anyone who allows things to go off on tangents should be fired. It's that simple.

Happens in my company all the time, but it requires competent management and lots of discipline. The software design has to support such changes, as does the work environment. If you've got a jumble of spaghetti and a boss who just wants it done, you've got management problems. No system is going to be very effective.

Agreed 100%. If you can't stop what you're doing and fix a bug in a few minutes, you've got management issues. The only exception to this that I've encountered are the rare situations where I'm using a system and nowhere near my development environment. In those cases I use whatever communication tool seems appropriate: email to myself, voicemail to myself, note scribbled on paper, etc.

This concept works in team projects as well. If you need a tracker, you have bigger problems than software defects.

This is exactly it. Everything I ever saw from Apple on this subject said their products were immune to the large volume of PC viruses out there, which is completely and totally true. They probably changed their tune in order to avoid a waste-of-time lawsuit from people who can't read.

I think you've spent too many of those 42-years indoors.

Our society indeed has a problem with accepting half-assed work. In my experience, employees and managers alike just want to be able to say something is done regardless of whether or not it really is. Few seem to show concern for doing a good job, and those who do are ridiculed for it.