8 ms·

I agree with your assessment that the primary reason we write unit tests is to be able to quickly make changes in the future without fear of breaking something:

by raldi 10y ago

I agree with your assessment that the primary reason we write unit tests is to be able to quickly make changes in the future without fear of breaking something: You do some extra work today so that you can save a tiny bit of work (and worry) tomorrow, and over time that accumulated future benefit outweighs the penalty paid today. However, many in the industry forget that this is the underlying reasoning, as seen just two days ago here on this site. Read through the top-rated comments on this post: https://news.ycombinator.com/item?id=13119138 https://news.ycombinator.com/item?id=13119138 They describe an emergency situation where a single "3" needed to be changed to "4" ASAP or people would lose their jobs, and everyone's applauding the gatekeepers who insisted on significant refactoring and the creation of additional tests before the change could be approved. I agree with those who say those improvements should maybe have been demanded immediately after the fire was out, but those who would have delayed the firefighting out of blind allegiance to the rules seemed, to me, to have forgotten that the rules are there to serve the programmers (particularly, their ability to quickly ship working code), and not the other way around. A rule that's failing to do that should be changed or ignored.

wnevets 10y ago
Everything in moderation.
- codeduck 10y ago
  including moderation.
- nurettin 10y ago
  That's rather extreme.
- matthewmorgan 10y ago
  I prefer a slightly different translation of that Ancient Greek saying: nothing too much
- 0xdeadbeefbabe 10y ago
  For a moderate amount of everything.
bluesign 10y ago
I think the linked thread is good example, changing 3 to 4 can seems minor, but i think even with rules in place, it is not a burning 'fire', it should be easily acceptable to run this with rules enforced in a day or two. Letting people to override rules is more damage in long run for sure. Maybe they would override next time when they shouldnt
- raldi 10y ago
  Sorry, but you don't get to make that call; it's the CEO's job, and the CEO said it needed to be done immediately, not in "a day or two".
  - switchbak 10y ago
    Having read that article, I do agree - but the requested change, while being "one line", could have unforeseen consequences that could also have a very negative effect on the business. I'm thinking that the CEO wouldn't take the blame for that though. But if people's jobs were truly on the line, I'm inclined to agree with the "screw it, push it through" approach.
  - didibus 10y ago
    I wholeheartedly disagree. In fact, I believe that's the difference between an engineer and a programmer. If you are hired as a programmer, then yes, just do whatever we ask of you. But if you are hired as an engineer, everything the business asks of you comes with an implicit: "and make sure it's done in a proper way that won't break anything, or slow us down, or cost us too much, or limit our ability to gain a competitive edge." You don't just change a 3 to a 4 because the CEO wants you to. You have to make sure the change doesn't come with unforseen impact that would put the company at risk, and you have to make the change in a similar way. That's what the CEO expects also. If you did the change, and it had caused impact to the business, that you had not pointed out, and for which the business believe is more harmful then having waited a few more days, you and only you are to blame, and you will be. You can't say, but CEO told me, you're the engineer, you're the person they hired to know this stuff and prevent these issues from happening, not the CEO.
didibus 10y ago
I wonder what would have happened if he had initially told the CEO it would take 6 days for the change? "We can do that, but it will take us 6 days, otherwise we risk taking the plant down and aggravating the issue." I wonder if the CEO would have just said ok thanks. In my experience that's the case. The engineer in that link got himself in a bad spot, because he didn't know what was involved for the change when he communicated his estimate. And most of his back and forth that slowed him down would have been avoided had he known beforehand how to properly do it. Even with everyone's feedback it sounds like a 1 day code change. That seems to me like the reason the change was slow is more ramp up time for him working on a code base he doesn't normally work on.
- 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 ago
    Yes, 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 ago
      This 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.
st3v3r 10y ago
I think most people here have had the experience that the agreement will be made that the fixes will come "later". And then later never comes.
rplst8 10y ago
> I agree with those who say those improvements should maybe have been demanded immediately after the fire was out, but those who would have delayed the firefighting out of blind allegiance to the rules seemed, to me, to have forgotten that the rules are there to serve the programmers (particularly, their ability to quickly ship working code), and not the other way around. I think it depends on the type of product you are working on. Certain domains require very strict adherence to policy - for very good reason. Just because your shiny new aircraft's deadline is tomorrow, doesn't mean you can skimp on the required testing.
jlarocco 10y ago
The scenario in the linked post was not a "fire", and it makes sense that it would require going through the regular process. If it were a fire then where was the CEO after step one? Why didn't he (or the 'operations manager') send out an email to everybody informing them to bypass the regular process? A fire is something like, "the site is down for XX% of customers!" (for a large value of XX) or the "the software is routing product to the wrong place!" No doubt a real fire would have been handled differently.
protomyth 10y ago
> everyone's applauding the gatekeepers who insisted on significant refactoring and the creation of additional tests before the change could be approved. I certainly didn't applaud the gatekeeper because I believe they opened themselves up to a great risk. If you are doing an emergency patch to production you should minimize the amount of changes. All the refactoring of code was an unnecessary, reckless risk. The refactoring should move to the next scheduled release as the top priority since part of it is already in production.

