5 ms·

seems often developers tend to over engineer or focus on edge cases that inflate costs, and not given enough attention to ROI

dsp1234 9y ago
Conversation from two days ago: manager: Why did you allow this thing to happen. me: It was an edge case that I pointed out 7 months ago. I've put it on the backlog 3 times, and you've removed it each time citing that it's an edge case that would never happen, and other newer features needed to be implemented. manager: That's an engineer's response. Just fix it! me: welp, shrug
- majormajor 9y ago
  I've had luck redirecting this type of question into "why did the process let this happen" where it becomes less my fault vs your fault and more "i did what you said, you did what the business person told you to prioritize, something broke" from a blame-agnostic point of view. In certain cases I've also overridden the "ignore that for now" in favor of at least some minimal fix because part of my job is to give you what you don't know you need to ask for, not just exactly what you ask for. And there's the value add because compared to people who don't consider that part of their job, my stuff / my team's stuff works better out the door. Another similar question that I've noticed others not always asking are things like "how often would this be used again, is it just a temporary one-off" which, of course, has an answer that's subject to change, but at least guides the initial design. And when it changes it gets revisited.
  - taneq 9y ago
    > In certain cases I've also overridden the "ignore that for now" in favor of at least some minimal fix because part of my job is to give you what you don't know you need to ask for, not just exactly what you ask for. This is a two-edged sword, though. I agree it's best practice from a technical point of view, but enabling wilful ignorance on the part of someone above you in the chain will eventually lead to a showdown when you really do need a week to fix it and it really is critical, and they tell you not to, and they'll stick to their guns because (as far as they know) they've been right every time.
    - majormajor 9y ago
      > This is a two-edged sword, though. I agree it's best practice from a technical point of view, but enabling wilful ignorance on the part of someone above you in the chain will eventually lead to a showdown when you really do need a week to fix it and it really is critical, and they tell you not to, and they'll stick to their guns because (as far as they know) they've been right every time. Yeah, pushing that too much requires either (a) sufficiently-padded early estimates so it's not a slippage and a nasty surprise (a good practice anyway, but hard), or (b) a sufficient level of don't-give-a-fuck, or (c) really good judgment around "when this is necessary to give them what they need vs what they want" and when not to e.g. truly critical and immediately messagable stuff. A healthy dose of don't-give-a-fuck/willing-to-say-no is often a good thing anyway, though, if you're able to do it politically/smoothly enough :)
- JustSomeNobody 9y ago
  This is so not uncommon. :)
- defined 9y ago
  > manager: That's an engineer's response. Just fix it! Translation: I didn't actually require any answer other than "I am sorry, sir/ma'am, it will never happen again." Facts are irrelevant. I may not always be right, but I am never wrong, code monkey.
  - TheSpiceIsLife 9y ago
    That's right. I have often spoken rapidly while saying the real reason(s) I believe lead to failure and then slow down and say "but never mind that, let's work out how to fix this and prevent it from happening, I'll get right on it", or something to that affect.
