6 ms·

Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in

Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe. What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. Whoever had written this project before me wrote no tests, and basically brute forced features to work. A dropdown box that loaded options dynamically based on other user selections had 18 variables buried in the code where 8 of them were either unused or redundant. For a fucking dropdown box? I told the PM 1 week in that I'm not going to make the delivery deadline and he should be advising the client of such. --- I don't want to talk bad of my coworkers so I'll just say this. I'm the only developer in my company with a software background. Everyone else is electrical engineering/tech and it shows when you review their code. Comparing this "Amateur" vs. "Professional" article to what I am currently going through feels almost cathartic knowing this is something widely experienced in the field. I truly love my job, but some days, like these last days, really make me want to unplug from the world and go live in the wild because not only do Amateurs make these mistakes, they're also blind to the Professional ways of approaching work. It almost felt like an argument at times convincing him that this "extra" work that was neglected previously is necessary and should be factored into everyone's projects, not just mine.

danans 6y ago
> What happened is once I cracked the codebase open I found ... Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate. If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.
- hnarn 6y ago
  If you ask someone to give you an estimate for work needing to be done on your car, not only is it obvious that they will have to look at the car first, it's also obvious that the estimated cost and/or time may and often will overrun (although you're normally notified and asked before it does). It seems like both of these things should be equally obvious in software.
  - jfengel 6y ago
    When you look in the car, there are only a very limited number of things you expect to be there. If you're a mechanic, you've seen this model before, and it'll be pretty much identical, down to the last bolt. You need to assess the condition, and that'll affect the cost, but even so you can make a pretty good estimate from a glance. Every piece of software is different. By the time you know what's going on in there, you're almost done. You have to look, but you're still going to be making a lot of assumptions. Assumptions that can throw you off by a factor of 10 -- or even make the fix literally impossible. That doesn't mean we can do without estimation, even in software. You have to make plans and allocate resources. Just be prepared to change the plans -- and make plans that can accommodate the changes.
- TheCapn 6y ago
  There's more to the story, mostly based on past expectations and experiences. The development I'm talking about is done in a SCADA system, particularly AVEVA's System Platform. For my company we typially have a lot of code re-use through templates so if I see a dropdown box I expect it to be the version that's been used throughout other projects. It shouldn't need testing. The other half of it was my changes were entirely to the Database and SCADA software, I did not need to touch the PLC software for these features, but I did need to simulate the PLC code to test my new changes. So when it became time to run code in the lab, I found the PLC code was lacking all the proper simulation/test code needed to run it in a lab environment. Basically simulating field I/O such as motor statuses, sensor status, etc. So all that means whoever wrote this project last neglected to include what's seen as standard for our development process and I had to fill the gaps. Its easy to say "this is going to take longer because whoever came before me neglected to test their code" but that doesn't solve the problem we arrived at. If this was a common issue, I'd pretty much be handing in my resignation, but I'd say this is more of a recent issue where we've taken on too much work for the resources we have. What's happened is coworkers are skipping the stuff like simulation test code because its not customer facing to get to the next project and its not discovered until its too late. If every quote I needed to give included ripping apart every part of the project, even stuff I'm not about to modify, we'd be in a much darker place.
- justin_oaks 6y ago
  And the project manager made the mistake of taking an estimate and interpreting it as a deadline.
deleted 6y ago
[deleted]

danans 6y ago

> What happened is once I cracked the codebase open I found ... Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate. If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.

hnarn 6y ago
If you ask someone to give you an estimate for work needing to be done on your car, not only is it obvious that they will have to look at the car first, it's also obvious that the estimated cost and/or time may and often will overrun (although you're normally notified and asked before it does). It seems like both of these things should be equally obvious in software.
- jfengel 6y ago
  When you look in the car, there are only a very limited number of things you expect to be there. If you're a mechanic, you've seen this model before, and it'll be pretty much identical, down to the last bolt. You need to assess the condition, and that'll affect the cost, but even so you can make a pretty good estimate from a glance. Every piece of software is different. By the time you know what's going on in there, you're almost done. You have to look, but you're still going to be making a lot of assumptions. Assumptions that can throw you off by a factor of 10 -- or even make the fix literally impossible. That doesn't mean we can do without estimation, even in software. You have to make plans and allocate resources. Just be prepared to change the plans -- and make plans that can accommodate the changes.
TheCapn 6y ago
There's more to the story, mostly based on past expectations and experiences. The development I'm talking about is done in a SCADA system, particularly AVEVA's System Platform. For my company we typially have a lot of code re-use through templates so if I see a dropdown box I expect it to be the version that's been used throughout other projects. It shouldn't need testing. The other half of it was my changes were entirely to the Database and SCADA software, I did not need to touch the PLC software for these features, but I did need to simulate the PLC code to test my new changes. So when it became time to run code in the lab, I found the PLC code was lacking all the proper simulation/test code needed to run it in a lab environment. Basically simulating field I/O such as motor statuses, sensor status, etc. So all that means whoever wrote this project last neglected to include what's seen as standard for our development process and I had to fill the gaps. Its easy to say "this is going to take longer because whoever came before me neglected to test their code" but that doesn't solve the problem we arrived at. If this was a common issue, I'd pretty much be handing in my resignation, but I'd say this is more of a recent issue where we've taken on too much work for the resources we have. What's happened is coworkers are skipping the stuff like simulation test code because its not customer facing to get to the next project and its not discovered until its too late. If every quote I needed to give included ripping apart every part of the project, even stuff I'm not about to modify, we'd be in a much darker place.
justin_oaks 6y ago
And the project manager made the mistake of taking an estimate and interpreting it as a deadline.

deleted 6y ago

[deleted]