5 ms·

Appreciate 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-u

Appreciate 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 ago
In 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.

gregjor 6y ago

In 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.