5 ms·

Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections st

Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you in the hall and says "hey you, how long will this take?" That is not a reasonable question, so sure you cant give a reasonable projection. If youre a professional coder and you show up to a planning meeting and your answer is "I dont know, i have no idea and its not possible to provide an answer even on an order of magnitude" thats just ridiculous.

davesnothere 7y ago
The domain is different in a way you don't understand.
BurningFrog 7y ago
One way software is different is that you're always doing things you've never done before. Because if you've done it before, you can just reuse that code. This is probably not how the refueling nuclear aircraft carriers projects work. That said, it's usually not quite as completely unknowable as your last sentence. Then again, it frequently is. The real tension is about trust. When people think engineers are lying about their estimates.
rhizome 7y ago
What you are describing are reasons why software engineering isn't Engineering.
- buzzerbetrayed 7y ago
  Could you expound on this? I’m not saying I disagree, I’m just not sure which part of what he says disqualifies software engineering from being “engineering”
  - rhizome 7y ago
    Start with the HUGE failure rate in software development. There is no provable reliability and/or costing, nor is there any form of standardization beyond RFCs and "best practices." One might even doubt that it's even possible for there to be standards like you see in capital-E Engineering due to the unique and complex nature of general computing systems. To sum up, software development requires too much trust, way more than would be acceptible in an aircraft carrier or airplane or nuclear bomb. Or refrigerator.
    - tra3 7y ago
      What about Engineering (or, construction, say) being hundreds of years old vs software development only 50? Not arguing with your main point, but curious to hear your thoughts.
      - repolfx 7y ago
        Software engineering is clearly engineering. The main difference is simply that in the software world, engineers often report directly to people who aren't engineers. This basically never happens in other fields - e.g. all buildings, tunnels, railways etc are built by dedicated engineering firms founded and run by more engineers. The exception in software is of course the tech industry, which routinely pulls off engineering marvels. Projects usually go wrong, or are "late" (relative to estimates engineers didn't want to give in the first place), when they're being closely controlled by people who are not engineers. The recent article on Berlin's new airport being a case in point, where the politicians tried to double its size after it started being constructed and the entire project collapsed in a heap. Now imagine that happening all the time, every day. That's the enterprise software world.
ehutch79 7y ago
False equivalence. You planning 'how to put fuel in a nulean aircraft carrier'. For most software projects the equivalent question being asked is 'can you put some fuel in this thing we have'. When asking things like * what kind of fuel * is the thing a container or a vehicle * etc The response is often 'isn't it obvious, you're the developer you should know'. Can you tell I'm in the middle of training coworkers to offer up proper requirements.
- uygarpe 7y ago
  I'm going to steal this if you don't mind.
  - ehutch79 7y ago
    feel free to
- darkr 7y ago
  Very true; to expand on this metaphor, past experience has lead me to ask “does this thing actually need fuel, or is it in fact a bicycle?”; aka: please give me the full context - what are you actually trying to achieve and why?
zentropia 7y ago
I will say that in sfortware you can estimate but because there are many unknown things it's difficult. Is a bit like "How long it will take to discover the cure for cancer?"
- mdpopescu 7y ago
  Yes! "We have this problem, you see, where cells sometimes start to multiply aggressively instead of doing their job. That's a bug, the customers are complaining. How long will it take to fix it? What do you mean you don't know - not even a ballpark estimate?"
