16 ms·

I can say how long my software compile or build time takes fairly accurately. That's the better analogy to use with construction. The rest of the software proje

I can say how long my software compile or build time takes fairly accurately. That's the better analogy to use with construction. The rest of the software project is design work, I'm moving walls around, adding more load bearing, and so on.

deleted 4y ago
[deleted]
hinkley 4y ago
I’m surprised how often people are wrong about simple things like this. If a build takes five minutes, that’s the absolute least amount of time before you’ll have a binary. The CI tool could have a queuing glitch. You could have a flaky test, you could be failing to isolate multiple integration test runs properly and one could ruin the other. But that’s just the simple stuff, the stuff without humans. Most of the time if something will take five minutes, we often try to find something to do that will take a few minutes. Well guess what, we always underestimate how long things will take, ususally by a factor of two. So a five minute build can take ten minutes for you to notice if it succeeded. And if it failed thirty seconds in, you might still be looking at fifteen to twenty minutes to the end of the second build (the more failures the lower the likelihood someone will multitask, but for some they only watch the third try closely). This doubling and tripling is why it’s more important than you might expect for compile and test times to be very fast. An extra minute can turn into three way too often.
foolfoolz 4y ago
the workers in trades in a construction project have plans. they have schematics that say do this here. to this exact dimension. using this exact type of connector. they don’t (usually) say which tools to use or how to do everything, it’s assumed you know compare this to a software team that has plans (design docs) for everything they want o build. they have schematics (tickets) that say do this here. to this exact interface. they don’t (usually) say which tools to use or how to do everything, it’s assumed you know i don’t think these scenarios should be that far apart. those people in the skyscraper aren’t moving walls. that would screw over the whole project. they have the output of more planning so they don’t have to. and it paid off during implementation
- woah 4y ago
  > compare this to a software team that has plans (design docs) for everything they want o build. they have schematics (tickets) that say do this here. to this exact interface. That's a recipe for failure
- jmillikin 4y ago
  A software project's design doc is like an architectural mock-up: sometimes useful, but not necessary and certainly not part of the construction process. Programmers write the blueprint. The construction is handled by the computer (compiler, linker, tests).
- vlovich123 4y ago
  Buildings are typically cookie cutter designs that aren’t too different. The ones that are have all the same problems - you have to adjust the design on the fly (see Burj Kalifa). Additionally, when your in the middle of creating your building, the owner doesn’t come in and say “actually, I want this apartment complex to also have a suite of luxury condors on every odd floor”. It’s a fantasy to think that more planning would make software development cheaper or more on time. We tried that. That’s waterfall. And it failed miserably because software supports business needs which change on a quarterly or yearly basis. Not to mention that we need to update our software to take advantage of newer systems or security vulnerabilities. That building you’re putting has a fixed purpose that’s going to remain largely unchanged for 50 to 100 years or so, there’s generally nothing new to learn in terms of techniques and problems (unless your pushing things like with Burj in which case they did have to make on the fly adjustments and delay), and doesn’t have to deal with the challenges of the virtual space that software plays in. So sure. If you’re a contractor building the same kind of website over and over again, I’m sure you can give a very accurate estimate of how long a given piece of work can take. If you’re trying to build a more scalable system or something totally new that hasn’t been done before, then there’s no plans to follow and you have to iterate until you figure out solutions to all the problems you encounter.
  - wizofaus 4y ago
    "Additionally, when your in the middle of creating your building, the owner doesn’t come in and say “actually, I want this apartment complex to also have a suite of luxury condors on every odd floor”." From what I've heard from people working in the construction industry, this sort of thing ("variations" I gather they're called) happens more than you'd think.

deleted 4y ago

[deleted]

hinkley 4y ago

I’m surprised how often people are wrong about simple things like this. If a build takes five minutes, that’s the absolute least amount of time before you’ll have a binary. The CI tool could have a queuing glitch. You could have a flaky test, you could be failing to isolate multiple integration test runs properly and one could ruin the other. But that’s just the simple stuff, the stuff without humans. Most of the time if something will take five minutes, we often try to find something to do that will take a few minutes. Well guess what, we always underestimate how long things will take, ususally by a factor of two. So a five minute build can take ten minutes for you to notice if it succeeded. And if it failed thirty seconds in, you might still be looking at fifteen to twenty minutes to the end of the second build (the more failures the lower the likelihood someone will multitask, but for some they only watch the third try closely). This doubling and tripling is why it’s more important than you might expect for compile and test times to be very fast. An extra minute can turn into three way too often.

foolfoolz 4y ago

the workers in trades in a construction project have plans. they have schematics that say do this here. to this exact dimension. using this exact type of connector. they don’t (usually) say which tools to use or how to do everything, it’s assumed you know compare this to a software team that has plans (design docs) for everything they want o build. they have schematics (tickets) that say do this here. to this exact interface. they don’t (usually) say which tools to use or how to do everything, it’s assumed you know i don’t think these scenarios should be that far apart. those people in the skyscraper aren’t moving walls. that would screw over the whole project. they have the output of more planning so they don’t have to. and it paid off during implementation

woah 4y ago
> compare this to a software team that has plans (design docs) for everything they want o build. they have schematics (tickets) that say do this here. to this exact interface. That's a recipe for failure
jmillikin 4y ago
A software project's design doc is like an architectural mock-up: sometimes useful, but not necessary and certainly not part of the construction process. Programmers write the blueprint. The construction is handled by the computer (compiler, linker, tests).
vlovich123 4y ago
Buildings are typically cookie cutter designs that aren’t too different. The ones that are have all the same problems - you have to adjust the design on the fly (see Burj Kalifa). Additionally, when your in the middle of creating your building, the owner doesn’t come in and say “actually, I want this apartment complex to also have a suite of luxury condors on every odd floor”. It’s a fantasy to think that more planning would make software development cheaper or more on time. We tried that. That’s waterfall. And it failed miserably because software supports business needs which change on a quarterly or yearly basis. Not to mention that we need to update our software to take advantage of newer systems or security vulnerabilities. That building you’re putting has a fixed purpose that’s going to remain largely unchanged for 50 to 100 years or so, there’s generally nothing new to learn in terms of techniques and problems (unless your pushing things like with Burj in which case they did have to make on the fly adjustments and delay), and doesn’t have to deal with the challenges of the virtual space that software plays in. So sure. If you’re a contractor building the same kind of website over and over again, I’m sure you can give a very accurate estimate of how long a given piece of work can take. If you’re trying to build a more scalable system or something totally new that hasn’t been done before, then there’s no plans to follow and you have to iterate until you figure out solutions to all the problems you encounter.
- wizofaus 4y ago
  "Additionally, when your in the middle of creating your building, the owner doesn’t come in and say “actually, I want this apartment complex to also have a suite of luxury condors on every odd floor”." From what I've heard from people working in the construction industry, this sort of thing ("variations" I gather they're called) happens more than you'd think.