4 ms·

I'm not in the software industry so this sounds really odd to me. Don't you guys write proposals to go along with the quote that detail exactly what is in the

I'm not in the software industry so this sounds really odd to me. Don't you guys write proposals to go along with the quote that detail exactly what is in the scope of work? Do you not have a contractual statement of work? If they come back and say, "oh, we forgot to say we also need D", then the response should be, "that's no problem, we estimate it will take an additional X hours or dollars to implement that. Would you like us to update the proposal?" Or, if you're under budget and you're charging hourly rates instead of a fixed cost, you might even say you can probably add it without going over budget. PS: I just realized that you're probably talking about internal "clients" so there's no contract or even payment. But I think the same general idea applies. When they bring up extra features, you just say that it's going to take additional time. edit 2: I guess this doesn't actually help with getting the project done on time. The initial time estimate is still going to be off for the reasons you mentioned. So this comment isn't really an argument against anything you wrote.

DougWebb 9y ago
That's funny. No, for most developers who are asked to provide an estimate, the analogy is more like this: PM: I want a bridge. When can we start using it? Eng: Uh, ok, where is the bridge? What's is going over? What kind of traffic will it carry? PM: I want a bridge. Why are you being difficult? Tell me right now when we can start using it! I've got to go promise my boss that you committed to getting it done by then! Oh, btw, it needs to be done next week.
- k__ 9y ago
  also, they don't want a bridge, they want something like a bridge, but maybe mobile or cloud based.
  - gvb 9y ago
    More like they ask for a car ferry to cross the river but really want a bridge. If you are lucky, you will recognize from their "requirements" (often just a verbal description) that they are describing the characteristics of a bridge (e.g. continuous bidirectional flow), not a ferry. More typically, after you have built the car ferry, they ask why it doesn't implement continuous bidirectional flow despite never specifying that as a requirement.
    - user5994461 9y ago
      I think that last description is more on point. People can usually describe why they want something, if asked, instead what they want. It's not too difficult to come up with a reasonable scope if either the dev or the manager knows how to start and scope a project. Usually they both suck. The manager will send an unclear email. The developer will start developing right away. None have any idea what they are supposed to do, why or when.
      - k__ 9y ago
        Often the manager also expects the dev to start right away. For managers the value of a developer is the solutions they build divided by the amount of time and information they need to build it. You have always the choice between delaying further or delivering something they like as soon as possible, risking they don't like it.
    - k__ 9y ago
      Yes. Normally you would need a prototype, throw it away after you saw the reactions to it and build something new. But often there is no money for this :/
    - defen 9y ago
      This is why it's key to ask clients what problem they're trying to solve, rather than just delivering what they say they want. The classic, "If I'd asked my customers what they wanted, they'd have said 'a faster horse'." Especially don't let non-technical people constrain the range of possible solutions without very good reasons.
- thwarted 9y ago
  This short is a great example. https://youtu.be/BKorP55Aqvg https://youtu.be/BKorP55Aqvg
- raarts 9y ago
  You forgot: I can't answer all that, you are the expert!
user5994461 9y ago
Outsourcing firms will do strict contracts as you said, to cover their asses. The history has proven that they are not enforceable and can usually backfire for the client. A client wants something. In software, the something is usually complex and not well understood, a contract is done to do a something like that. During the project, they will invariably find new information and issues, the scope will change, sometimes dramatically. For the comparison, consider a building. You want to construct a new building, it's easy, you say what land you have, the engineers will tell you how large and tall they can build on that, you get to pick the interiors among a few office/industrial layouts. You can all understand what is being discussed. In software project, there is no physical limitations and no regulations. The limits are not clearly defined, noone will see or believe them. Worse, you have to integrate with clients/new/legacy systems that are not well defined and unknown ahead of time, nothing you can plan about that.
- Shoothe 9y ago
  This is the most accurate description of reality I've seen in this thread. Most of my work is "just" discovery of what can be built and what should be built while building the thing. And that's OK since one of the greatest strengths of software is extreme flexibility.