coldtea 7y ago
>I simply do not accept it is impossible to project a timeline for software. Well, as you said, you're not a coder. "Refueling nuclear aircraft carriers" has so fewer fail states and unknowns, it's not even comparable to writing a large piece of software.
reroute1 7y ago
You refuse to accept that there's a possibility of something in a domain you have no understanding of... That sounds like a very illogical refutation in itself
chhickman 7y ago
> Refueling nuclear aircraft carriers have projections start to finish, a half decade long. The difference is that those projections weren't spit out on the fly by a engineer after a 15 minute pitch of some manager's great new idea. Those plans took many months of effort to put together by a team of specialists planning out the various details of the project. Software does have the equivalent of this, it's called waterfall development. The reason we don't do this is because, unlike aircraft carrier design, if you take six months to create a project plan your requirements will have likely already substantially changed.
Scarblac 7y ago
> If youre a professional coder and you show up to a planning meeting and your answer is "I dont know, i have no idea and its not possible to provide an answer even on an order of magnitude" thats just ridiculous. True, but it's because that question is often ridiculous. If it's technology I've never worked with before, in a domain I've never worked, for which the test data doesn't exist yet, it's perfectly reasonable to be outside an order of magnitude. E.g., we mostly do Web app development with React and Django, sometimes going into more complicated data processing and visualization. In a recent planning meeting we were asked about recognizing waterways from aerial photographs to improve local government's GIS datasets. Ummm...
- shados 7y ago
  > we mostly do Web app development with React and Django, sometimes going into more complicated data processing and visualization. In a recent planning meeting we were asked about recognizing waterways from aerial photographs to improve local government's GIS datasets. Ummm To be fair, thats something that happens all the time in "normal engineering". While the field itself is much better understand (mostly because aside of record beating sky scrappers, its usually within the same problem space), not everyone knows everything. For a more down to earth example, if I ask my carpenter to scope out a bathroom remodel, the first thing he's going to do is call a plumber to take a look. The carpenter's not going to be able to give an answer on the plumbing themselves, but they sure as hell can say "Im going to ask someone and get back to you on it". As a software engineer, I have a network of connections I can reach out to if I'm asked about a problem completely out of my space, and you'd be hard pressed to ask about something that no one in my team knows or has a connection to someone who knows. Definitely won't get the answer today or even tomorrow, but we can get SOME information.
lazyasciiart 7y ago
I'm not a nuclear aircraft carrier refueller, so maybe the domain is different in a way I don't understand, but it's ridiculous to need a five year plan to just refuel something, people refuel cars in five minutes everyday. I simply do not accept that it is impossible to refuel in a week or so, assuming it's a couple orders of magnitude more complex than refueling a car. Thats about how your comment sounded.
- kryogen1c 7y ago
  +1 However, your comment didnt help me understand. It doesnt help because even if i embark on something i have no idea about, even in total ignorance i can _bound the problem_. I dont understand how a professional coder can approach even a problem and have no idea - you have to DO the problem, so what is your approach? Just start coding and somewhere between 5 days and 5 years you stop? Planning meetings dont happen in a vacuum, so what kind of problem can you research but have literally no guess about its solution? Bear in mind, we're not talking edge cases (research grants or whatever), but coders hired to do a job.
  - rramadass 7y ago
    >i can _bound the problem_ This is the nub of the problem when it comes to software. I understand your skepticism but software development is really very different from other activities. It is "mind-stuff" (and thus quite unstructured) which needs to be expressed in very precise language to solve an [almost always ill-defined/constantly redefined] problem. The inherent complexity involved is huge due to the number of degrees of freedom and malleability involved. I can do no better than point you to the article "The Humble Programmer" (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW...) written by one of the pioneers of Computer Science to really understand the issues that make Software Development such a complex and difficult activity. And since then (the article is from 70's) we have made matters exponentially worse by orders of magnitude.
    - thwarted 7y ago
repolfx 7y ago
The domain is different, indeed. Refuelling a nuclear aircraft carrier may be a complex operation but it's one for which the plan was already developed quite some time ago. To compare to software development is missing the point. Building a PC, installing Windows and all the apps you need might take half a day if you're experienced, and it'll take half a day each and every time: it's labour and you can't reduce the time taken to zero. That's like refuelling an aircraft carrier: executing a plan. But software development isn't like manual labour where you execute a pre-determined plan. It's more like researching how to build the aircraft carrier. Once the plan (the software) is built, installing and executing it is trivial and takes very predictable amounts of time, which means software developers are almost always doing "research" even if it doesn't seem that way. How long did the first nuclear aircraft carrier take to design? Well, literally the first sentence of the Design section of the wiki article for USS Enterprise says: Enterprise was intended as the first of a class of six carriers, but massive increases in construction costs led to the remaining vessels being cancelled So I guess ship designers suck at estimating about as much as software developers do.

davesnothere 7y ago

The domain is different in a way you don't understand.

BurningFrog 7y ago

One way software is different is that you're always doing things you've never done before. Because if you've done it before, you can just reuse that code. This is probably not how the refueling nuclear aircraft carriers projects work. That said, it's usually not quite as completely unknowable as your last sentence. Then again, it frequently is. The real tension is about trust. When people think engineers are lying about their estimates.

rhizome 7y ago

What you are describing are reasons why software engineering isn't Engineering.

buzzerbetrayed 7y ago
Could you expound on this? I’m not saying I disagree, I’m just not sure which part of what he says disqualifies software engineering from being “engineering”
- rhizome 7y ago
  Start with the HUGE failure rate in software development. There is no provable reliability and/or costing, nor is there any form of standardization beyond RFCs and "best practices." One might even doubt that it's even possible for there to be standards like you see in capital-E Engineering due to the unique and complex nature of general computing systems. To sum up, software development requires too much trust, way more than would be acceptible in an aircraft carrier or airplane or nuclear bomb. Or refrigerator.
  - tra3 7y ago
    What about Engineering (or, construction, say) being hundreds of years old vs software development only 50? Not arguing with your main point, but curious to hear your thoughts.
    - repolfx 7y ago
      Software engineering is clearly engineering. The main difference is simply that in the software world, engineers often report directly to people who aren't engineers. This basically never happens in other fields - e.g. all buildings, tunnels, railways etc are built by dedicated engineering firms founded and run by more engineers. The exception in software is of course the tech industry, which routinely pulls off engineering marvels. Projects usually go wrong, or are "late" (relative to estimates engineers didn't want to give in the first place), when they're being closely controlled by people who are not engineers. The recent article on Berlin's new airport being a case in point, where the politicians tried to double its size after it started being constructed and the entire project collapsed in a heap. Now imagine that happening all the time, every day. That's the enterprise software world.

