-1

For example:

  • After I've learned about SQL injections I realized that in past projects I didn't check user inputs for SQL injections.
  • After I've learned about PKCE I realized that in past projects I didn't use PKCE in OAuth 2.0.

Each time I have these enlightenments, I feel bad about my past projects. My inner voice says to me: "How dare you event start working on it if you didn't know this?".

Is it just normal flow of how software developer grows? If so, does that mean that we legalize wrong things we do in our projects?

In the other hand "we don't know what we don't know" and I think this shouldn't stop us from doing the job.

Nick Rogan
  • 29
  • 1
  • 3
    No one is born with all the knowledge. You learn as you go and will make mistakes. The problem is when you don't learn from your mistakes. – MetalMikester Mar 18 '24 at 13:48
  • @MetalMikester tell that to construction or aviation engineer – Basilevs Mar 18 '24 at 14:00
  • 1
    Are you working as a sole developer or as part of a team? In a professional environment, these things should be caught as part of the design and/or code review process. – Philip Kendall Mar 18 '24 at 14:06
  • Duplicate of What needs to change for Software Engineering to become a formal profession? – Basilevs Mar 18 '24 at 14:23
  • 1
    @Basilevs: that might be seen as related, but it is definitely a different question. – Doc Brown Mar 18 '24 at 14:31
  • @DocBrown OP would not ask the question, if he had a diploma, and a stamped protocol of government inspection on hand. – Basilevs Mar 18 '24 at 14:35
  • 1
    @Basilevs, when was the company lawyer or company secretary, last expected to look after their own burglar alarm? There are many reasons why software development should have better professional training, but in the case of computer security, the real issue is that it shouldn't even be regarded as the same occupation as computer programming. – Steve Mar 18 '24 at 14:53
  • @Steve, company executives are responsible for hiring decisions. They can't hire an engineer without credentials and apply for certifications. – Basilevs Mar 18 '24 at 14:59
  • @Basilevs They make mistakes too. That's why some buildings or other infrastructure collapse, or why planes crash. In an ideal world, all mistakes would be caught (either by, say, the developer, or by code reviewers and/or QA), but it's not an ideal world. Ultimately the point is, it's not because you made mistakes in the past that you should find another field of work or shy away from new challenges (new tech, etc). Ideally you have someone with better knowledge double checking your work, but... again, not an ideal world. – MetalMikester Mar 18 '24 at 15:03
  • @MetalMikester I agree. In non-ideal world we have to fall back to correctional system. Note, that we jail executives, not inexperienced engineers. – Basilevs Mar 18 '24 at 15:06
  • BTW, in established industries, it is impossible to "make a mistake" in a lawful manner. This is (in part) why it takes so long to get permits for anything.

    Take for example Boeing crashes - they had a deal with a regulator. Another example is https://en.wikipedia.org/wiki/Titan_submersible_implosion where other corners were cut.

     – Basilevs Mar 18 '24 at 15:09
  • A developer's education background and paper qualifications are irrelevant and do not indicate anything about their ability do their job correctly. in highly regulated industries, there are already laws requiring a mountain of checks and measures in-place to assure development work is done correctly -- in reality, employers ensure these checks happen and there are competent people acting as gatekeepers who review, test and check all the work done multiple times, ensure it meets all the required standards, question anything they aren't expecting to find, reject the work if necessary, etc. – Ben Cottrell Mar 18 '24 at 21:22
  • @BenCottrell, how would they chose "competent people" then? – Basilevs Mar 19 '24 at 08:31
  • @Basilevs Typically by focusing on the person's hands-on ability and real-world experience rather than academic credentials. Which is generally what happens in every company I've ever worked at. Even if someone unsuitable slips through the interview, employers usually have a short initial probation period where they are just getting up-to-speed and given less responsibility; it doesn't take very long while actively working with someone, to figure out whether or not they are up to the job. The gatekeepers are generally trusted employees who have already proven themselves at work. – Ben Cottrell Mar 19 '24 at 08:38
  • @BenCottrell I would not want to live in a country, where a professional credentials are just hearsay and have no paper trail. I assure you that most homeopathy specialists have a lot of real world experience. – Basilevs Mar 19 '24 at 08:42
  • @Basilevs Nice strawman, but that has nothing to do with the topic being discussed here. We're talking about software engineering for safety-critical systems, which is completely different as I mentioned above, because the companies who own and build these systems are subject to a lot of laws and regulations which have a lot of lengthy, time-consuming quality and safety checks and processes in-place. The paper qualifications and academic credentials of a single engineer do not matter in such an environment. This is not a field where expertise is taught in a classroom. – Ben Cottrell Mar 19 '24 at 08:45
  • @Basilevs Medicine on the other hand is nearly always usually a short (sometimes as little as 15 minutes) private, confidential face-to-face consultation, or small team, often requiring immediate action/decisions - no time for peer reviews or guardians/gatekeepers to do in-depth reviews of the medical decision; they have to make a snap decision in the moment. In this situation, professional credentials are used because it's not viable to delay urgent patient care by gatekeeping the process, as all that would do is lead to harm for the patient. – Ben Cottrell Mar 19 '24 at 09:04
  • Let us continue this discussion in chat. – Basilevs Mar 19 '24 at 10:52

