There are elements and leanings toward this combative view of security in a whole lot of companies, both in IT departments and in software-focused corporations. I haven’t seen even a small fraction of such places (only maybe a few hundred directly and indirectly), but it seems rare that it gets to strategic levels (aka cold war with each side hesitant to change the status quo) - most places are aware of the tradeoffs and able to make risk-estimate-based decisions. It helps a LOT to have developers do the initial risk and attack value estimates.
I’ll agree about the emergency/patch deployment process being the one to focus on. There’s something akin to Gresham’s law in ops methodology—bad process drives out good.
heh. Consultants are the people who couldn’t meet our hiring bar, so we pay them twice as much to avoid any long-term responsibility for outcomes. They are useful at making sure our devs have asked the right questions and considered the right options. But the actual analysis and decision starts and ends on the team (and management) that’s going to actually run the system and deal with the consequences.
Not everywhere, and not as completely sane as I’m stating it—there’s a lot of truth in Dilbert. But if it’s too bad where you are, go elsewhere. There are good software teams and they’re hiring.
Do you have a reliable way to distinguish good teams from bad ones, before you sign the paperwork and put in your notice?
I’ve stayed in jobs I wanted to leave a couple of times now, because my team was a reasonably good team and I was afraid that elsewhere I would end up with Dilbert’s boss.
More importantly, the overall software dev market is such that you can change 3-4 times in one year without really limiting your prospects, as long as you can explain what you’re looking for and why you think the next one is it. You probably can’t do that two years in a row, but trying a new job isn’t a life sentence, it’s an exploration.
There are elements and leanings toward this combative view of security in a whole lot of companies, both in IT departments and in software-focused corporations. I haven’t seen even a small fraction of such places (only maybe a few hundred directly and indirectly), but it seems rare that it gets to strategic levels (aka cold war with each side hesitant to change the status quo) - most places are aware of the tradeoffs and able to make risk-estimate-based decisions. It helps a LOT to have developers do the initial risk and attack value estimates.
I’ll agree about the emergency/patch deployment process being the one to focus on. There’s something akin to Gresham’s law in ops methodology—bad process drives out good.
“developers do the initial risk and attack value estimates”
You mean trust in-house devs? Heresy! If they were any good they wouldn’t work here! Only consultants can be relied upon.
heh. Consultants are the people who couldn’t meet our hiring bar, so we pay them twice as much to avoid any long-term responsibility for outcomes. They are useful at making sure our devs have asked the right questions and considered the right options. But the actual analysis and decision starts and ends on the team (and management) that’s going to actually run the system and deal with the consequences.
Not everywhere, and not as completely sane as I’m stating it—there’s a lot of truth in Dilbert. But if it’s too bad where you are, go elsewhere. There are good software teams and they’re hiring.
Do you have a reliable way to distinguish good teams from bad ones, before you sign the paperwork and put in your notice?
I’ve stayed in jobs I wanted to leave a couple of times now, because my team was a reasonably good team and I was afraid that elsewhere I would end up with Dilbert’s boss.
Not terribly reliable, but you can get a start by asking Joel’s questions (https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/) and Kate Mats ones (http://katemats.com/questions-for-candidates-to-ask-in-an-interview/).
More importantly, the overall software dev market is such that you can change 3-4 times in one year without really limiting your prospects, as long as you can explain what you’re looking for and why you think the next one is it. You probably can’t do that two years in a row, but trying a new job isn’t a life sentence, it’s an exploration.