5 ms·

So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing. Let's extend the analogy somew

• code_duck 13y ago
  The hiking analogy works pretty well, extended to traveling in general. I spent a couple of years traveling around to visit friends and family all over the US, and regularly my estimates were off in when I'd arrive somewhere. My software delivery estimates are similarly not perfect, in the later direction like most people. My conclusion was that my estimation of how long it takes to do anything is off a bit. For me, this is because I'm trying to say I'll do something sooner to meet the perceived needs and desires of others.
• icelancer 13y ago
  Spot on. NTE billing puts the onus on you and gets you actually thinking about it. Helped me a ton.
• avmich 13y ago
  "Developer estimates are regularly off because they seldom impact the developer directly." I think I most disagree with this. Developers, in my experience, are quite often asked to leave the company after such estimates. It's good to have a template - it helps not to forget things - but it is inherent in the work to have unknowns. Large unknowns. A good consultant would probably refuse to work on a project which would require him to use several major technologies which aren't familiar to him, but developer in a company may not have such a luxury as selecting a kind of a project.
  • crusso 13y ago
    Developers, in my experience, are quite often asked to leave the company after such estimates. I've seen developers let go because they weren't very good at writing software. I've seen developers let go because they were painfully anti-social to the point that they were negatively impacting the rest of the organization. I have never ever seen a developer let go because their estimates were crappy.
    • cs02rm0 13y ago
      You must have good customers then that value quality software over meeting deadlines. Not government I take it?!
    • avmich 13y ago
      Our experiences obviously differ. Usually it goes like this - the developer gives his best estimate (which is, by the way, hard by itself - a lot of things has to be taken into account), and that estimate is considered too high. So the developer is ordered - in one form or another - to, effectively, "do it faster". Often it's by cutting corners in places deemed least important - but then it also reduces probability of the correct estimate overall. One more thing - specifications are quite rarely are good enough - there are other reasons why that's the case - and the final result causes management to wonder, why it doesn't include this, of why that works this clumsy way. So nobody's happy - and developer pays the price. It may look as the developer isn't good at writing software... because "writing software" is a sort of encompassing figure.
• kronholm 13y ago
  Been going at it for a couple years now with consulting and freelancing. I've finally gotten good at hitting my estimates. What worked for me was to keep strict time of everything (shoutout to toggl.com, love it!), so I could learn from my mistakes. The trouble is now though, my competition seems to be underbidding me, but in reality they're providing those ~33% estimates they will never realistically keep, while I'm at ~100% estimates. Not really sure how to relay that to clients. One of the many reasons people like me need a salesperson in front, I guess.
  • avmich 13y ago
    If you're really good at estimates, try to play that you can keep not only the final delivery, but also the partial ones. Something like "you can be sure I'll get 100% done because you can check when 10% is going to be done". Sure it's not a guaranteed sale - and it's harder to keep both partial estimates and totals, comparing to only totals - but it's still something.
  • crusso 13y ago
    What worked for me was to keep strict time of everything (shoutout to toggl.com, love it!), so I could learn from my mistakes Right, that was part of my method as well. I learned to keep really good notes of each part of the project. At the end of each project, I compared my "what I thought it would take" with "what it actually took". In subsequent projects, I tried to match up similar complexity items with "what it actually took" notes to remind myself of the pain.
    • kronholm 13y ago
      Same! And I'm sure the reason it didn't take that long with getting good at it, was it hurts like hell when you do the 33% thing on a couple large projects, when you're on your own.
  • RyanZAG 13y ago
    You're probably losing more business than you think - customers have no idea who is accurate or who is just faster, etc. They will generally go with the lowest quote regardless of other factors unless they've been burned before multiple times. Most people haven't. I don't have a solution here though other than noticing that underbidding and then getting skilled at convincing clients to do paid extensions later actually appears to make the most money at the cost of your ethics. I'd avoid that approach, but it does seem to work for a lot of companies. My personal approach is to quote for very bare projects with only the bare essentials (eg, poor UI design, minimum possible feature for the client to see what they're asking for, etc). This can usually be done a lot cheaper than most people think as 90% of the work is in the last 20% of the features. Then once the client has something, you can give them a quote to touch up the parts they need. Basically you split the project up into many small projects each with their own quote which helps you to estimate tasks as they appear and helps your client to minimize costs by leaving off features that are more expensive than they initially appear.