by raldi 10y ago

wnevets 10y ago

Everything in moderation.

codeduck 10y ago
including moderation.
nurettin 10y ago
That's rather extreme.
matthewmorgan 10y ago
I prefer a slightly different translation of that Ancient Greek saying: nothing too much
0xdeadbeefbabe 10y ago
For a moderate amount of everything.

bluesign 10y ago

I think the linked thread is good example, changing 3 to 4 can seems minor, but i think even with rules in place, it is not a burning 'fire', it should be easily acceptable to run this with rules enforced in a day or two. Letting people to override rules is more damage in long run for sure. Maybe they would override next time when they shouldnt

raldi 10y ago
Sorry, but you don't get to make that call; it's the CEO's job, and the CEO said it needed to be done immediately, not in "a day or two".
- switchbak 10y ago
  Having read that article, I do agree - but the requested change, while being "one line", could have unforeseen consequences that could also have a very negative effect on the business. I'm thinking that the CEO wouldn't take the blame for that though. But if people's jobs were truly on the line, I'm inclined to agree with the "screw it, push it through" approach.
- didibus 10y ago
  I wholeheartedly disagree. In fact, I believe that's the difference between an engineer and a programmer. If you are hired as a programmer, then yes, just do whatever we ask of you. But if you are hired as an engineer, everything the business asks of you comes with an implicit: "and make sure it's done in a proper way that won't break anything, or slow us down, or cost us too much, or limit our ability to gain a competitive edge." You don't just change a 3 to a 4 because the CEO wants you to. You have to make sure the change doesn't come with unforseen impact that would put the company at risk, and you have to make the change in a similar way. That's what the CEO expects also. If you did the change, and it had caused impact to the business, that you had not pointed out, and for which the business believe is more harmful then having waited a few more days, you and only you are to blame, and you will be. You can't say, but CEO told me, you're the engineer, you're the person they hired to know this stuff and prevent these issues from happening, not the CEO.

didibus 10y ago

I wonder what would have happened if he had initially told the CEO it would take 6 days for the change? "We can do that, but it will take us 6 days, otherwise we risk taking the plant down and aggravating the issue." I wonder if the CEO would have just said ok thanks. In my experience that's the case. The engineer in that link got himself in a bad spot, because he didn't know what was involved for the change when he communicated his estimate. And most of his back and forth that slowed him down would have been avoided had he known beforehand how to properly do it. Even with everyone's feedback it sounds like a 1 day code change. That seems to me like the reason the change was slow is more ramp up time for him working on a code base he doesn't normally work on.

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 ago
  Yes, 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 ago
    This 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.

st3v3r 10y ago

I think most people here have had the experience that the agreement will be made that the fixes will come "later". And then later never comes.

rplst8 10y ago

> I agree with those who say those improvements should maybe have been demanded immediately after the fire was out, but those who would have delayed the firefighting out of blind allegiance to the rules seemed, to me, to have forgotten that the rules are there to serve the programmers (particularly, their ability to quickly ship working code), and not the other way around. I think it depends on the type of product you are working on. Certain domains require very strict adherence to policy - for very good reason. Just because your shiny new aircraft's deadline is tomorrow, doesn't mean you can skimp on the required testing.

jlarocco 10y ago

The scenario in the linked post was not a "fire", and it makes sense that it would require going through the regular process. If it were a fire then where was the CEO after step one? Why didn't he (or the 'operations manager') send out an email to everybody informing them to bypass the regular process? A fire is something like, "the site is down for XX% of customers!" (for a large value of XX) or the "the software is routing product to the wrong place!" No doubt a real fire would have been handled differently.

protomyth 10y ago

> everyone's applauding the gatekeepers who insisted on significant refactoring and the creation of additional tests before the change could be approved. I certainly didn't applaud the gatekeeper because I believe they opened themselves up to a great risk. If you are doing an emergency patch to production you should minimize the amount of changes. All the refactoring of code was an unnecessary, reckless risk. The refactoring should move to the next scheduled release as the top priority since part of it is already in production.