ehutch79 7y ago

False equivalence. You planning 'how to put fuel in a nulean aircraft carrier'. For most software projects the equivalent question being asked is 'can you put some fuel in this thing we have'. When asking things like * what kind of fuel * is the thing a container or a vehicle * etc The response is often 'isn't it obvious, you're the developer you should know'. Can you tell I'm in the middle of training coworkers to offer up proper requirements.

uygarpe 7y ago
I'm going to steal this if you don't mind.
- ehutch79 7y ago
  feel free to
darkr 7y ago
Very true; to expand on this metaphor, past experience has lead me to ask “does this thing actually need fuel, or is it in fact a bicycle?”; aka: please give me the full context - what are you actually trying to achieve and why?

zentropia 7y ago

I will say that in sfortware you can estimate but because there are many unknown things it's difficult. Is a bit like "How long it will take to discover the cure for cancer?"

mdpopescu 7y ago
Yes! "We have this problem, you see, where cells sometimes start to multiply aggressively instead of doing their job. That's a bug, the customers are complaining. How long will it take to fix it? What do you mean you don't know - not even a ballpark estimate?"

coldtea 7y ago

>I simply do not accept it is impossible to project a timeline for software. Well, as you said, you're not a coder. "Refueling nuclear aircraft carriers" has so fewer fail states and unknowns, it's not even comparable to writing a large piece of software.

reroute1 7y ago

You refuse to accept that there's a possibility of something in a domain you have no understanding of... That sounds like a very illogical refutation in itself

chhickman 7y ago

> Refueling nuclear aircraft carriers have projections start to finish, a half decade long. The difference is that those projections weren't spit out on the fly by a engineer after a 15 minute pitch of some manager's great new idea. Those plans took many months of effort to put together by a team of specialists planning out the various details of the project. Software does have the equivalent of this, it's called waterfall development. The reason we don't do this is because, unlike aircraft carrier design, if you take six months to create a project plan your requirements will have likely already substantially changed.