4 Answers4

4

We all make mistakes, and feeling bad about them is quite normal. However, at some point it is better to put the bad feelings aside and look at this from a professional point of view.

Do you have warranty or maintenance obligations for these past projects which are still in place? If you are the software vendor, you should consider to make a risk analysis, and in case the risk is high enough your design flaws could cause some serious issues, you hopefully decide to fix the issues, inform your customers and provide an update. In case you are just one team member in a larger software organization, you can inform your superiors and leave this to them.

If you don't have any warranty obligations for these past projects, then don't bother - just learn from your mistakes. Software for which security breaches can cause severe damage should always be subject of an obligation of the software vendor to provide updates. It is the customers responsibility to establish a contract or other kind of measures which gurantees them to get these updates. If they forgot this, sooner or later they will learn it the hard way they have to care for updates.

When you want to establish a long-lasting customer relationship, or don't want to risk loss of reputation when someone else detects your faults at a later point in time, you may consider to deliver an update even when there are no warranty obligations.

All-in-all, these are business decisions, not really software engineering decisions, so treat them as such.

Doc Brown
  • 206,877
2

I wouldn't worry.

If you hired a person to design say a biscuit production line, you wouldn't typically expect that person to involve themselves in the problem of what happens if someone feeds arbitrary sewage into the line instead of good food ingredients, or attacks the machinery with hammers, or steals the ingredients from the forecourt.

You especially wouldn't expect a (typically) young and inexperienced engineer, working single-handedly, to design a machine (or an ordered factory environment) that was completely resilient to all those kinds of malicious attacks on the biscuit-making machinery. It would be the responsibility of a large organisation of people, including senior managers in all kinds of specialist functions, and reinforced by the facilities which the state provides (who provide police, judiciary, buildings inspectors, health and safety inspectors, factory inspectors, etc.).

Experienced programmers might be able to avoid the most blatant dangers and invitations to mischief, but only because they're more familiar by rote with a popularly-known list of bad practices. These are typically evangelised by public figures, who are either security specialists in the computer industry, or they are corporate managers who are themselves the most recent victims of a specific security hole. Or, like with Bobby Tables and SQL injection, a comic strip/meme that has become well-known because it is funny.

Experienced programmers are not much better than novices at analysing and solving overall security from first principles, which is a deeply expert area.

So don't be so hard on yourself.

Steve
  • 8,715
-1

I think there is some misunderstanding on your side. If you don’t realise that you did things wrong in the past, that’s when you should worry.

gnasher729
  • 44,814
  • 4
  • 64
  • 126
-2

This is not a personal problem, just a symptom of a young and unrefined industry. Laws for established industries prevent them from producing a subpar product. They have standards, certifications, licenses, inspections, mandatory education.

In a hypothetical future, education and tooling would be mandatory and a business would lose their license for leaking customer data or failing to account for CSRF.

None of that applies to software engineering yet.

Consider yourself an artisan - you produce an "art and craft" product without any guarantees or protections for the end user. As long as you and your end user agree on a level of quality ("provided as is"), there would not be any anguish.

It is important to remember, that "artisan" approach does not apply when working for health and safety industries.

Basilevs
  • 1,665
  • 11
  • 14
  • In that future, you would be fired with demerit and would sue the university for uncertified cirriculum. – Basilevs Mar 18 '24 at 14:20