Software Developers, Stick To Your Principles!
As a former Software Developer, Architect and now Manager, I have been faced with some interesting decisions over my career. Some decisions like what software stack to use or what framework to leverage or what pattern to implement were easy decisions. But forget about the easy decisions, let’s talk about the hard ones.
I’m not talking about things like what to do about discrimination, workplace bullying or passive aggressive retaliation (although, there’s a good chance you’ll experience those things at some point during your career). I’m talking about the kind of the decisions that can make you question your own professional integrity.
To level set, nobody makes perfect software. And if you are working for someone else, the amount of control you have over what software you produce and how you produce it is limited. I think it’s reasonable to expect to have input into how your work is done. I think it’s even reasonable to expect to be proud of the work you produce. But there is an element of give and take.
Sometimes you will make mistakes. Mistakes are OK. Mistakes are how you learn.
However, other times you may be pressured to do things that are damaging, either to your reputation or to that of your organization’s. Mistakes are one thing, but knowingly publishing or releasing something that is of poor quality or that has a high probability of failure is an entirely different thing. This is best explained using an example:
Example
You’re the lead software engineer on a high profile software project that is behind schedule due to various factors. One of those factors is that it turns out a piece of 3rd party software that your project integrates with has a known critical bug that at best, will make the entire system unstable and at worst, will result in a total system failure that could cause reputational damage for you and the organization in which you work.
The project has an internal deadline for completion scheduled in 4 weeks and the deadline has already slipped once. It cannot slip again. However, you know that the 3rd party software won’t be fixed in time and there is not enough time to pivot to a different 3rd party (or internally developed) software product before the deadline.
The root problem is a failure of product ownership and of project management — clearly this is not something that should have popped up at the last minute. But the focus now is on getting it done. Directors aren’t going to get it done. A project manager isn’t going to get it done. The product owner isn’t going to get it done. No, you, the lead software engineer are either going to facilitate and participate in getting it done or you won’t. What is a person who’s on the hook for a problem that someone else created to do?
**Note: this kind of situation will happen to you more than once.
Options
- Be the Hero: You can try to be the hero. You can work day and night to try to patch what may be an un-patchable problem (within the specified deadline).
- Push Something Out: It may not work. But hey, at least something will be released by the deadline.
- Object: Inject a hard dose of reality into all the people who don’t want to hear it.
I’d like to tell you that in these kind of situations, I always chose #3. But that would not be true. There were times when I chose #1 and there were other times when I chose #2. That’s how I learned that #3 was the way to go. Why?
I started my tech career in consulting, where you were expected to be the hero. Heck, you got rewarded for being the hero and performance was measured in terms of hours spent in the office. The problem with being the hero, however, is that what you produce is never as good as it could have been if you weren’t in “get ‘er done” hero mode.
You tell yourself (and everyone else) that you’ll clean it up later. But later never comes, because if it ain’t broke, don’t fix it. And you didn’t have the time before, so what makes you think you’ll have the time later? Also, part of that lack of time comes from your never ending patchwork dance on what was frankly just a patch to begin with — you wanted to be the hero; you own it now!
Just pushing something out is also known as the hope and pray approach. And for some reason, many people find that to be a perfectly acceptable approach. And nearly every time, it has perfectly predictable results: failure.
Honestly, the hope and pray approach is not that different from the hero approach. Neither one is well thought through and both are essentially just a scramble down a path to misery. The reason for both the hero approach and the hope and pray approach is the belief that there is no choice — it has to get done now. There is always a choice.
The third option is to object. Objection means speaking the truth and refusing to be a passenger down a road to ruin. It is not failure. It is honesty. And honesty like that requires sticking to your principles.
Sticking To Your Principles
Do you think anybody really wants to stand something up just to watch it fall over? What is the consequence of that verses missing the deadline, getting a plan together, and standing up a system that has a good chance of being successful? What will standing up a system just to watch it fall over mean for your own reputation? What does that say about your professional integrity? You may not have created this problem, but if you support a direction that you know has a high probability of failure, then you own that decision.
However, if you speak up, if you pump the brakes on the crazy train and tell those who want you to do their dirty work for them, “We should not release a broken system just to claim a nearsighted victory. If you decide to move forward then you do so against the recommendation of your lead software engineer, knowing that there is a high probability of system failure.” then you may just end up being the hero after all.
As a manager, I can tell you that running over the top of my technical lead is not something I ever want to do. The message that you send when you do something like that is “I know the technical particulars better than the person whose job it is to know the technical particulars.” Generally, that is not the case, if ever.
Another issue is that when you run over someone, you also tell them that their opinion doesn’t carry any weight. It’s akin to telling someone that you don’t care about them or what they have to offer. It’s not the kind of message that helps to establish and/or grow trust. Finally, what manager wants to explain how he or she made a call against the recommendation of their technical lead that resulted in a failure? Not me!
Conclusion
If you haven’t come across a situation in your career as a software developer where you were pressured to deliver poor quality software or a system that had a high probability of failure then be patient. You will. For everyone else, being the unpopular voice is hard. But if it’s the difference between something you can be proud of and something you will be ashamed of, then be the voice of dissent. You just might make a difference for your organization. At the very least, you will be regarded by some as honest and principled. And that’s not such a bad thing.
