3 ms·
It’s not the right approach. Structural engineers shouldn’t let management fiddle with their safety standards to increase speed. They will still blame you when
by klabb3 2y ago
It’s not the right approach. Structural engineers shouldn’t let management fiddle with their safety standards to increase speed. They will still blame you when things fail. In software, you can’t just throw in yolo projects with much lower “carefulness” than the rest of the product, everything has maintenance. The TL in this case needs to establish a certain set of standards and practices. That’s not a choice you give away to another team on a per-feature basis.
It’s also a ridiculous low bar for engineering managers to not even understand the most fundamental of tradeoffs in software. Of course they want things done faster, but then they can go escalate to the common boss/director and argue about prioritization against other things on the agenda. Not just “work faster”. Then they can go manage those whose work output is proportional to stress, not programmers.
- atoav 2y agoWhich is why liability is needed.
- thrw42A8N 2y agoManagement decides whether they build a cheap wooden building, a brick one, or a steel skyscraper. These all have different risk profiles. Safety is a business/management decision, even in structural engineering. A pedestrian bridge could be constructed to support tanks and withstand nuclear explosions, but why. Many engineered structures are actually extremely dangerous - for example mountain climbing trails. Also yes, you have many opportunities to just YOLO without significant consequences in software. A hackathon is a good example - I love them, always great to see the incredible projects at the end. The last one I visited was sponsored by a corporation and they straight up incorporated a startup next day with the winning team.
- hiddencost 2y agoExpected use and desired tolerance is a management decision. Safety is still on engineers.
- toss1 2y agoIsn't the point what level of safety? If management intends expected use to be a low-load-quick-and-dirty-temporary-use prototype to be delivered in days, it seems the engineers are not doing their job if they calibrate their safety process to a heavy-duty-life-critical application. And vice versa. Making the decision about the levels of use, durability, reuse-ability, scalability, AND RISK is all management. Implementing those decisions as decided by management is on engineering. It is not on engineering to fix a bad-trade-off management decision beyond what is reasonably possible (if you can, great, but go look to work someplace less exploitative).
- scott_w 2y agoWhat you wrote didn’t really refute the point you’re replying to.
- toss1 2y agoWhat you wrote didn’t really refute my point either. If management allocates time and resources only for a quick-&-dirty prototype not for public use, then releases it to the public with bad consequences, they will definitely ask the engineers about it. If the engineers properly covered their paper trail, i.e., kept receipts for when management refused their requests for resources to build-in greater safety, then engineering will be not responsible. Ethically, this is the correct model. But if he & you are saying that management will try to exploit engineering and then blame failures on engineering when it was really bad management, yup, you should expect that kind of ethical failure from management. Yes, there are exceptions, but the structure definitely encourages such unethical management behaviors.
- feoren 2y ago"Management" is generally a bunch of morons bikeshedding to try to distract everyone from the fact that their jobs are utterly worthless. The fewer decisions management makes, the better. If management feels like they need to make a decision, throw something in there they can tell you to remove later. It's a tried and tested method of getting those imbeciles off your back. Then build the damn thing that actually needs building. Management will take the credit, of course. But they'll be happy. Everyone wins. Think about it this way: the person who suffers the consequences of the decision should be making the decision. That's not management; they will never, ever accept any level of blame for anything. They'll immediately pass that buck right on to you. So that makes it your decision. Fuck management; build what needs building instead. Look at what happened when "management" started making decisions at Boeing about risk, instead of engineers making the decisions.
- yarekt 2y agoI can tell you’ve never worked with a competent manager. They are required because building the wrong thing is worse than not building anything at all
- feoren 2y agoBuilding the wrong thing is exactly what happens when you listen to management too much. Talk to the client yourself. Learn the subject. Get the textbook. Read the materials. That's how you build the right thing.
- mdaniel 2y ago> They are required because building the wrong thing is worse than not building anything at all And yet, "manager" is usually[1] only responsible for ensuring the boards get carried from the truck to the construction site and that two workers don't shoot at each other with nail guns, not "we, collectively, are building the right house." I freely admit that my cynicism is based on working in startups, where who knows what the right thing actually is, but my life experience is that managers for sure do not: they're just having meetings to ensure the workers are executing on the plan that the manager heard in their meeting 1: I am also 1000000% open to the fact that I fall into the camp of not having seen this mythical "competent manager" you started with