• thirdtruck 13y ago
  Have you shared these spreadsheets and lists online? They sound like something that could turn into an excellent, three-figure or more information project.
  • ataylor32 13y ago
    I, too, would be interested in seeing these. Here are some guidelines from somebody else that I found helpful, though: http://www.missionfamilybank.org/software-estimating/ http://www.missionfamilybank.org/software-estimating/
    • thirdtruck 13y ago
      Thanks!
• pjungwir 13y ago
  Yep, I agree estimates are a lot more important when you work for yourself. I've had at least one client comment on how pleased he was that my estimates were usually accurate. I know another developer was giving him answers like, "That will take 5 minutes!", so perhaps his expectations were low. :-) On the other hand, giving realistic estimates I often hear clients say, "I asked around, and other folks say this should take half what you're quoting." Usually this happens before the work, but I once had it happen in the middle of a long-term engagement after I delivered a two-week invoice, and they were disappointed I hadn't accomplished more. So if I'm not careful I can lose my clients' trust, which is my highest asset. I've gotten pretty good at explaining why a job isn't 5 minutes (or 1 day, or whatever), but I might save this article as something to share if a client doesn't have much experience doing software projects.
• wpietri 13y ago
  I'm glad you got better at it, but I don't think software estimates can ever be very good. Nor should they be. That a project is estimatable has to mean that novelty is low and predictability is high. But low novelty is a sign of duplication, which should be factored out into things like libraries, frameworks, and self-service tools. High predictability is either a sign of duplication or it's a sign that people have basically agreed not to learn anything during a project. If you are shipping early and often and study users and metrics as you go, then you will always learn things that affect the plan. Which means that the schedule isn't predictable even in theory.
  • crusso 13y ago
    First of all, don't overly aggrandize what we do. 99% of it is derivative in most ways. Although I've enjoyed doing the work on many of my projects, I'm not under any illusions that what I was doing was ground-breaking. Besides, most of the things you mention can be accounted for. If part of your development process involves iterating through the design with the customer every couple of weeks then you build that into your estimates. Likewise, I always build documentation and code handover support into any serious project rather than acting surprised that customers will want such a thing and expect it to be part of what I'm delivering.
    • wpietri 13y ago
      99% of what some people do is derivative. But if what they're doing is software, that's expressive duplication, and it's worth trying to DRY it up. I think we have different intuitions here because it sounds like you're more in a service business than specifically writing software. I agree that a lot of any service business is standardizable, because it's mainly about people and their needs; that has a lot of regularity. But I don't think the software creation part of a service business is standardizable over the long term. During the first wave of "put smallish businesses on the internet" each web site was custom, hand-rolled software. Early on those schedules were unpredictable, but for a while, it became a known, predictable business. That business has, in the long term, been basically destroyed. People spotted the regularities and developed common code and tools. What was mainly a problem of software development became a (much smaller) problem of installation and configuration. The competitive advantage for those people now lies not in coding ability, but in customer service and in helping people manage the essential complexity of the domain.
• brudgers 13y ago
  What makes the hiking analogy perfect is that people are so accepting of it as an analogy. My first thought: Why the fuck are you hiking to Los Angeles? Plane, train, or for adventure, Greyhound. A sailboat makes more sense. A bicycle makes more sense. And if you insist on walking, at least follow a fucking road instead of cutting cross country. If you decide the first step to driving to LA is mining iron ore to smelt for casting an engine block and building a Bessemer furnace for the steel for hand forged pistons, then there's lots of shit that can go wrong, EPA permits and zoning laws, even if you've done done it before. The reason software production estimates are bad is because they aren't taken seriously. The guild of programmers can say, "we shall get from A to B by cross country hike." Yes, the analogy is perfect because its absurdity is acceptable.
• loceng 13y ago
  What are you doing now?
