2 ms·

The idea is right, but his vin example is poor. If the system doesn't actually reflect reality than the system is poor. A better example might be someone say a

The idea is right, but his vin example is poor. If the system doesn't actually reflect reality than the system is poor. A better example might be someone say asking for a report that shows all the part time employees that are getting overtime time and a half pay. Which makes sense at first, until you consider that an employee working more than 30 hours (or whatever the number is) is classified as full time, and its not possible to get overtime unless your working more than 40 hours. So the programmer then has to go back and clarify, "do you want to find employees that were hired as part time but are now classified as full time, or are you interested in part time employees collecting holiday/danger/etc pay multipliers?" Saying "it can't be done" is the kind of thing you would get from a junior employee that doesn't understand the business nor the code. The more senior guy understands the mismatch and asks questions that clarify what the intentions actually are. So, the VIN example would make more sense if they clarified the system only has license plate data, and partial or missing VIN information because the data wasn't collected. In that case the work item includes getting someone to do that data entry/etc work of assuring the VINs exist for all the vehicles as well as creating the vin->mileage report.

SoftTalker 3y ago
You might also have employees who are ostensibly "part time" and average 30 hours a week but occasionally work more than 40 and get overtime pay. The real world is full of messiness like this, because what people actually do on a given day is rarely physically constrained by policies and job classifications.
- treeman79 3y ago
  Recall during the dot com crash at RadioShack. District manager kept complaining that a bunch of displays were not getting setup. We were a busy understaffed store so nothing got done during the day. Finally I stayed until 3am once and got everything done. District was unhappy that I got extra pay. No thanks at all for resolving the matter.
  - advael 3y ago
    The coupling between results and costs is fundamentally broken in the minds of most people who get to make the decisions
travisgriggs 3y ago
> The idea is right, but his vin example is poor. If the system doesn't actually reflect reality than the system is poor. Here’s some examples I’ve experienced over the last 10 years. I have operated as a primary (but not sole) developer for wireless valve automation products in large agriculture irrigation. Much of oir guidance comes from older/seasoned/conservative individuals who like things they can easily understand and maintain farmer/irrigator autonomy. - Example 1 - Early on, we prototyped some early emerging cloud centric stuff and the company wouldn’t have it. People still had too many recent memories of buggy/down cloud services due to security outages, infrastructure, you name it. So we did some novel things with proximity based security (rather than tradition user/pass with model), Bluetooth, MQTT, and edge centric computation. In these environments, power is king, so you go light and small (because you might be running on a solar panel). Fast forward, and every other play in this space is doing some cloud centric subscription operation, with lots of REST APIs and the like. Suddenly, the company wants cloud based controls (as opposed to handheld), and infinite logging/memory. It’s hard to explain to them “edge centric is tough to just infinitely scale storage and transport” and even harder to explain why the pressures they brought to bear make these things harder and harder to accomplish. - Example Two - we’ve built two generations of proprietary radio network protocols for Val control (first on top of Zigbee like DSM; second on top of LoRA—not Wan). Responsiveness and low power and reliability totally informed this design, as well as the patterns of how agricultural valve operations occur. But suddenly, with California water use legislation, the end customers thing that this provoked should easily be modified to transport constant feed flow/pressure telemetry. And again, it’s impossible to Ty and explain why you can’t have your cake and eat it too, without coming across as a priggish programmer that doesn’t want to advance in the company.
- StillBored 3y ago
  Tending to provide solutions as well as the tradeoffs tends to be better accepted. Saying we need to replace all the existing HW, but then it will work once we buy a billion dollars of AWS leaves the decision to people who are paid to make such decisions. I've been there, I worked for a place that wanted to copy a competitors feature set with myself and a couple other programmers, when the competitor had a team of like 200 people working on the same thing. My response was basically, look I might be able to get a prototype in a year or two, but no guarantees on stability, feature set, etc. If we hire a half dozen people, it might be done in two years, but its going to take them 6 months to become productive and then your going to still be missing X, Y, Z. And I assumed that would kill it, but you know I ended up spending a year working on a prototype by myself anyway. Which was "fun" and I learned a lot, but was a giant opportunity lost for the business because it turns out a half ass prototype can't compete with a solid polished product in POCs. edit: This isn't to say "i was right" because in that case the right decision was probably to hire the extra people and make a significant move into that market, given the state of the existing product which died just a couple years later. But the business people didn't or couldn't expend the resources to make us competitive. So, they were probably hoping for a miracle, which many were delivered but a bunch of small miracles doesn't equal a big one.

