4 ms·

> 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

• 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.