• sbov 13y ago
  Part of the problem is good estimates take time. For many things you can't give a good estimate after 10 minutes of analysis much less the 10 seconds some people ask for. Because of this I offer two estimates: one that might be off by a factor of 100x, and those that are fairly accurate but take more time to make. My boss usually goes for the former. Edit: also there's two types of estimates. One measures how much of my time it will take. The other measures the date it will be done and/or live. The two are oftentimes different numbers, and as a developer I can't always control the 2nd.
• gcv 13y ago
  It's more like this: you've been on dozens and dozens of hiking trips. Except these trips generally go through seismically unstable territory and war zones. You just never know when you'll have to dig a tunnel underneath a battlefield to get to the next river you'd have to cross — a river unmarked on your map, or perhaps the result of some aggressive "engineering" by someone since your map was drawn. Then you get an urgent message from your customer: you weren't supposed to hike from SF to LA after all. You actually need to go from New York to London, on a submarine. Specs require that you do this without surfacing or refueling. So you need to design a nuclear reactor, figure out a way to put it on the leaky old U-Boat your customer just happens to have lying around. All within the same timeline as before, and in the same budget. You've had all this happen to you a few dozen times, so you factor in the time you know you need to build submarines (all just different enough, of course, that you can't reuse parts, even if the customers let you adapt, say, the propeller shafts to a new customer's design: I hear that in software, this is called "DRY" and "using libraries and frameworks" and "refactoring") — and you give an honest estimate: "it'll take eight months of full-time work, and will cost you about X hundred thousand dollars (a bargain for a nuclear submarine, if you ask me)" — and the customer will then go to someone else, leaving you wondering how you'll pay your bills.
  • crusso 13y ago
    Meh, you're just contriving extreme circumstances for your analogy so that the software developer is both a super hero and has no blame in being late with deliverables. There are simple methods to combat gross inaccuracies in the client specification. You document the requirements for what you'll be delivering in a carefully worded Statement of Work that the client signs off on, you ask to be paid in chunks as you go with a portion up front, and you implement a system of change control so that it's totally clear if the customer is sending you off in a completely new direction. At that point, you book what you've worked at your hourly rate and you submit new work and time estimates for the changes.
• rquantz 13y ago
  Would you be willing to share these checklists you've created? I would be curious to see them.
• Iftheshoefits 13y ago
  Let me fix that for you: Developer estimates are regularly off because "experienced development managers" are all too eager and willing to allow organizational politics and external influences to add complexity in ways the developers cannot anticipate. Inexperienced developers' estimates are even further off because of their relative lack of experience. I assure you, the first time a "development manager" tries to scapegoat his subordinates for his own failures to deliver to these external influences his subordinates realize that their estimates impact them eventually, and directly.
• coldtea 13y ago
  >So the article tries to describe the hidden complexity of software with a hiking analogy but then it leaves a huge part missing. Let's extend the analogy somewhat... this isn't your first hiking trip. In fact, you've been on dozens and dozens of hiking trips. You're an experienced hiker. Yet, why do you continue to give meaningless as-the-crow-flies estimates of how long it will take you to get to your destination? The reason is that if you miss your estimate, it probably won't matter. Nice try, but no. Developers who are DIRECTLY affected from missing estimates (e.g one man shops paying out of their own pockets, people building an app while having quit work, eating ramen and maxing their credit cards etc, developers in companies who will personally pay for any delays by attrocious, unpaid overtime crunch marches, etc) underestimate the time needed to get something done just the same. Just ask Allan Odgaard (of TextMate 2 infamy).
  • nnq 13y ago
    100% agree on that. I did a lot of bad estimates and was directly affected by them (fixed rate projects that ended up driving my rate to "below mcdonalds worker" and some even with "lateness discounts" because I just wanted to keep the customer happy), and it took me a lot of time to get better at estimating even if I was paying from my own pocket for all the bad estimates. Now if I am to hire a developer I will never think that "his estimates are bad because he's not directly affected by missing them"!
• natmaster 13y ago
  If you've been hiking on similar trails so much, why haven't you built a land rover or rail system that gets you there every time? You're like the expert sherpa trying to convince people to use your message delivery service when the internet exists.
  • wildgift 13y ago
    The Sherpa are an ethnic group, not a job.