5 ms·

How did you manage to constrain the time overrun to only 4x? As a mercenary engineer, I've had to answer the estimation question many times. Whenever I've give

by pgt 7y ago

How did you manage to constrain the time overrun to only 4x? As a mercenary engineer, I've had to answer the estimation question many times. Whenever I've given estimates, it has only ever shot me in the foot. Spolsky might have figured it out, but I haven't. So I try to avoid giving estimates as far as possible and instead focus on demonstrating velocity of a working system they can choose to stop funding at any time. Some clients, especially from the construction industry, expect me to give them GANTT-chart style estimates down to the hour. Here is how I convey the software estimation problem to them: If I write the same code twice, I done fucked up. So any code I write, is new code. If I can reuse code, I will, but that's not the code you're asking about. In your industry, you have built the same house many times before with the same team, on the same foundation. But you are employing me to design, architect and construct a new house that has never been built before. If it existed already, you would just buy it off the shelf instead of employing me. So think of me as more of an architect than a labourer, and together with you as the client, we are embarking on a design that you're not quite sure you want yet, that won't collapse on a potentially unstable foundation.

davnicwil 7y ago
This is a good analogy, and when you're bootstrapping a product somehow it's extended further because in addition to being the architect you're also taking on the role of town planner, deciding where it gets built and thinking about if it should be built at all (do people need it).
- pgt 7y ago
  Town planner or city planner is a great analogy! The role conveys the uncertainty of future growth and anticipation of problems much better than an architect, who typically only does a once-off design. Thanks for that :).
endymi0n 7y ago
Having done hundreds of small to mid sized projects I take comfort in the fact estimating is a very distinct task that even the best of developers learn last. I've got three tricks in my pocket that at least help me with this: The first is that I go by the formula mentioned in "The Mythical Man-Month" — which is that the effort in larger projects is distributed as follows: 1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand Developers tend to mainly estimate their coding time, which leads exactly to the effects mentioned. It also explains all the annoying situations with all the holdups once the project is "almost done", this is simply a systems test and will add another 25%. The other is that I simply add 5-10% on top for each person involved into the project (dev, stakeholder, anything) for communication overhead. It usually holds true. The third trick is meticuluous focus on lean delivery, which involves scoping down, early testing on as much as possible, hidden and pre-deadlines and setting tractable sub-milestones. Unfortunately, all of these techniques don't accelerate the project, they just help you be more realistic. If you find something that accelerates complex projects, let me know ;-)
- ido 7y ago
  > If you find something that accelerates complex projects, let me know Developer experience. I've been working as a developer for a living for 18 years & I thought I was pretty hot-shit 10 years ago already, but I can probably do more today in 4 days than I used to in 4 weeks (or 4 months a few years before that).
  - WrtCdEvrydy 7y ago
    This holds very true up to the architect level.
    - mannykannot 7y ago
      As learning curves generally flatten out, that is to be expected.
      - ido 7y ago
        I've switched sub-fields of development a few times during my career (scientific computing, back-end web, front-end web, desktop applications, embedded, games [various platforms - native desktop/mobile/consoles, html5, flash, etc]) and I found that helped me keep the learning curve steep.
- tarsinge 7y ago
  Really insightful, thank you. Also regarding: > If you find something that accelerates complex projects, let me know When possible cut scope and split the project in smaller projects with real deployments (much like you said with "The third trick is meticuluous focus on lean delivery, which involves scoping down, early testing on as much as possible, hidden and pre-deadlines and setting tractable sub-milestones."). In nearly all my projects I now propose something like this to clients: "Ok we understand your needs and requirements. What do you think about having a V1 with only these core features deployed in a few weeks (which ideally already provide business value), and after that we iteratively improve it?". Works great for smoothly throwing away all the nice to have.
- 7y ago
mattmanser 7y ago
For me Joel was spot on in my experience, and I disagree, you are always writing the same code again and again. Just tweaking it a bit to fit the requirements. An easy example is the thousands of JSON APIs you can integrate these days, where the code to do that is almost identical, but not quite. Generally the only complications are in what stupid authentication and pagination method this API came up with. But it happens everywhere in coding. Every system might need user management, but slightttttly different each time. Or sending emails but Bob already uses Sendgrid, where traditionally you've used mailgun. Also the software industry changes all the time. That email code you wrote ten years ago using SMTP won't be reusable. The invoicing system you built for one client using PHP and jQuery 1.7 in 2012? Not appropriate to sell to a client today. Basically you should have written things at least very similar to what you're estimating on. Then you need to find your "multiplier". The figure you need to increase your gut estimate by to get the real estimate. Plus, there's a lot of legal complication about reusing code with different clients, often you should be rewriting purely to be safe for them and you from a copyright perspective.
- laumars 7y ago
  In my experience working in a broad range of fields in IT; web development is quite unlike any other type of development when it comes to code reuse and framework churn.
  - TeMPOraL 7y ago
    IME, web frontend might be particularly repeatable once you drop the artistics. But when I was doing desktop development, beyond simple UI issues, almost all work I had was unique and dictated by customer's ever changing and ever weirder requirements. In backend work, similarly, pretty much everything I write is a new and unique flower on a unkempt bush of the overall architecture.
    - mattmanser 7y ago
      Not really, I've built all sorts of stuff, but ultimately when you're hooking together a client's accountancy SaaS to their order system, it's going to be roughly the same code and take the same time as the other umpteen times you've done it for other clients. But it'll be a little different as they're using Xero instead of Quickbooks which you used last, and they have a different order entity design because of X. I really feel like anyone arguing otherwise is slightly delusional. I find it particularly funny the guy two up claiming frontend might be reusable code, but backend isn't. Once you've done one invoicing/emailing/workflow/search system/time tracking/credit control/custom form designer/forecasting module/cash flow/etc./etc./etc. module for a client, you've pretty much done 'em all. And after a certain point you can then start to estimate the complexity of other systems with a small amount of talking to the client and research that let's you know the scope and the gotchas.
