| |
| ▲ | ninkendo 2 days ago | parent [-] | | It certainly should be the most difficult engineering on the planet, yes… but IME the standards for quality are so low that it’s a pretty easy gig. You’re expected to slap together stuff that barely works and fix things later. That’s now how any other engineering discipline works, or at least not nearly to the same degree. Also it’s hard to observe how hacky software is from the outside, so it’s easy to get away with a terrible mess of code that would nauseate anyone who looked at it. Most of the time management doesn’t even care. Watching Practical Engineering on YouTube is a pretty illuminating experience for me as it as it shows the extreme care that goes into projects from the outset, how much planning is involved, how much we’ve learned from centuries of experience building things, and how even despite all of this, things can still fail spectacularly. And when it does, there are independent reports done by thorough investigators, who find the real root causes and carry the knowledge forward for future projects. It makes me sad that Software isn’t treated this way. Yes, we get things off the ground fast, but we don’t learn from our mistakes, we don’t conduct thorough investigations into failures, and often people just release things and move on to the next job. Software may be a more complicated and “difficult” discipline but it sure isn’t treated like it. | | |
| ▲ | MrMcCall 2 days ago | parent | next [-] | | Its difficulty and uniqueness is why it just hasn't been 'engineerized' or 'engineerified' yet. It's still a craft, as opposed to an engineering discipline. As such, that means the quality of the software produced by any shop is going to vary according to the organization's standards, which is their combination of management and engineers. Sometimes management is very business-schooly in their perspective, sometimes more engineery. That boundary layer and how it is treated by the top of the hierarchy makes all the difference. I was summer programming in an IT department in the late 80's; it was under the auspices of the comptroller, simply because the org didn't know where else to put it. Management was still figuring out which department would have the budget/cost stuff allocated to it. You can forget about engineering excellence or even semblance of IT knowledge. Everything since then has been the (in)organic growth of IT in the situation that, for the vast majority of companies, IT is simply a cost whose benefit is hard to quantify, especially to the money guys, who are always the ones in charge. | |
| ▲ | jart 2 days ago | parent | prev [-] | | Planning and "extreme care" makes sense if you're building a bridge. Professional software engineering is more like a demolition derby. If you want to be successful you should focus on building fast and breaking things. It wouldn't make sense to blow up a bridge right after you've constructed it, but with software you can do just that. For example, I was just using American Fuzzy Lop a moment ago to break my symbol demangler. It was able to find eight ways to make it crash in a minute. So I fixed all those and let it run for a couple hours and it found another. Tools like this are a superpower. It's also fun to write torture tests and DDOS your own infrastructure. If you don't break it then someone else will. |
|
|