cloverich 9y ago
> "that's no problem, we estimate it will take an additional X hours or dollars to implement that. Would you like us to update the proposal? What happens in practice is they didn't realize they were asking for additional features -- they thought they were asking for D, E, F (etc) all along in the initial request. They just assumed "Email signup link" also meant spam handling, re-sending, prevention of double sending, etc. Good product managers account for these obvious things, and leave padding for the unexpected. But good product managers are rare. Most software developers I know have never even met one. So instead you have a political dance where you try to plan for the things they aren't telling you, along with all the _expected unexpected's_ that come up in normal software development, and set your deadline's appropriately. Definitely the worst part of software development.
thaumaturgy 9y ago
I think there are a handful of problems unique to the software industry that make accurate estimation practically impossible. Mostly they're a sign of an immature industry. So, as a lot of comments here suggest, most people just give it their best guess, and then inflate the number a lot, and negotiate some kind of deal, and then work like hell to actually pull it off. 1. It's never repeatable. Nearly every single thing built in software is being built for the first time. Even if it's some government CRUD application, and even if you're leveraging sixteen popular software frameworks to build it, that application will still be in some way different from other applications in the same niche. There's no blueprint for building software; mechanics have a gigantic (sometimes accurate) database of the time required to do a variety of jobs, tract home builders are all building the same thing over and over ... the closest that software ever gets to that is themes or skins for frontend UI, and even those inevitably end up getting customized in some way. 2. Nobody wants to pay to build a blueprint. The only way in the software industry to figure out how complex a particular application is going to be is to build it. Developing an accurate spec is exactly as expensive as building the actual application. This is because the "engineering" part of software engineering is still practically nonexistent. 3. And while we're on the topic of engineering: there are no standards. Or, there are thousands of different standards, depending on how you look at it. That CRUD application could be built with one of many different interfaces -- should it emulate data entry terminals, with simple tab-navigable text fields? Should it use Google's "Material" UI? Bootstrap? There's no comprehensive study which has compared the amount of end user effort required to use each interface, and therefore there's no industry standard which says, "this is always the right way to build this thing given these constraints". Compare to something like a low voltage contractor's license, which expects you to be familiar with the different types of cable to use in different building environments. 4. It's buggy as hell. Ok, so you're experienced enough to navigate your way through everything else up above and not get burned too badly. You have a preferred toolkit, you specialize in a particular niche, cool. Well, today, Chrome just released an update that broke the way your application handles cached content. (Happened to me.) The vendor for one of your frameworks released an urgent security update that completely broke critical functionality in an unrelated part of the application. (Happened to me.) The two libraries you're using together, which don't use any of the same globals and should be entirely isolated from eachother, are still somehow interfering in a way that's not covered by the sparse documentation. (Happened to me.) There are millions upon millions of lines of code involved in every single interaction with a computer now, and they are imperfect. Many of them are written by amateurs, people who -- even though they're getting paid to write code -- have only been in the industry for a couple of years and they're still re-learning all of the same lessons that everyone else before them had to learn through trial and error. 5. Too many programmers like shiny new things. We could fix a lot of the above if we slowed down and "refactored" our industry -- started doing real usability studies, establishing standards for storing sensitive information, more rigorously separating security and feature updates. But, nobody really wants to do that. They want the new thing: the new programming language, the new framework, the new browser feature, the new toolchain. I think this is largely because while programmers spend a lot of their time talking to machines, they aren't machines themselves. They need a steady stream of new stuff to stave off the boredom. It's also a good way to improve your resume or income. If a new Widget comes out, and you immediately learn Widget, you're now one of very few people in the world that knows Widget. Now, if you convince your bosses or customers to use Widget, you're the only person that they can go to for help with Widget. So there's a lot of immaturity, and it's kind of a mess, but it's also a pace of technological development that's unprecedented in the history of humankind.
GlennS 9y ago
If you've detailed exactly what's in scope, then most of the work is already done.
valuearb 9y ago
If every software project was fully specced, we'd do nothing but spend all our time writing specs. The best (and fastest) way to build something is with minimal specs, and modifying as you go along. As your clients (internal or otherwise) actually get to use features as they are built, they'll provide tons of input that they wouldn't ever have put in a spec. This is also why you should never, ever, do fixed bid work in software development.

