7 ms·
I agree that the best possible answer to management would have been, "It'll take six days by the book, or if you approve some emergency rulebreaking and the iss
by raldi 10y ago
I agree that the best possible answer to management would have been, "It'll take six days by the book, or if you approve some emergency rulebreaking and the issuance of technical debt, I can have it done in an hour. And then it'll take six days to clean up."
Then the boss can make an informed decision.
- beat 10y agoYes, this. Provide options to management, with risk analysis, so they can make a decision. Management's priorities are not always the same as development's priorities. The important thing here is to provide the risk-assessed alternative in writing. This covers the asses of both sides! If something blows up and management was not warned about the possibility, they're well within their rights to rake the engineers over the coals for it. But if engineers warn management of the potential consequences and management chooses to take the risk, if it blows up, you have your CYA right there - they were warned in writing.
- imagist 10y agoThis works if you trust your manager to take responsibility for the decision, which you often (usually?) can't. If you can't trust your manager to take responsibility for the decision, then it's better to make a decision you're going to be held accountable for than to let your manager make the decision and then hold you accountable. I've seen other engineers in the position where they give a risk analysis and warning in writing, and then shit hits the fan and they get fired. Maybe it doesn't happen immediately, maybe the reason they were fired isn't explicit, but the change in the manager's attitude toward the engineer traces back to when they did what the manager said. There are also mangers who won't follow through on the tech debt part because they don't trust their engineers even if their engineers are trustworthy. When they discover that they can bypass testing by pulling the emergency lever, they'll start pulling it all the time because they see it as a way to get what those lazy engineers to do their jobs faster. And when tech debt catches up with you, bugs abound, and development slows to a crawl, the engineers get blamed. Maybe you have a boss you can trust to take responsibility for their risky decisions. Maybe your boss trusts you when you say that paying down tech debt is necessary. But maybe your boss and their boss don't have the same relationship, and the shit rolls down hill. Yes, I want to work in a trusting environment where my interests are aligned with doing what's best for my company, but an at-will employment capitalist economy doesn't always work that way. It's every man for himself at a fundamental level, and exceptions to that are too rare to make a blanket claim that people should just do what's best for their company.
- beat 10y agoIf you can't trust your boss to not scapegoat you when you provide a risk analysis in writing, you need another job.
- imagist 10y agoEh, it's not all that big of a problem of you know how to deal with it (protect your own interests, not the company's, by making conservative choices as I described above). I work 35 hours a week, make $125k/year, have good benefits, like most of my coworkers, and am doing relatively interesting work for a company that isn't completely evil. Sure, my boss can scapegoat me if I let him make technical decisions, but I don't. That's a tradeoff I'm okay with. I'm always on the lookout for something better but I'm happy where I am. And besides, most people who think their bosses won't scapegoat them if something goes wrong are naive. If it's your job or theirs and they have the power, you're screwed. It's better to avoid the risk and not put yourself in that situation. To be clear, I'm not saying don't take risks. I'm saying wroth risks on your own behalf.
- pmoriarty 10y ago"Yes, I want to work in a trusting environment where my interests are aligned with doing what's best for my company, but an at-will employment capitalist economy doesn't always work that way." What economy does work that way?
- 10y ago
- hinkley 10y agoIt's important not to understate the fact that both options are a false choice. you can have it the right way Plan A, or the right way Plan B. There was no offer of a Plan C where we hack stuff and then just hope for the best. Plan C is what the Strategy guys always want to go for, because they can't recognize when the repucussions happen. They just tell themselves it's those good for nothing engineers screwing up again. But too often there's been one guy ithe engineering group who values accolades over stability and will offer to be a hero, only to wander off without finishing anything. Later in life I've realized I should have suffered through more of the issues at companies where the team at least had solidarity. I knew I wanted that in a team, but didn't know that I needed it.
- beat 10y agoThat's why you don't offer a Plan C. There's a fast-but-dangerous Plan B, with a risk analysis. You've warned them what can happen, in writing. Now, if something goes wrong that you didn't warn about, there could be other repercussions, but that's still better than not warning them at all, which easily makes you the "But no one told me this could happen!" scapegoat. Plan C doesn't differ from Plan B in terms of technical approach. It differs in terms of the consequences of failure - not the technical consequences, but the political consequences. My first really interesting project that led me down the sort of DevOps/Agile trail was in the mid-1990s, when I helped write a risk management and contingency planning process for the mid-sized company where I worked. One of the features of the process was that management could not reject a risk analysis on any grounds except incompleteness. They couldn't say "I don't want that written down!" They had to sign off on it, in writing. This turned out to be very popular with both teams and management. Teams felt they were finally getting the opportunity to cover their asses, and management finally felt like they were getting straight answers from the teams about actual risks. In the earlier lack of process, teams were at least passively discouraged from honest, written risk analysis, as naysayers who were resisting business opportunities. Worse, if a warning was given and then the problem happened, the people who warned were blamed for not preventing the problem! When we beta-tested the analysis process, the first project that tried it actually turned down business because it was too risky. That had never happened before. We probably saved the company many millions.
- edoceo 10y agoManager agrees, rulebreaking then fix later. Later...never arrived for tomorrow is another Very Important Thing that must be done now! Somehow management continues to forget the critical resource: time to do things right
- marcelvaldez 10y agoYeah, but the problem is that managers are not engineers, they want "results" and do not have sufficient software engineering knowledge to be aware of the effects of making this type of decisions over and over again. Eventually the software engineering department has a code base that is riddled with tech debt, to a point where changing a 3 into a 4 ACTUALLY takes 6 days. Then management asks "WTF? What did you do? Why does it take 6 days to turn a 3 into a 4?", next comes frustration and SWEs leave the company. I've seen this happen at 3 different companies in 3 different industries, a huge company (hundreds of devs), a medium company (50 devs), and a small company (2 devs) [1]. Every time it happened, it was because a SWE team was constantly delivering under pressure by management that disregarded the cost of writing code "that works" without ever addressing tech-debt, no matter how much the SWEs warned management. [1] To be fair the small company only fell into that anti-pattern because neither the engineers nor the managers knew any better.
- raldi 10y agoPerhaps the reason you've seen this phenomenon everywhere is that the companies that don't do it tend to fail, whereas the companies that do tend to succeed and grow and hire people like you.
- taneq 10y agoThis was one of the most important lessons I learned at my first job out of university. Beautiful, well structured, clear, simple code is nice, but the customer doesn't give a shit about it. All the customer cares about is that your product solves their problem. By all means, if you have additional resources, invest them in refactoring and improvements and additional testing and continuous integration and all those things that make our days enjoyable and our product quality high. But your first priority has to be making sure that your product solves your customer's problem.
- dustinmoris 10y agoI disagree with this. Management doesn't need to micro-manage everything, that's certainly not their job role. This was a simple change in an internal system. Yes, maybe this minor super isolated change could have broken something in some parallel world, but the stuff it would have broken is not an airplane computer or a heart machine. Bloody hell, sometimes it is important to put things into context. Engineers get paid a hell lot of money and you would expect that someone with that qualification and level of experience would be capable to make smart decisions independently without being micro-managed by a manager all the time. After all the engineer is the real expert of his/her code and can make a much better assessment of the impact of the change than the manager, so freaking do it! That's what you get paid for! Seriously, there was no excuse for this to take 6 days.
- Too 10y agoThis handshake adds yet another day to the process though.
- mcv 10y agoIncreasing the backlog by a month is not so urgent that 6 days is a problem. It's useful to have a process in place for more urgent hotfixes in production, but I don't see why that would be needed for this particular case. And rushing changes for a mission critical system can be very dangerous.