LoSboccacc 7y ago
probably it's because developers tend to estimate the technical part first and foremost. then comes prouctization, then comes integration. if the estimate is consistently between 3x and 6x, that's what's likely missing.
ebiester 7y ago
I'm a strong proponent of learning formal and informal estimation methods - I'd start with Steve McConnell's book "Software Estimation: Demystifying the Black Art." For estimates that I would put money on, I will estimate in 4 hour blocks and get features down to the most granular level. If I don't understand it at that level, I don't understand it well enough to estimate yet.
saalweachter 7y ago
One of my favorite shows is Grand Designs. Building a house is probably the most understood human activities; as you stated, you can take a standard design on a normal building lot and throw up a house in a very predictable amount of time. If you've done it enough, you can write down a schedule of when every piece of material and every trade needs to be on site. Grand Designs always involves some combination of unusual design, unusual sites, and unusual techniques, and frequently inexperienced builders. People set out to accomplish something grand, and usually succeed, but it takes much longer and more money than expected, and especially more than constructing a conventional house on a conventional lot. Now, besides echoing your point that many novel software projects are much more akin to a Grand Designs house than a cookie cutter ranch in a Midwestern suburb, in Grand Designs one concept that is proved true time and again is that once you are out of the ground -- once you have your foundation in, your gas and water and sewer and electric hookups -- the hard part is over and the job will proceed much more smoothly. It's hard to estimate before you get out of the ground, because the ground is filled with unknowns and unforseen problems. You might still misjudge how long it will take you to finish, particularly the finicky details that always take forever, but this is purely a failure of estimation; an experienced builder could predict the time to spackle, trim, paint, install flooring and built-ins accurately, you just didn't realize it. But under the ground, there are all sorts of problems with rocks and water tables and pipes and whatnot you can't predict. Do we, as software engineers, have a similar inflection point in our software development? Do we ever get "out of the ground", to the point that most of the unknowns are known and we have a predictable (if still great and difficult) amount of work remaining?
antoniuschan99 7y ago
This is a great analogy on why it's so difficult to estimate: https://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe https://www.quora.com/Engineering-Management/Why-are-softwar... Estimating should be fun, plus there are various ways, such as estimating as a team (majority wins), t-shirt sizes, etc

by pgt 7y ago

davnicwil 7y ago

This is a good analogy, and when you're bootstrapping a product somehow it's extended further because in addition to being the architect you're also taking on the role of town planner, deciding where it gets built and thinking about if it should be built at all (do people need it).

pgt 7y ago
Town planner or city planner is a great analogy! The role conveys the uncertainty of future growth and anticipation of problems much better than an architect, who typically only does a once-off design. Thanks for that :).

endymi0n 7y ago

Having done hundreds of small to mid sized projects I take comfort in the fact estimating is a very distinct task that even the best of developers learn last. I've got three tricks in my pocket that at least help me with this: The first is that I go by the formula mentioned in "The Mythical Man-Month" — which is that the effort in larger projects is distributed as follows: 1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand Developers tend to mainly estimate their coding time, which leads exactly to the effects mentioned. It also explains all the annoying situations with all the holdups once the project is "almost done", this is simply a systems test and will add another 25%. The other is that I simply add 5-10% on top for each person involved into the project (dev, stakeholder, anything) for communication overhead. It usually holds true. The third trick is meticuluous focus on lean delivery, which involves scoping down, early testing on as much as possible, hidden and pre-deadlines and setting tractable sub-milestones. Unfortunately, all of these techniques don't accelerate the project, they just help you be more realistic. If you find something that accelerates complex projects, let me know ;-)

ido 7y ago
> If you find something that accelerates complex projects, let me know Developer experience. I've been working as a developer for a living for 18 years & I thought I was pretty hot-shit 10 years ago already, but I can probably do more today in 4 days than I used to in 4 weeks (or 4 months a few years before that).
- WrtCdEvrydy 7y ago
  This holds very true up to the architect level.
  - mannykannot 7y ago
    As learning curves generally flatten out, that is to be expected.
    - ido 7y ago
      I've switched sub-fields of development a few times during my career (scientific computing, back-end web, front-end web, desktop applications, embedded, games [various platforms - native desktop/mobile/consoles, html5, flash, etc]) and I found that helped me keep the learning curve steep.