DougWebb 9y ago

That's funny. No, for most developers who are asked to provide an estimate, the analogy is more like this: PM: I want a bridge. When can we start using it? Eng: Uh, ok, where is the bridge? What's is going over? What kind of traffic will it carry? PM: I want a bridge. Why are you being difficult? Tell me right now when we can start using it! I've got to go promise my boss that you committed to getting it done by then! Oh, btw, it needs to be done next week.

k__ 9y ago
also, they don't want a bridge, they want something like a bridge, but maybe mobile or cloud based.
- gvb 9y ago
  More like they ask for a car ferry to cross the river but really want a bridge. If you are lucky, you will recognize from their "requirements" (often just a verbal description) that they are describing the characteristics of a bridge (e.g. continuous bidirectional flow), not a ferry. More typically, after you have built the car ferry, they ask why it doesn't implement continuous bidirectional flow despite never specifying that as a requirement.
  - user5994461 9y ago
    I think that last description is more on point. People can usually describe why they want something, if asked, instead what they want. It's not too difficult to come up with a reasonable scope if either the dev or the manager knows how to start and scope a project. Usually they both suck. The manager will send an unclear email. The developer will start developing right away. None have any idea what they are supposed to do, why or when.
    - k__ 9y ago
      Often the manager also expects the dev to start right away. For managers the value of a developer is the solutions they build divided by the amount of time and information they need to build it. You have always the choice between delaying further or delivering something they like as soon as possible, risking they don't like it.
  - k__ 9y ago
    Yes. Normally you would need a prototype, throw it away after you saw the reactions to it and build something new. But often there is no money for this :/
  - defen 9y ago
    This is why it's key to ask clients what problem they're trying to solve, rather than just delivering what they say they want. The classic, "If I'd asked my customers what they wanted, they'd have said 'a faster horse'." Especially don't let non-technical people constrain the range of possible solutions without very good reasons.
thwarted 9y ago
This short is a great example. https://youtu.be/BKorP55Aqvg https://youtu.be/BKorP55Aqvg
raarts 9y ago
You forgot: I can't answer all that, you are the expert!

user5994461 9y ago

Outsourcing firms will do strict contracts as you said, to cover their asses. The history has proven that they are not enforceable and can usually backfire for the client. A client wants something. In software, the something is usually complex and not well understood, a contract is done to do a something like that. During the project, they will invariably find new information and issues, the scope will change, sometimes dramatically. For the comparison, consider a building. You want to construct a new building, it's easy, you say what land you have, the engineers will tell you how large and tall they can build on that, you get to pick the interiors among a few office/industrial layouts. You can all understand what is being discussed. In software project, there is no physical limitations and no regulations. The limits are not clearly defined, noone will see or believe them. Worse, you have to integrate with clients/new/legacy systems that are not well defined and unknown ahead of time, nothing you can plan about that.

Shoothe 9y ago
This is the most accurate description of reality I've seen in this thread. Most of my work is "just" discovery of what can be built and what should be built while building the thing. And that's OK since one of the greatest strengths of software is extreme flexibility.

cloverich 9y ago

> "that's no problem, we estimate it will take an additional X hours or dollars to implement that. Would you like us to update the proposal? What happens in practice is they didn't realize they were asking for additional features -- they thought they were asking for D, E, F (etc) all along in the initial request. They just assumed "Email signup link" also meant spam handling, re-sending, prevention of double sending, etc. Good product managers account for these obvious things, and leave padding for the unexpected. But good product managers are rare. Most software developers I know have never even met one. So instead you have a political dance where you try to plan for the things they aren't telling you, along with all the _expected unexpected's_ that come up in normal software development, and set your deadline's appropriately. Definitely the worst part of software development.

