21–30 of 129 posts
Had a similar thing a while ago. Very complicated IPSEC tunnels, routers switches firewalls and whatnot between us and our customer. Customers techs were - not great - so needed to make sure port 443 worked through the tunnel. Our side mainly Linux, theirs was mainly Windows 10. Asked a programmer our side (.net) who said it'd take a couple of hours to write a simple webserver, package it up into an .msi and give it…
Earlier quoted context omitted.
Exactly, this is the substantial other side of the argument that almost always seems to be left out of the discussion. "Good enough, done in a week" is a perfectly viable option that is rarely offered by timesheet-padding developers.
seems often developers tend to over engineer or focus on edge cases that inflate costs, and not given enough attention to ROI
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
Had a similar thing a while ago. Very complicated IPSEC tunnels, routers switches firewalls and whatnot between us and our customer. Customers techs were - not great - so needed to make sure port 443 worked through the tunnel. Our side mainly Linux, theirs was mainly Windows 10. Asked a programmer our side (.net) who said it'd take a couple of hours to write a simple webserver, package it up into an .msi and give it…
On the flip side, when something DOESN'T need HA, sub-millisecond query response time, or lynx and IE Edge compatability, people need to know when "good enough" is good enough. On my ops team, we've gotten some flak for not building robust enough of a request queue for some tasks. But it's been down several hours in the past year. The server almost never needs maintenance. None of the workload is real-time. App resta…
I once had an infrastructure guy who worked in the same company quote me £70K for new hardware to host a single static HTML web page. £70K of new hardware! I stuck it on an existing server and nobody noticed though I might have got into trouble with the Change Prevention Board for not using the right form or something... Edit: He did have a carefully worked out explanation of where the money had to be spent.... which…
Then dump the static file on S3, and let the interest from the £40K in your bank account pay for it.
Had a similar thing a while ago. Very complicated IPSEC tunnels, routers switches firewalls and whatnot between us and our customer. Customers techs were - not great - so needed to make sure port 443 worked through the tunnel. Our side mainly Linux, theirs was mainly Windows 10. Asked a programmer our side (.net) who said it'd take a couple of hours to write a simple webserver, package it up into an .msi and give it…
Sometimes, I take 10% of the time writing what is needed and 90% of the time getting it to be testable and then writing the actual unit tests.
> Nothing ever works as soon as an engineer writes code; it is an iterative process. One of my complaints about working in an environment where I am the only person who can program is that nobody else understands this. I've taken the time to explain this point to people, and they seem to grasp it fairly well, but once they see something that somewhat resembles the final product they get really impatient. The last 25%…
once they see something that somewhat resembles the final product they get really impatient. (Especially for internal tool) Is it possible that what they've seen is, actually, good enough? Or at least, good enough to solve 90% of the problem while you fill in the missing piece that covers the rest.
Then we have a few people who completely ignore any limitations I put of tools and use them in ways in which they are explicitly not working.
Case-in-point: I created a process that automated a particular task. Said task bears a resemblance to another task, but there are a lot of edge cases in the other task. The manager who runs the second task got upset that I had automated one task but not the other, and complained in a senior staff meeting about this.
I mentioned that the second process was much more complex, and a lot could go wrong if she tried using the new process for it.
Anyways, I took a sick day yesterday, and she had sent an email to me CCing my boss, complaining about how the new process was broken. She had tried changing the settings to work with her process and broken both processes.
She is fully convinced I am just keeping tools from her because I don't like her. The reason she doesn't have any tools is because I have to build the most robust tools possible or she'll break everything, and I can automate 10 other processes with that sort of time.
Had a similar thing a while ago. Very complicated IPSEC tunnels, routers switches firewalls and whatnot between us and our customer. Customers techs were - not great - so needed to make sure port 443 worked through the tunnel. Our side mainly Linux, theirs was mainly Windows 10. Asked a programmer our side (.net) who said it'd take a couple of hours to write a simple webserver, package it up into an .msi and give it…
Earlier quoted context omitted.
Exactly, this is the substantial other side of the argument that almost always seems to be left out of the discussion. "Good enough, done in a week" is a perfectly viable option that is rarely offered by timesheet-padding developers.
seems often developers tend to over engineer or focus on edge cases that inflate costs, and not given enough attention to ROI
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.
On the flip side, when something DOESN'T need HA, sub-millisecond query response time, or lynx and IE Edge compatability, people need to know when "good enough" is good enough. On my ops team, we've gotten some flak for not building robust enough of a request queue for some tasks. But it's been down several hours in the past year. The server almost never needs maintenance. None of the workload is real-time. App resta…
So has AWS, so you can kind of feel good.
Because your "5 minutes" is pure bullshit and your engineer knows it. Your engineer knows that if she writes your "5 minute" query without careful analysis, peer review and documentation and the query ever produces a questionable result --- whether it was anticipated by your requirements or not --- it's your engineers ass; you'll throw your engineer under the bus _instantly_. Your engineer knows that if she writes yo…