As software developers, we often need to compromise. Budgets go short, requirements change, launch dates must be honored. Everyone in the field for more than a couple of years has plenty of examples of rushing through a project, cutting corners, skipping testing and generally delivering a suboptimal solution to hit the time or budget constraints.
But how much compromise is enough? Hard to tell as software development is not that regulated. In other fields, there is a term called “malpractice”, which means that the professional (and not necessarily the company that hires them), is legally responsible for certain types of mistakes. This ensures for example that no surgeon does half the surgery because the manager wanted it done quicker. They are liable for their work, finger pointing will not make the consequences go away. Now, luckily as an e-commerce developer, I cannot kill anyone with my mistakes. But I can lose millions of dollars. I can even make a company go under.
That’s why a while ago, I have decided that there are some lines I will not cross no matter the pressure. I would go as far as losing the job/project instead of compromising. But let me go back a bit. The first thing you need to understand as a professional developer is your role as a professional. Basically you are responsible for:
- Defining the architecture. The architecture must work. There is no point of proposing something that’s flawed from the start. A cheap car that does not work does not have any value.
- Estimating. Project Managers or CEOs have wishes on when to launch, but you are responsible for telling them if it can be done. It might not and that’s ok. You are also responsible of NOT estimating if you cannot do it. When you go a physician with an illness that does not have a definite timespan, the physician will not be promising you will be cured in one month. They will tell you to follow a treatment and check in from time to time. It will be done when it will be done. Worst words a project manager wants to hear, but sometimes that’s the truth.
- Let everyone know if you discover you were wrong. That’s a hard discussion to have, but keep in mind that everyone’s goal is a working solution. There might be consequences for you, but remember you’re the professional and must act accordingly.
Now, back to compromises. It’s hard to tell what is something that really puts the project at risk and what’s not a big deal. Especially under pressure. Personally, I have compiled a list of things that I am not compromising on:
- Always reproduce the bug first. This might be a very complex, but if I cannot do it, how can I check my solution?
- Always test all use-cases myself. While one might decide that QA by the dedicated team can be skipped, I am never skipping my own testing.
- Always take a moment to think through the security implications. Never leave a security flaw in place with the note to fix it later.
- Never cut a corner that I know I cannot uncut. It’s ok to write messier code under pressure, but only if there really is a way to go back and fix it.
I guess it ultimately boils down to being ok with the solution you provide. Not thrilled by it, not even happy, but at least ok with it. If a developer sees the code a few months later, he should be able to say that the solution is good enough.
There are of course a lot of other things I can compromise on:
- putting in extra hours to see the project through.
- implement a suboptimal solution knowing that I can go back and fix it later. Of course, with the client’s approval/understanding of the compromise.
- hard coding, code duplication, coding standards, not-so-performant solutions and everything else related to code quality, as long as the solution is still ok-ish.
Even the above compromises do not play well long-term. While they will not do major damage at any specific point in time, they add tech debt that makes the project harder and harder to work on. Each change becomes more expensive and error-prone. If the client is always in rush mode it’s ok to warn them a few times and at some point, look for another project/job. Leaving a project is never easy, but I prefer that to knowing I was the guy that slowly pushed it over the point of no return.