Scarblac 7y ago

> If youre a professional coder and you show up to a planning meeting and your answer is "I dont know, i have no idea and its not possible to provide an answer even on an order of magnitude" thats just ridiculous. True, but it's because that question is often ridiculous. If it's technology I've never worked with before, in a domain I've never worked, for which the test data doesn't exist yet, it's perfectly reasonable to be outside an order of magnitude. E.g., we mostly do Web app development with React and Django, sometimes going into more complicated data processing and visualization. In a recent planning meeting we were asked about recognizing waterways from aerial photographs to improve local government's GIS datasets. Ummm...

shados 7y ago
> we mostly do Web app development with React and Django, sometimes going into more complicated data processing and visualization. In a recent planning meeting we were asked about recognizing waterways from aerial photographs to improve local government's GIS datasets. Ummm To be fair, thats something that happens all the time in "normal engineering". While the field itself is much better understand (mostly because aside of record beating sky scrappers, its usually within the same problem space), not everyone knows everything. For a more down to earth example, if I ask my carpenter to scope out a bathroom remodel, the first thing he's going to do is call a plumber to take a look. The carpenter's not going to be able to give an answer on the plumbing themselves, but they sure as hell can say "Im going to ask someone and get back to you on it". As a software engineer, I have a network of connections I can reach out to if I'm asked about a problem completely out of my space, and you'd be hard pressed to ask about something that no one in my team knows or has a connection to someone who knows. Definitely won't get the answer today or even tomorrow, but we can get SOME information.

lazyasciiart 7y ago

I'm not a nuclear aircraft carrier refueller, so maybe the domain is different in a way I don't understand, but it's ridiculous to need a five year plan to just refuel something, people refuel cars in five minutes everyday. I simply do not accept that it is impossible to refuel in a week or so, assuming it's a couple orders of magnitude more complex than refueling a car. Thats about how your comment sounded.

kryogen1c 7y ago
+1 However, your comment didnt help me understand. It doesnt help because even if i embark on something i have no idea about, even in total ignorance i can _bound the problem_. I dont understand how a professional coder can approach even a problem and have no idea - you have to DO the problem, so what is your approach? Just start coding and somewhere between 5 days and 5 years you stop? Planning meetings dont happen in a vacuum, so what kind of problem can you research but have literally no guess about its solution? Bear in mind, we're not talking edge cases (research grants or whatever), but coders hired to do a job.
- rramadass 7y ago
  >i can _bound the problem_ This is the nub of the problem when it comes to software. I understand your skepticism but software development is really very different from other activities. It is "mind-stuff" (and thus quite unstructured) which needs to be expressed in very precise language to solve an [almost always ill-defined/constantly redefined] problem. The inherent complexity involved is huge due to the number of degrees of freedom and malleability involved. I can do no better than point you to the article "The Humble Programmer" (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW...) written by one of the pioneers of Computer Science to really understand the issues that make Software Development such a complex and difficult activity. And since then (the article is from 70's) we have made matters exponentially worse by orders of magnitude.
  - thwarted 7y ago

repolfx 7y ago

The domain is different, indeed. Refuelling a nuclear aircraft carrier may be a complex operation but it's one for which the plan was already developed quite some time ago. To compare to software development is missing the point. Building a PC, installing Windows and all the apps you need might take half a day if you're experienced, and it'll take half a day each and every time: it's labour and you can't reduce the time taken to zero. That's like refuelling an aircraft carrier: executing a plan. But software development isn't like manual labour where you execute a pre-determined plan. It's more like researching how to build the aircraft carrier. Once the plan (the software) is built, installing and executing it is trivial and takes very predictable amounts of time, which means software developers are almost always doing "research" even if it doesn't seem that way. How long did the first nuclear aircraft carrier take to design? Well, literally the first sentence of the Design section of the wiki article for USS Enterprise says: Enterprise was intended as the first of a class of six carriers, but massive increases in construction costs led to the remaining vessels being cancelled So I guess ship designers suck at estimating about as much as software developers do.