thaumaturgy 9y ago

I think there are a handful of problems unique to the software industry that make accurate estimation practically impossible. Mostly they're a sign of an immature industry. So, as a lot of comments here suggest, most people just give it their best guess, and then inflate the number a lot, and negotiate some kind of deal, and then work like hell to actually pull it off. 1. It's never repeatable. Nearly every single thing built in software is being built for the first time. Even if it's some government CRUD application, and even if you're leveraging sixteen popular software frameworks to build it, that application will still be in some way different from other applications in the same niche. There's no blueprint for building software; mechanics have a gigantic (sometimes accurate) database of the time required to do a variety of jobs, tract home builders are all building the same thing over and over ... the closest that software ever gets to that is themes or skins for frontend UI, and even those inevitably end up getting customized in some way. 2. Nobody wants to pay to build a blueprint. The only way in the software industry to figure out how complex a particular application is going to be is to build it. Developing an accurate spec is exactly as expensive as building the actual application. This is because the "engineering" part of software engineering is still practically nonexistent. 3. And while we're on the topic of engineering: there are no standards. Or, there are thousands of different standards, depending on how you look at it. That CRUD application could be built with one of many different interfaces -- should it emulate data entry terminals, with simple tab-navigable text fields? Should it use Google's "Material" UI? Bootstrap? There's no comprehensive study which has compared the amount of end user effort required to use each interface, and therefore there's no industry standard which says, "this is always the right way to build this thing given these constraints". Compare to something like a low voltage contractor's license, which expects you to be familiar with the different types of cable to use in different building environments. 4. It's buggy as hell. Ok, so you're experienced enough to navigate your way through everything else up above and not get burned too badly. You have a preferred toolkit, you specialize in a particular niche, cool. Well, today, Chrome just released an update that broke the way your application handles cached content. (Happened to me.) The vendor for one of your frameworks released an urgent security update that completely broke critical functionality in an unrelated part of the application. (Happened to me.) The two libraries you're using together, which don't use any of the same globals and should be entirely isolated from eachother, are still somehow interfering in a way that's not covered by the sparse documentation. (Happened to me.) There are millions upon millions of lines of code involved in every single interaction with a computer now, and they are imperfect. Many of them are written by amateurs, people who -- even though they're getting paid to write code -- have only been in the industry for a couple of years and they're still re-learning all of the same lessons that everyone else before them had to learn through trial and error. 5. Too many programmers like shiny new things. We could fix a lot of the above if we slowed down and "refactored" our industry -- started doing real usability studies, establishing standards for storing sensitive information, more rigorously separating security and feature updates. But, nobody really wants to do that. They want the new thing: the new programming language, the new framework, the new browser feature, the new toolchain. I think this is largely because while programmers spend a lot of their time talking to machines, they aren't machines themselves. They need a steady stream of new stuff to stave off the boredom. It's also a good way to improve your resume or income. If a new Widget comes out, and you immediately learn Widget, you're now one of very few people in the world that knows Widget. Now, if you convince your bosses or customers to use Widget, you're the only person that they can go to for help with Widget. So there's a lot of immaturity, and it's kind of a mess, but it's also a pace of technological development that's unprecedented in the history of humankind.

GlennS 9y ago

If you've detailed exactly what's in scope, then most of the work is already done.

valuearb 9y ago

If every software project was fully specced, we'd do nothing but spend all our time writing specs. The best (and fastest) way to build something is with minimal specs, and modifying as you go along. As your clients (internal or otherwise) actually get to use features as they are built, they'll provide tons of input that they wouldn't ever have put in a spec. This is also why you should never, ever, do fixed bid work in software development.