hermitdev 9y ago
It's not necessarily over engineering. It can often be about competing priorities. Multiple pressures on your time. I worked at a hedge fund for 9 years in back office IT developing firm-critical software. We traded pretty much anything you can trade, so we had a lot of trading desks requesting changes all the time. So, while making a change for one desk, at least one other is bitching about why their changes is taking so long. Yeah, the change might only take 5 minutes, but it might be 4 weeks before I get to it. We traded for all but about 2 hours of the week. Means you had a narrow deployment window. Even once the change has been made and tested, you've got to wait for the deployment window. One weekend of each month was off-limits to system changes to options expiration. So, even the smallest, simplest change might take at least a week or two to get into production. Quite longer big or breaking changes. Toss in regulatory and compliance issues and you've got a lot of paperwork and sign-offs to do a deployment. You've got to track those people down, explain the changes to the managing director and the risk with making the change. Emergencies were fun. Either getting called or having to call a manager at 2am in the morning to get approval... I once had an emergency at 11pm. I got a call from my director about 15 minutes after I'd popped sleeping pills (I was having insomnia at the time). I went through every source of caffeine I had in my apartment to get through that; I dropped off the conference call at 4am. I recall hearing the call went on for several hours afterwards. TL;DR It's not always over-engineering, it's more often misunderstood or invisible (to the business side) pressures on the engineer's time.
hysan 9y ago
> and not given enough attention to ROI Which itself could be a result of management often viewing engineering as a cost center with no perceivable ROI. This can be reflected in pay not being commensurate with company performance and not stacking up to other employees (sales, management, etc.) and gives the engineers no reason to pay attention to ROI in their decisions. I would bet that in companies where engineering is very much involved with cost, ROI, and paid based on how those numbers turn out, the engineers would focus less on edge cases and know when to draw the line.
kls 9y ago
Guess who's ass gets chewed when the system craps out in the middle of the night, when Asia your emerging market is just coming on line? Funny this story reminded me of a recent event where my team was working on some reg-ex expressions for a language processor. Not overly complex stuff but not simple by any definition (they had been working on the set for 2 days), they had a side line manager from another department, that knew enough to be dangerous, so he decides he is going to run in his office and whip up some reg-ex, after reading the docs. So we threw it in the test cases, after tons of failures he got the picture that edge cases count, as he got a good visualization of how multiple edge cases increase the the odds of failure by orders or magnitude.
sbuttgereit 9y ago
I've been on both sides and I understand both points of view. When my responsibility is managerial in nature, I'll tend to prioritize the dates and the ROI, then weigh the risks more optimistically because risk mitigation usually makes it harder to achieve what I am being judged on. However, when I'm the one actually doing the work... I tend to over-engineer (assuming "bullet-proof" is over-engineering for a circumstance), test, and the like. While I'm certainly rewarded for on-time deliveries, I have a professional interest in seeing a solid piece of work; and I tend to face more negative consequence if the work isn't of sufficient quality than I do if it's late. What's hard is finding the right balance. The proverbial "SQL in 5 minutes" moment from the blog post may not fully appreciate the developer's job, but it can serve as a reality check to self-question if you're over-baking it.
s73ver 9y ago
Developers are also the ones that get yelled at, called on the weekends, and even fired if those cases happen. If you're willing to come in on the weekend to fix your query, be my guest. But I like being able to spend my weekend relaxing.
- grogenaut 9y ago
  Huh, where I work the managers are the ones who get fired for bad ops or oversights. The engineers are just penalized by dealing with shitty decisions so they dream about quitting. The smart ones just fulton out of shitty managers to good teams.
  - salesguy222 9y ago
    You most likely work for a company that hasn't yet been overrun by the corporate world's version of "career politicians" who are there to leech a paycheck at all costs. They often blame others while finding very sneaky and specific ways to, despite all odds, rise to a relatively insulated level without any modicum of technical or managerial prowess congrats!!!
    - grogenaut 9y ago
      It's likely the ship, drive more revenue or get fired culture that keeps people from settling in.
WhitneyLand 9y ago
Interesting observation. I assume you have the skills and experience as a software developer to properly judge the technical aspect of these decisions, not just what appears to be clear from the business aspect?
borplk 9y ago
The problem is the businesses want to have their cake and eat it too. Damned if you do damned if you don't. If you don't focus on edge cases then later it's your fault for being sloppy. If you focus on edge cases you are "over engineering". Most of the time "over engineering" just means "I wish this was cheaper".

dsp1234 9y ago

Conversation from two days ago: manager: Why did you allow this thing to happen. me: It was an edge case that I pointed out 7 months ago. I've put it on the backlog 3 times, and you've removed it each time citing that it's an edge case that would never happen, and other newer features needed to be implemented. manager: That's an engineer's response. Just fix it! me: welp, shrug

majormajor 9y ago
I've had luck redirecting this type of question into "why did the process let this happen" where it becomes less my fault vs your fault and more "i did what you said, you did what the business person told you to prioritize, something broke" from a blame-agnostic point of view. In certain cases I've also overridden the "ignore that for now" in favor of at least some minimal fix because part of my job is to give you what you don't know you need to ask for, not just exactly what you ask for. And there's the value add because compared to people who don't consider that part of their job, my stuff / my team's stuff works better out the door. Another similar question that I've noticed others not always asking are things like "how often would this be used again, is it just a temporary one-off" which, of course, has an answer that's subject to change, but at least guides the initial design. And when it changes it gets revisited.
- taneq 9y ago
  > In certain cases I've also overridden the "ignore that for now" in favor of at least some minimal fix because part of my job is to give you what you don't know you need to ask for, not just exactly what you ask for. This is a two-edged sword, though. I agree it's best practice from a technical point of view, but enabling wilful ignorance on the part of someone above you in the chain will eventually lead to a showdown when you really do need a week to fix it and it really is critical, and they tell you not to, and they'll stick to their guns because (as far as they know) they've been right every time.
  - majormajor 9y ago
    > This is a two-edged sword, though. I agree it's best practice from a technical point of view, but enabling wilful ignorance on the part of someone above you in the chain will eventually lead to a showdown when you really do need a week to fix it and it really is critical, and they tell you not to, and they'll stick to their guns because (as far as they know) they've been right every time. Yeah, pushing that too much requires either (a) sufficiently-padded early estimates so it's not a slippage and a nasty surprise (a good practice anyway, but hard), or (b) a sufficient level of don't-give-a-fuck, or (c) really good judgment around "when this is necessary to give them what they need vs what they want" and when not to e.g. truly critical and immediately messagable stuff. A healthy dose of don't-give-a-fuck/willing-to-say-no is often a good thing anyway, though, if you're able to do it politically/smoothly enough :)