tarsinge 7y ago
Really insightful, thank you. Also regarding: > If you find something that accelerates complex projects, let me know When possible cut scope and split the project in smaller projects with real deployments (much like you said with "The third trick is meticuluous focus on lean delivery, which involves scoping down, early testing on as much as possible, hidden and pre-deadlines and setting tractable sub-milestones."). In nearly all my projects I now propose something like this to clients: "Ok we understand your needs and requirements. What do you think about having a V1 with only these core features deployed in a few weeks (which ideally already provide business value), and after that we iteratively improve it?". Works great for smoothly throwing away all the nice to have.
7y ago

mattmanser 7y ago

For me Joel was spot on in my experience, and I disagree, you are always writing the same code again and again. Just tweaking it a bit to fit the requirements. An easy example is the thousands of JSON APIs you can integrate these days, where the code to do that is almost identical, but not quite. Generally the only complications are in what stupid authentication and pagination method this API came up with. But it happens everywhere in coding. Every system might need user management, but slightttttly different each time. Or sending emails but Bob already uses Sendgrid, where traditionally you've used mailgun. Also the software industry changes all the time. That email code you wrote ten years ago using SMTP won't be reusable. The invoicing system you built for one client using PHP and jQuery 1.7 in 2012? Not appropriate to sell to a client today. Basically you should have written things at least very similar to what you're estimating on. Then you need to find your "multiplier". The figure you need to increase your gut estimate by to get the real estimate. Plus, there's a lot of legal complication about reusing code with different clients, often you should be rewriting purely to be safe for them and you from a copyright perspective.

laumars 7y ago
In my experience working in a broad range of fields in IT; web development is quite unlike any other type of development when it comes to code reuse and framework churn.
- TeMPOraL 7y ago
  IME, web frontend might be particularly repeatable once you drop the artistics. But when I was doing desktop development, beyond simple UI issues, almost all work I had was unique and dictated by customer's ever changing and ever weirder requirements. In backend work, similarly, pretty much everything I write is a new and unique flower on a unkempt bush of the overall architecture.
  - mattmanser 7y ago
    Not really, I've built all sorts of stuff, but ultimately when you're hooking together a client's accountancy SaaS to their order system, it's going to be roughly the same code and take the same time as the other umpteen times you've done it for other clients. But it'll be a little different as they're using Xero instead of Quickbooks which you used last, and they have a different order entity design because of X. I really feel like anyone arguing otherwise is slightly delusional. I find it particularly funny the guy two up claiming frontend might be reusable code, but backend isn't. Once you've done one invoicing/emailing/workflow/search system/time tracking/credit control/custom form designer/forecasting module/cash flow/etc./etc./etc. module for a client, you've pretty much done 'em all. And after a certain point you can then start to estimate the complexity of other systems with a small amount of talking to the client and research that let's you know the scope and the gotchas.

LoSboccacc 7y ago

probably it's because developers tend to estimate the technical part first and foremost. then comes prouctization, then comes integration. if the estimate is consistently between 3x and 6x, that's what's likely missing.

ebiester 7y ago

I'm a strong proponent of learning formal and informal estimation methods - I'd start with Steve McConnell's book "Software Estimation: Demystifying the Black Art." For estimates that I would put money on, I will estimate in 4 hour blocks and get features down to the most granular level. If I don't understand it at that level, I don't understand it well enough to estimate yet.

saalweachter 7y ago

One of my favorite shows is Grand Designs. Building a house is probably the most understood human activities; as you stated, you can take a standard design on a normal building lot and throw up a house in a very predictable amount of time. If you've done it enough, you can write down a schedule of when every piece of material and every trade needs to be on site. Grand Designs always involves some combination of unusual design, unusual sites, and unusual techniques, and frequently inexperienced builders. People set out to accomplish something grand, and usually succeed, but it takes much longer and more money than expected, and especially more than constructing a conventional house on a conventional lot. Now, besides echoing your point that many novel software projects are much more akin to a Grand Designs house than a cookie cutter ranch in a Midwestern suburb, in Grand Designs one concept that is proved true time and again is that once you are out of the ground -- once you have your foundation in, your gas and water and sewer and electric hookups -- the hard part is over and the job will proceed much more smoothly. It's hard to estimate before you get out of the ground, because the ground is filled with unknowns and unforseen problems. You might still misjudge how long it will take you to finish, particularly the finicky details that always take forever, but this is purely a failure of estimation; an experienced builder could predict the time to spackle, trim, paint, install flooring and built-ins accurately, you just didn't realize it. But under the ground, there are all sorts of problems with rocks and water tables and pipes and whatnot you can't predict. Do we, as software engineers, have a similar inflection point in our software development? Do we ever get "out of the ground", to the point that most of the unknowns are known and we have a predictable (if still great and difficult) amount of work remaining?

antoniuschan99 7y ago

This is a great analogy on why it's so difficult to estimate: https://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe https://www.quora.com/Engineering-Management/Why-are-softwar... Estimating should be fun, plus there are various ways, such as estimating as a team (majority wins), t-shirt sizes, etc