SoftTalker 3y ago

You might also have employees who are ostensibly "part time" and average 30 hours a week but occasionally work more than 40 and get overtime pay. The real world is full of messiness like this, because what people actually do on a given day is rarely physically constrained by policies and job classifications.

treeman79 3y ago
Recall during the dot com crash at RadioShack. District manager kept complaining that a bunch of displays were not getting setup. We were a busy understaffed store so nothing got done during the day. Finally I stayed until 3am once and got everything done. District was unhappy that I got extra pay. No thanks at all for resolving the matter.
- advael 3y ago
  The coupling between results and costs is fundamentally broken in the minds of most people who get to make the decisions

travisgriggs 3y ago

> The idea is right, but his vin example is poor. If the system doesn't actually reflect reality than the system is poor. Here’s some examples I’ve experienced over the last 10 years. I have operated as a primary (but not sole) developer for wireless valve automation products in large agriculture irrigation. Much of oir guidance comes from older/seasoned/conservative individuals who like things they can easily understand and maintain farmer/irrigator autonomy. - Example 1 - Early on, we prototyped some early emerging cloud centric stuff and the company wouldn’t have it. People still had too many recent memories of buggy/down cloud services due to security outages, infrastructure, you name it. So we did some novel things with proximity based security (rather than tradition user/pass with model), Bluetooth, MQTT, and edge centric computation. In these environments, power is king, so you go light and small (because you might be running on a solar panel). Fast forward, and every other play in this space is doing some cloud centric subscription operation, with lots of REST APIs and the like. Suddenly, the company wants cloud based controls (as opposed to handheld), and infinite logging/memory. It’s hard to explain to them “edge centric is tough to just infinitely scale storage and transport” and even harder to explain why the pressures they brought to bear make these things harder and harder to accomplish. - Example Two - we’ve built two generations of proprietary radio network protocols for Val control (first on top of Zigbee like DSM; second on top of LoRA—not Wan). Responsiveness and low power and reliability totally informed this design, as well as the patterns of how agricultural valve operations occur. But suddenly, with California water use legislation, the end customers thing that this provoked should easily be modified to transport constant feed flow/pressure telemetry. And again, it’s impossible to Ty and explain why you can’t have your cake and eat it too, without coming across as a priggish programmer that doesn’t want to advance in the company.

StillBored 3y ago
Tending to provide solutions as well as the tradeoffs tends to be better accepted. Saying we need to replace all the existing HW, but then it will work once we buy a billion dollars of AWS leaves the decision to people who are paid to make such decisions. I've been there, I worked for a place that wanted to copy a competitors feature set with myself and a couple other programmers, when the competitor had a team of like 200 people working on the same thing. My response was basically, look I might be able to get a prototype in a year or two, but no guarantees on stability, feature set, etc. If we hire a half dozen people, it might be done in two years, but its going to take them 6 months to become productive and then your going to still be missing X, Y, Z. And I assumed that would kill it, but you know I ended up spending a year working on a prototype by myself anyway. Which was "fun" and I learned a lot, but was a giant opportunity lost for the business because it turns out a half ass prototype can't compete with a solid polished product in POCs. edit: This isn't to say "i was right" because in that case the right decision was probably to hire the extra people and make a significant move into that market, given the state of the existing product which died just a couple years later. But the business people didn't or couldn't expend the resources to make us competitive. So, they were probably hoping for a miracle, which many were delivered but a bunch of small miracles doesn't equal a big one.