4 ms·

Interesting - and no one tried to beat you down on the end date when a task went quickly, or berated you when one overan? I truely believe that developing soft

by RegW 5y ago

Interesting - and no one tried to beat you down on the end date when a task went quickly, or berated you when one overan? I truely believe that developing software is a creative process that you are always doing for the first time (unless you did it wrong the first time). Why does everyone expect us to know how long its going to take. The basic rule of thumb I use is to take my best guess and multiply by PI. (answer: because 3 isn't usually enough).

hhggffdd 5y ago
I think it’s because of perpetual instability of the tools we use. There are always new libraries and apis to learn. I think a lot of it is self-inflicted. If we built stuff the way we built it 10 years ago, we would still get the same product finished but having done the same thing in the same way, estimates would be more reliable. But boy did we succeed at allocating a heap of VC cash into devs pockets.
- rahoulb 5y ago
  For me and dev work it's generally about misunderstanding the requirements. They ask for X, I think X involves A, B and C, when actually it involves A, D, E, F, G and H.
  - 5e92cb50239222b 5y ago
    Not to mention that often they ask for X while actually meaning Y.
  - rubidium 5y ago
    Yep. And that’s on you and the product owner to get aligned on. Fix that alignment and you fix the problem.
    - lostcolony 5y ago
      Time needed to fix that alignment is impossible to estimate, and also impossible to prove you have done sufficiently.
rubidium 5y ago
I basically believe that building a house is a creative process that you are always doing for the first time. As a general contractor you can’t expect me to provide a timeline of when it will done. This house has never been built this way before. … That way of speaking would fly in no other engineering discipline. Software, while it possesses some interesting differences from other fields (eg mechanical, electrical) has some massive growth to do in terms of actually developing engineering skills. The biggest problems I see with sw engineers who complain about estimating work are (1) lack of experience (2) lack of rigor and (3) lack of effective teamwork. A mature sw team with good disciple around getting user input and estimating work is totally possible. I’ve seen it. This who think software is un-estimable compared to other engineering fields are just giving themselves an excuse from accountability.
- foxfluff 5y ago
  "This house has never been built this way before." That implies someone's already designed how it's going to be built? What I often see in software that you're expected to give estimates on the spot before there's a design. You're expected to be the designer and implementor, and you're expected to say how long it'll take before you've started designing. "I need features X, Y and Z" isn't a design. And if you think other engineering disciplines are different, please go ask an EE how long it'll take -- or what it'll cost -- to make a board with a 2 GHz SoC and 8GB of LPDDR4 and PCIe. (That's not a design, and if you don't get laughed at, you'll learn that the answer depends massively on the design)
- sirwhinesalot 5y ago
  The design of a house doesn't change every 3 weeks while it is getting built. House construction is usually only started after a massive amount of detailed design and planning is done. This is priced in. This is almost never true for software. Even with the above houses often take longer to build than expected and unforeseen issues can arise. Even the weather can screw things up. The amount of unexpected issues that can come up in software is huge. Everything from a bug on a library that you use to differences in the exact machine that the software will run on vs where it was developed.
- 5y ago
wpietri 5y ago
> I truely believe that developing software is a creative process that you are always doing for the first time This is absolutely true. And that's because when we find ourselves doing the same thing repeatedly, we abstract it into a library, a framework, or a service so that we don't have to do it again. The easiest thing to predict is something that has been done a zillion times. So if you're building 100 houses in a subdivision, you can get really good at estimating and hitting those estimates. But the more novel something is, the harder it is to predict. And software by its nature is novel. If it isn't, we're doing it wrong.

by RegW 5y ago

hhggffdd 5y ago

I think it’s because of perpetual instability of the tools we use. There are always new libraries and apis to learn. I think a lot of it is self-inflicted. If we built stuff the way we built it 10 years ago, we would still get the same product finished but having done the same thing in the same way, estimates would be more reliable. But boy did we succeed at allocating a heap of VC cash into devs pockets.

rahoulb 5y ago
For me and dev work it's generally about misunderstanding the requirements. They ask for X, I think X involves A, B and C, when actually it involves A, D, E, F, G and H.
- 5e92cb50239222b 5y ago
  Not to mention that often they ask for X while actually meaning Y.
- rubidium 5y ago
  Yep. And that’s on you and the product owner to get aligned on. Fix that alignment and you fix the problem.
  - lostcolony 5y ago
    Time needed to fix that alignment is impossible to estimate, and also impossible to prove you have done sufficiently.

rubidium 5y ago

I basically believe that building a house is a creative process that you are always doing for the first time. As a general contractor you can’t expect me to provide a timeline of when it will done. This house has never been built this way before. … That way of speaking would fly in no other engineering discipline. Software, while it possesses some interesting differences from other fields (eg mechanical, electrical) has some massive growth to do in terms of actually developing engineering skills. The biggest problems I see with sw engineers who complain about estimating work are (1) lack of experience (2) lack of rigor and (3) lack of effective teamwork. A mature sw team with good disciple around getting user input and estimating work is totally possible. I’ve seen it. This who think software is un-estimable compared to other engineering fields are just giving themselves an excuse from accountability.

foxfluff 5y ago
"This house has never been built this way before." That implies someone's already designed how it's going to be built? What I often see in software that you're expected to give estimates on the spot before there's a design. You're expected to be the designer and implementor, and you're expected to say how long it'll take before you've started designing. "I need features X, Y and Z" isn't a design. And if you think other engineering disciplines are different, please go ask an EE how long it'll take -- or what it'll cost -- to make a board with a 2 GHz SoC and 8GB of LPDDR4 and PCIe. (That's not a design, and if you don't get laughed at, you'll learn that the answer depends massively on the design)
sirwhinesalot 5y ago
The design of a house doesn't change every 3 weeks while it is getting built. House construction is usually only started after a massive amount of detailed design and planning is done. This is priced in. This is almost never true for software. Even with the above houses often take longer to build than expected and unforeseen issues can arise. Even the weather can screw things up. The amount of unexpected issues that can come up in software is huge. Everything from a bug on a library that you use to differences in the exact machine that the software will run on vs where it was developed.
5y ago

wpietri 5y ago

> I truely believe that developing software is a creative process that you are always doing for the first time This is absolutely true. And that's because when we find ourselves doing the same thing repeatedly, we abstract it into a library, a framework, or a service so that we don't have to do it again. The easiest thing to predict is something that has been done a zillion times. So if you're building 100 houses in a subdivision, you can get really good at estimating and hitting those estimates. But the more novel something is, the harder it is to predict. And software by its nature is novel. If it isn't, we're doing it wrong.