3 ms·
Because software development, unlike plumbing, does not have an agreed-upon set of core skills or best practices. We don’t know how to measure software quality
by gregjor 6y ago
Because software development, unlike plumbing, does not have an agreed-upon set of core skills or best practices. We don’t know how to measure software quality or reliability. We struggle with the hiring process. We can’t define or measure programmer productivity.
These problems are old and well-known. Multiple attempts at certifications and core skills have fallen flat, partly because demand outstrips supply, partly because the languages and tools move so fast.
That said, we’ve probably all had the experience of the car that won’t start, the electrical outlet that doesn’t work, the door that sticks in the frame. Shit happens and it’s not necessarily because of widespread incompetence. Be careful extrapolating from a small sample. I’ve been in the software dev business for 40+ years. I’m amazed that our code works as well as it does, because I know what it probably looks like.
Programming is hard. While I agree somewhat that programming, and web development in particular, has attracted a lot of people with questionable skills and little experience, I don’t have a solution.
For the specific problem you described, a password manager eliminates most of those problems.
- cphoover 6y agoAppreciate the insight from someone who has been in the industry for as long as you. > Because software development, unlike plumbing, does not have an agreed-upon set of core skills or best practices. We don’t know how to measure software quality or reliability. We struggle with the hiring process. We can’t define or measure programmer productivity. I wonder if this partially has to do with maturity? You say you have been in the business for 40+ years which is very long for this industry. Relatively some disciplines are much older. I think though there are de-facto industry standards for many software system design choices. They may not be enforced but are understood. E.G do not store your passwords in plain-text, use a salt to prevent utilization of rainbow/lookup tables for hash-cracking, Parameterize database queries, backup essential data, don't log sensitive data... etc > For the specific problem you described, a password manager eliminates most of those problems. I'm not sure how a password manager would help if their authentication service was failing which seemed to be the problem.
- gregjor 6y agoIn software development we have some things understood as universal best practices, such as encapsulation, locality of reference, using good names. And we have a much larger set of specific best practices that change fairly often, or have multiple implementations. Password management is an example. Teladoc could, for example, email a link to log you in rather than using a password reset system, or maybe an outsourced authentication system. Systems tend to have problems at the boundaries. That’s true in software and plumbing. Modern software systems have lots of boundaries, both between internal modules and applications and with external services. Programmers don’t usually have control over the landscape their code runs in. Errors are infrequent so they either get ignored/not accounted for, or they send the user into a maze of confusing behavior. What you perceived as a failure to reset a password could have any number of causes, from a database table primary key overflowing to network latency to a glitch in a string library. There might not be an obvious smoking gun bad chunk of code written by an amateur to blame. I do see programmers who have no interest in their craft and don’t know what they’re doing. I see a lot more who don’t have a lot of experience, putting their mental effort into learning nuts-and-bolts stuff like languages, libraries, frameworks, APIs. Even very experienced programmers can’t possibly keep all of the details straight, or think through all of the possibilities. A lot has been written about writing better code, and making teams work together, and how psychology plays out in software development. You can find books on the subject going back to the 1960s. As Fred Brooks wrote, there’s no silver bullet.