JustSomeNobody 9y ago
This is so not uncommon. :)
defined 9y ago
> manager: That's an engineer's response. Just fix it! Translation: I didn't actually require any answer other than "I am sorry, sir/ma'am, it will never happen again." Facts are irrelevant. I may not always be right, but I am never wrong, code monkey.
- TheSpiceIsLife 9y ago
  That's right. I have often spoken rapidly while saying the real reason(s) I believe lead to failure and then slow down and say "but never mind that, let's work out how to fix this and prevent it from happening, I'll get right on it", or something to that affect.

hermitdev 9y ago

It's not necessarily over engineering. It can often be about competing priorities. Multiple pressures on your time. I worked at a hedge fund for 9 years in back office IT developing firm-critical software. We traded pretty much anything you can trade, so we had a lot of trading desks requesting changes all the time. So, while making a change for one desk, at least one other is bitching about why their changes is taking so long. Yeah, the change might only take 5 minutes, but it might be 4 weeks before I get to it. We traded for all but about 2 hours of the week. Means you had a narrow deployment window. Even once the change has been made and tested, you've got to wait for the deployment window. One weekend of each month was off-limits to system changes to options expiration. So, even the smallest, simplest change might take at least a week or two to get into production. Quite longer big or breaking changes. Toss in regulatory and compliance issues and you've got a lot of paperwork and sign-offs to do a deployment. You've got to track those people down, explain the changes to the managing director and the risk with making the change. Emergencies were fun. Either getting called or having to call a manager at 2am in the morning to get approval... I once had an emergency at 11pm. I got a call from my director about 15 minutes after I'd popped sleeping pills (I was having insomnia at the time). I went through every source of caffeine I had in my apartment to get through that; I dropped off the conference call at 4am. I recall hearing the call went on for several hours afterwards. TL;DR It's not always over-engineering, it's more often misunderstood or invisible (to the business side) pressures on the engineer's time.

hysan 9y ago

> and not given enough attention to ROI Which itself could be a result of management often viewing engineering as a cost center with no perceivable ROI. This can be reflected in pay not being commensurate with company performance and not stacking up to other employees (sales, management, etc.) and gives the engineers no reason to pay attention to ROI in their decisions. I would bet that in companies where engineering is very much involved with cost, ROI, and paid based on how those numbers turn out, the engineers would focus less on edge cases and know when to draw the line.

kls 9y ago

Guess who's ass gets chewed when the system craps out in the middle of the night, when Asia your emerging market is just coming on line? Funny this story reminded me of a recent event where my team was working on some reg-ex expressions for a language processor. Not overly complex stuff but not simple by any definition (they had been working on the set for 2 days), they had a side line manager from another department, that knew enough to be dangerous, so he decides he is going to run in his office and whip up some reg-ex, after reading the docs. So we threw it in the test cases, after tons of failures he got the picture that edge cases count, as he got a good visualization of how multiple edge cases increase the the odds of failure by orders or magnitude.

sbuttgereit 9y ago

I've been on both sides and I understand both points of view. When my responsibility is managerial in nature, I'll tend to prioritize the dates and the ROI, then weigh the risks more optimistically because risk mitigation usually makes it harder to achieve what I am being judged on. However, when I'm the one actually doing the work... I tend to over-engineer (assuming "bullet-proof" is over-engineering for a circumstance), test, and the like. While I'm certainly rewarded for on-time deliveries, I have a professional interest in seeing a solid piece of work; and I tend to face more negative consequence if the work isn't of sufficient quality than I do if it's late. What's hard is finding the right balance. The proverbial "SQL in 5 minutes" moment from the blog post may not fully appreciate the developer's job, but it can serve as a reality check to self-question if you're over-baking it.

s73ver 9y ago

Developers are also the ones that get yelled at, called on the weekends, and even fired if those cases happen. If you're willing to come in on the weekend to fix your query, be my guest. But I like being able to spend my weekend relaxing.

grogenaut 9y ago
Huh, where I work the managers are the ones who get fired for bad ops or oversights. The engineers are just penalized by dealing with shitty decisions so they dream about quitting. The smart ones just fulton out of shitty managers to good teams.
- salesguy222 9y ago
  You most likely work for a company that hasn't yet been overrun by the corporate world's version of "career politicians" who are there to leech a paycheck at all costs. They often blame others while finding very sneaky and specific ways to, despite all odds, rise to a relatively insulated level without any modicum of technical or managerial prowess congrats!!!
  - grogenaut 9y ago
    It's likely the ship, drive more revenue or get fired culture that keeps people from settling in.

WhitneyLand 9y ago

Interesting observation. I assume you have the skills and experience as a software developer to properly judge the technical aspect of these decisions, not just what appears to be clear from the business aspect?

borplk 9y ago

The problem is the businesses want to have their cake and eat it too. Damned if you do damned if you don't. If you don't focus on edge cases then later it's your fault for being sloppy. If you focus on edge cases you are "over engineering". Most of the time "over engineering" just means "I wish this was cheaper".