16 ms·

What do you mean ‘we need more time’? Project schedule estimation in software

238 points by hepha1979 11y ago

bluesign 11y ago
I think also one of the biggest mistakes is making over estimates, or playing too safe. Especially when working with big teams and multiple projects (with a lot of dependencies).
- pjc50 11y ago
  Why - has that led to a spate of projects completed early?
  - yoo1I 11y ago
    no... effort required seems to expand to fill the available time allocated to it... and then spill over some. Which is why it's also a problem.
  - Ensorceled 11y ago
    It leads to what I call "do it right syndrome". Since I have time, I'll do it right, with a factory class, and extendible configuration package (that I'll write myself so it will be just perfect) and, for optimal speed, I'll use Red-Black trees that I'll have to write my own implementation of since there isn't a standard library ...
    - pestaa 11y ago
      What's wrong with separation of concerns, extendability, optimal speed, etc.? More often than not, I observed doing it right the first time is actually a huge time saver compared to hacking some stupid prototype nobody can understand later.
      - sombremesa 11y ago
        Agreed, except in cases where the code will never be maintained again (e.g. game releases on N64). In my experience an "over-estimate" that leads to the so called "do it right" syndrome happens if someone else estimates for a developer. When the developer makes the estimate him/herself and doubles it, you can be damn sure they are going to need all that time and then some to even get it in the ballpark of long-term acceptable. (That being said, the company needs to have standards for code acceptability in the first place, which doesn't always happen)
      - Ensorceled 11y ago
        You are saying I'm wrong because good engineering is better that writing crap. Except that's not what I said; I was saying over-engineering is bad and we should stick to engineering.
- melted 11y ago
  Underpromise and overdeliver — that's the secret to professional success.
  - dreamfactory2 11y ago
    and a rookie mistake in sales
    - sixothree 11y ago
      Sales pressure is sometimes the primary reason when our estimates are under.
    - melted 11y ago
      I'd argue that promising what you can't deliver is a mistake in sales, too.
- bliti 11y ago
  How do you get the right estimates then? Mind sharing your techniques?
  - bluesign 11y ago
    I was on the developer side, whose estimates are usually doubled by PMs. (or if we go by the story theme, they always assumed 'primer' may needed on every paint job) Then we had a lot of scheduling problems, and low effiency ( you finish painting the room, but people who will gonna move furniture still not available)
13hours 11y ago
Almost at the end : "Yes, all this sounds like a lot of work". Exactly. And it will most probably still turn out to be wrong, because you will forget to ask some questions, and there will be things that you simply cannot foresee that will influence the time. Turns out it's pointless to even try to do this. So why waste valuable time to do all this, if you know it's not the truth anyway? The answer is to accept that you will learn things as you go along, and that things take as long as they take, and to rather deal with that. Marketing wants a product by Christmas. Fine, we can do that. They just cannot say what needs to be in that product by Christmas. They can have whatever the last production quality release is at that stage. Instead of taking many weeks or months to try and answer all these estimation questions, we start and tackle the high risk items first. We learn from them, readjust, and as we get closer to the deadline, we keep communicating with all the other stakeholders what we think will be delivered on that date. It's a narrowing cone of uncertainty. One sprint before the deadline we'll be pretty accurate in predicting what it will be. 2 or 3 sprints before, accurate enough to be able to do marketing. At the start : the best we can predict is simply whether we feel we can have something useful at the deadline.
- soft_dev_person 11y ago
  Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...
  - 13hours 11y ago
    I used to as well, until I started to refuse to do it. It truly is in the best interest of the customer to work this way, and I explain it to them. The ones that understand it and buy into this way of working are the ones I work with.
    - soft_dev_person 11y ago
      Sounds awesome. Unfortunately I don't work in my own company. Fortunately, I don't work with sales (much).
Theodores 11y ago
The thing that annoys me most about project estimation is when the micro-managing types don't let you even look at the problem space first, an instant answer is expected. Of course the figure plucked out the air could be 'x days' with 'x' being greater than the time one expects internally so backside is covered, yet that is not really a true answer. At the moment I am putting together a 'simple' feature on a website, where I have been able to explore the problem space first. For the $content there actually needs to be half a dozen date fields that were not in the original brief, I doubt I would have discovered this had I not rolled a little bit of code first and explored 'prior art' in the area. I need to put together a semi-working prototype to discover such things - particularly when UX is involved. Yet, far too often, the opportunity to do actual preliminary dev work is denied by those that 'know best', preferring a spec. in a Word document (or something else equally 1990's) instead of a rough working prototype in code (with back-of-envelope sketch). My current feature-being-added will need to be re-factored at some stage, once users have started using it and problems/features overlooked in the original brief catered for. It is not as if the users of my new feature will know that 'actually they wanted it to work this way' until they have something to see. So why we have these silly cast-in-stone processes I do not know. I also must say that I find the metaphor of painting a room is quite a poor one, I would not need to paint 'an alcove first' to get a handle on how long the whole room would take.
- Ensorceled 11y ago
  Actually, the metaphor is pretty good, except they missed a key change: in real life if the "test painting" shows you need to "prime first" you now have no idea how long it will take without starting the estimation process all over again. So, in real life, paint the room is "2 days or, if the test painting goes badly on day one, I'm not sure and won't know until the end of day 1". And people don't like those kinds of estimates.
  - crpatino 11y ago
    If that's the case, you assume priming will be needed in your original estimation, then go do the test anyways, and at the end of day one you will look like a hero when you say "hey guys, I think we can get away with cutting priming from the plan, we just saved $abc from the budget and xyz days".
anon4 11y ago
> The fact that I technically only asked how long the fix would take is something only an engineer would bother pointing out. -_- Well excuse me for not fitting your prejudiced profile for a neurotypical extroverted 20-something white male. Yes, I might have needed the clarification between "how long will it take you to paint the room" vs "how long until the room is back the way it was with the walls in a different colour", but you help noone when you talk down to the painter like that. You asked a question and I misunderstood, because we use slightly different language and I have a ton of other things to think about all the time. Can we stop this "oh let's treat engineers like they're children with mental development issues" already? I'm not some god in an ivory tower, I don't want you to kneel before me, I just want the usual everyday respect you afford to your peers and to engage with me as one professional with another. This kind of treatment is not ok.
- Ensorceled 11y ago
  Agreed. As an engineer, I can also claim that if I say "we can deliver that March 15th", then I get a argument about why can't it go out with the Feb 28th release and why is it going to take 30 days to do something simple and why ... all because marketing people can't understand delivery cycles. So, let's just not have that type of conversation at all.
  - ams6110 11y ago
    Ever talk to a contractor about a home renovation, or even a painter as in this story? If you start questioning why something will take so long, in my experience the usual answer is something like "if you think you know better than me, do it yourself." Especially if they are good at what they do. Most good tradespeople have more work than they can do, and will just walk if they think a customer is going to be a pain in the ass. How often will developers take that approach?
    - crpatino 11y ago
      Well tradespeople usually work for multiple clients on smallish projects. For good tradespeople, a significant number of those projects come from repeat customers, which means their optimal strategy is not to serve all customers equally, but to prioritize those that are more likely to bring repeat business down the road. A difficult customer is usually not someone you want to do repeat business with, so they get "managed out" pretty reliably. Most software engineers, on the other hand, work for one big customer at a time (your employer). And though I agree that a bad employer at the end of day is detrimental to your career, you cannot afford to switch jobs on trivial matters, on risk of getting labeled as a grasshopper. That's why you do not see developers "walking".
kbouck 11y ago
Regardless of project/planning methodology, having a ever-growing checklist of less-obvious estimation items is a simple way to avoid forgetting to consider them. The book "Software Estimation: Demystifying the Black Art" [1] by Steve McConnell contains a number of these. Some examples: - Team or company meetings - Team member sick days, holidays, vacations - Bugs in third party software - Maintenance of previous systems - Maintenance of build automation - Demos - Interviews - ... ... or your own list of whatever other items you have historically forgotten, or tend to forget when estimating. In the painting example, the moving of the furniture was something I overlooked, despite having made the effort to carefully think of all tasks. A estimation checklist built up from previous painting projects could have triggered me to consider this task. [1] http://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351 http://www.amazon.com/Software-Estimation-Demystifying-Devel...
dreamfactory2 11y ago
article assumes specs are known. they might be for some kind of brochureware but for any serious work they never are, and in business reqs change day to day. 60% of software features are never used - so that's 60% overspend right there. there's no reason not to do fixed cost agile (personally wouldn't do it any other way). trying to fix scope otoh is just bad business from the get go - a) you might have target outcomes but you don't know exactly what you're going to need to get there b) useful software tends to be ongoing in terms of reqs
mzahir 11y ago
http://qr.ae/ROlwZp http://qr.ae/ROlwZp - I've found this answer on quora to be one of the best explanations as to why software estimates are so off.
- mannykannot 11y ago
  Digging down into the details is one of the best responses to absurdly unrealistic schedules.
cateye 11y ago
Analogies like "painting a room" are pretty useless because they are very misleading. Especially when it is an innovative product, a better analogy would be: "painting a room on Mars". With software development, there are a lot more "unknown attributes" that determine the main part of the effort estimation unless it is a repetitive task. So, a critical/skeptical engineer would always drive the customer nuts by asking questions nobody can know and the conclusion will end somewhere like it is not possible to give a upfront estimation and stop the project. Or the effort to give the estimation approaches the effort to develop.
- GFischer 11y ago
  There are several different categories of software projects, as you say, the innovative ones might fit your definitions, but I'd argue that most don't. The most common kind of software projects I've encountered are very straightforward, mostly just CRUD with an interface + business logic, and reporting, or relatively straightforward websites. Those are the "paint the room" type of projects. There are challenges with those kinds of projects, but they should be reasonably easy to estimate, as long as the team is somewhat familiar with their development tools. Other kinds of projects ARE more difficult because they have unique or innovative elements (probably the case for a lot of startups). Those might be the "paint a room on Mars" kind of projects. As an employee, I've encountered the first kind 90% of the time. As a startup founder, I have encountered a lot more unknowns, but I've still found my project reasonable to estimate.
- erikb 11y ago
  Before NASA sent their first drone to Mars they made a lot of predictions, a lot of tests, guessed a lot of things that may get wrong, etc. Do some of their missions still fail? Sure. But the amount of success is much much larger because they didn't just sent a drone there and watched what happened. So even if all you say is correct it's still worth improving one's estimation skills.
  - lmm 11y ago
    > Before NASA sent their first drone to Mars they made a lot of predictions, a lot of tests, guessed a lot of things that may get wrong, etc. Do some of their missions still fail? Sure. But the amount of success is much much larger because they didn't just sent a drone there and watched what happened. How much effort went into estimating Opportunity's lifetime at 90 days? How useful has that estimate proven to be?
jahaja 11y ago
I may be cynical at this point but overeager project scheduling/estimation processes and top-down software processes in general are really where software development as a creative and experimental occupation dies.
- crpatino 11y ago
  If you can do "creative software development" and get paid for it, count your blessings. And better yet, give a very big "Thank you!" to your manager. The reality of this trade, regardless of you doing in-house work or a product for the market, is that everything is required for yesterday. There is an "economy of pressure" where every stakeholder pushes everyone else as much as they can in the expectation that they will be pushed as well. If you do not get to experience this, it means someone in your chain of command is very good at pushing others, and that some other part of the overall system is shouldering most of that pressure all by themselves.
  - jahaja 11y ago
    So if I understand you correctly you're saying that "creative software development" is inherently incompatible with the hierarchical realities of the corporation? If so, I think you're probably right. "The reality of this trade [..] is that everything is required for yesterday" But it just isn't. This is an artificially created pressure for selfish reasons, and should not just be accepted in passing.
    - bigmanwalter 11y ago
      The game is rigged. Only way to win is not to play.
      - sombremesa 11y ago
        Or according to the parents of this reply, to play under the wing of an expert player.
alistairSH 11y ago
In tech, we spend little time talking about the softer skills like communication, project management, and prioritization. Well, that's not a good start. Maybe my career has been abnormal, but I've spent a lot of time thinking and talking about project management skills, particularly estimation. It's something my employer expects all non-junior employees to do - more than half my team are certified in scrum or have taken courses in other PM methodologies. For most of what we do, the hard part is project management. Sure, the techie code stuff is usually more fun, but that's not even half of my daily workload (and hasn't been since well before my title changed from "product architect" to "project manager").
davidgrenier 11y ago
> These are the skills that elevate someone from a good programmer to a great software engineer I stopped reading at engineer
- ddingus 11y ago
  You really shouldn't. While the term engineer is loaded with the licensing and professional aspects, and understandably so, the people working with software very often do actually have to perform the task of engineering solutions. Dismissing a valid dialog on this basis does no one any real good. Despite the issue you raise, the query and discussion remain valid and high value.
work-on-828 11y ago
As a new grad who has worked a couple different jobs now, some things I don't get about this: - What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature? - The author says that estimation is easier to do if you are doing something you have done before. What do you do if you are always working with a new framework or language? - How do you break down the steps if you don't know what a project entails until you are finished? - What do you do if asked to estimate how long something will take to debug? What if you just started on a project and the error message you are trying to debug doesn't make sense? My approach there is to try to understand the system I am working with. If the system doesn't have documentation and the existing people on the project don't have time to give a walk through of things, I figure that means source diving. However, I've gotten the feedback that I should avoid trying to "understand the universe" when debugging. What can I do to produce accurate estimates of how long it takes to find a bug in a system without spending the time to gain a mental model of the system? - This excercise takes a lot of time. What do you do when asked for an estimate in a meeting rather than over email? What - What do you do if the thing you are building relies on getting an external API to work and that API is either undocumented or is documented in a foreign language? Assume that the google translation is not making sense and this is your first project and you don't have a budget to hire a professional translator? This sounds like something you would need to get working before you could actually give an estimate. Why do experienced engineers ask for estimates anyway? Every time I give one I feel like I am lying and I try to warn people "I really don't know how to come up with estimates but I am guessing 3 hours". How do I deal with it when they are upset about it taking a week and a half?
- fenier 11y ago
  It comes down to experience really. The more you are exposed to, if you are paying attention, the easier it becomes to relate to previous events, which can help inform estimates. If you don't have a spec, get a spec. A Senior engineer may be more reluctant to help you with implementation direction without knowing the requirements. Sometimes you need to do research to give an estimate. If someone asks you in person, or over e-mail, and you honestly don't know ask them if you can get back to them. Do not give them a number. Do the research, then reply. If you're relying on external APIs or Frameworks etc. You need to factor in Risk Assessments that include what happens if the fit is wrong, or the interface changes mid project, etc. When it comes to debugging a lot comes into play, system design, documentation, experience with the code. "I don't know" is an acceptable answer until you understand what is going on. Once you understand what is going on, you then estimate the fix based on the code. Giving a number before you understand what you are fixing in detail is a bad plan. I am exceptionally experienced with a certain code base and system. You may be experienced with a different code base. You're more qualified to handle estimation on what you know. That said, if you honestly don't know, say that. Don't low ball the amount of work if you actually have no idea how long it will take. There are a few good books on estimation and debugging, look around maybe they'll give you a few ideas.
a3n 11y ago
As long as sales, or its local equivalent, commits to as yet non-existing products and features, it will ever be thus.
deleted 11y ago
[deleted]
beat 11y ago
The tendency to estimate poorly - particularly to underestimate - is one of the key reasons to use a very tight, short-iteration agile process. If I estimate something will take two days, and I'm off by 50%, it'll take three days. If I estimate it'll take two years, and I'm off by 50%, it'll take three years. And because I can get a lot more practice at two day schedules than two year schedules, I'll improve my accuracy over time, through steady practice. This takes us back to the triangle of constraints that Kent Beck talked about in the first Extreme Programming book. There are three constraints on projects - schedule, scope, and resources. You can control two of them. Generally, resources are inflexible. So in practice, projects are either schedule-bound (we must hit this date) or scope-bound (we must have these features). A project that tries to do both, without a significant resource surplus, is probably doomed. Since estimation improves over time with short iterations, it seems better to me to be scope-constrained than schedule-constrained. With steady progress, you can achieve the goals eventually. Good agile processes are much better at saying where you are and where you're going than when you'll get there.
- p4wnc6 11y ago
  I've never experienced estimation improving over time in an Agile process. In fact, since short estimation cycles are just as susceptible to political games as longer cycles, and this dominates the whole process in any organization, the length of the estimation cycle really has nothing to do with the estimation issue. But, what shorter estimation cycles are responsible for is a decoupling of the overall big picture progress from the immediate tasks being prioritized. This often leads to sprints that are well scoped, and everything in the sprint gets completed close to on time (at least as close as in longer work cycles, but not usually any closer), but, crucially all of the work has to be scrapped because the whole sprint, conceptually, was not right. In my experience, this happens maybe 1/5 of the time in Agile exactly in ways that would be prevented with longer-term planning. It's very similar to the classical fractal effects of measuring the coast of Britain. By refining your ruler, you merely think you're being more accurate, and a lot of people are doing a lot of performative managerial crap for the sake of the Scrum performance, like a ritual. It feels like you are estimating better, but really because the whole meta-level concept you are working on isn't guided by longer-term thinking, you end up having so much round off error, added up over more and more cycles, that the overall waste is colossally greater than systems that involve some more significant longer-term pre-planning and which work on variable cycle lengths instead of a cookie-cutter, one-size-fits-all approach (which is the core philosophy of Agile, though people try to obfuscate this fact by No True Scotsman-ing it with the Agile Principles). I also can't miss the opportunity to point out this great article on the political games we play during estimation: < http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC322/F09/files/EstimatingGames.pdf http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC3... >
Gratsby 11y ago
I'm about to being a rant here because this is a larger problem than anybody likes to admit. Developers are good at development. By and large, they are not good at task management, project management, and certainly not estimation. One of the primary reasons for this is that their plates are always overflowing and they work more efficiently than many people in other professions. They shift priorities on the fly when work in one area cannot be progressed. Development time is social currency. You can make your boss happy by progressing his priority, or you can make someone else happy by progressing their priorities. Not many developers truly answer to a singular master. And few allocate time for learning although we all spend a significant amount of time doing it - how else do we maintain relevant skill sets? Can a developer really estimate a project and tell his manager that 3 weeks in the timeline are for 2 unknown and unforeseen problems that require interaction with vendor support? No, because the manager will fight back and say that those 3 weeks are really just zipping up logs and making three phone calls and "if it takes anything more than that, hand it over to me!" Most can't tell their manager that it will take 2 weeks to parse a CSV because the source data is shit and they have too many other things they are working on. So they stay an extra 6 hours in the office and get called a rock-star until the day that they opt to go to their child's school play instead. The solution to this problem is simple. Take task management and project estimation out of the hands of developers. It's time for the return of the secretary to the workplace. A single $50-80k administrative assistant could easily support, manage the priorities of, and improve the outward facing communication for five developers. With experience doing so, that admin could provide better time estimates for all of them and would be better at negotiating realistic timelines than any of them individually. People have been coming up with methodologies and software to solve this problem for decades. Developers don't have brains built for project management. Yes, they can do it, but they don't get paid to work in MS Project. They get paid because they know the difference between a bubble sort and a quick sort and when to use either. Conversely, I don't know a soccer mom who doesn't successfully manage a more challenging schedule and competing set of priorities better than every nose-down developer I've ever met. Give appropriate work to appropriate people. Developers have their talents. Scheduling, estimating, and task management are not among them.
- orky56 11y ago
  Ideally a product manager solves or assists with many of those problems- 1. Reduce the ambiguity of what features to work on and what are the priorities. This involves being the barrier from other manager and team members trying to pull a fast on and changing what should be worked on. 2. Stay on top of what the latest estimates are in an honest and transparent way. Product managers as project managers should be able to translate what a particular developer says into what estimation might be in reality. They can acquire or release resources, or even change scope accordingly or at least make the case. 3. Product managers should provide developers a constant opportunity to break down tasks into components that can be tracked easily in Asana or another task management tool. This takes discipline as a product manager to enforce a system onto developers in ways that make sense. Disclaimer: Product manager here.
orky56 11y ago
One of the fundamental issues is that upper management sees estimates as bell curves as though 50% of the time a project may finish early. In reality, very few projects on time, let alone early. No one wants to hear about reducing scope but at the same time an MVP that solves the customer problem without feature creep should be evangelized within organizations. In reality, schedule follow more of an exponential function where slippage time goes from bad to worse very quickly as resources/scope/schedule snowball very quickly. Things get scrapped before we see this in practice.
gjkood 11y ago
A pet peeve of mine: Scenario: Finished requirements, analysis, design; completed development and testing; in UAT; Production deployment: 1 week away. Customer: Hey this field name does not exactly represent what we want to convey. Can we change its name quickly before we go live? Eager Novice (who is unfortunately in front of the customer at that moment): Oh yeah, that's just a small change in the Customer model. I think we an get this ready and unit tested in 2 hours. Customer: Great. Lets git er done! Project Manager (wary of customer and afraid to rock the boat on an already shaky project): Sure we can do that. Grizzled Veteran/Grey Beard (who for some reason wasn't consulted on the change request): Hmmm....have we done an impact analysis of the change? What are the downstream impacts on code that references this field? What do we need to do to propagate the change to the db? What about the seven or so Web Services that are impacted by this field change? How long does it take to do a regression test? etc... Net effect: 2 Hrs initial estimate given to customer; 4 Days worth of work in actuality; Production deployment moved down a week..
- edc117 11y ago
  Agree 100%. Golden rule: Never give off the cuff estimates (even if you're sure).
mikeskim 11y ago
You could just use data, machine learning and optimal control to make better estimates. It has aleady worked for fighter jets, self driving cars, and automated factories. With enough data it will work for anything.
- chillacy 11y ago
  What kind of features would we use? Which prior projects will help predict how long it takes a team of 3 developers (one of them senior with a history of underestimating time, two junior with little track history) to produce a novel photo sharing app where the requirements might or might not change every day? The problem I see is that there isn't enough data, and the problem space (the number of possible projects and teams) is too large to draw meaningfully on past data. Unless we're looking to predict specific CRUD apps where the requirements are known up front and a team cranks these out consistently. Humans have already been flying fighter jets, driving cars, and doing work in factories, so we know it's a learnable skill. We have not yet learned how to estimate arbitrary software production.
geebee 11y ago
Estimates are a tricky thing. Ultimately, I don't think they work in software. We should be looking for a different solution. Think of it this way - a physician can prescribe a medication and tell you how long you'll be on it, but can she estimate how long it will take before your blood pressure falls within normal parameters? She can tell you what has happened in the past, but suppose you take the medication and your blood pressure remains stubbornly high. Has she failed to meet her targets? A lawyer may be able to tell you, roughly, how long litigation tends to take, but can your lawyer estimate how long a case will take, what it will cost, what the outcome will be, and the date it will all be wrapped up? If that doesn't happen, did the lawyer fail to meet targets? Well, in both cases, sort of, yeah. You didn't get the outcome you wanted. But these professions, run by the people who staff them, understand what can be predicted and what can't. This blog entry uses the task of estimating painting a room as an example, and focuses on breaking the task into subsections. Ultimately, I think the entire approach is deeply flawed, and it all starts by thinking that software development is similar to something like painting a room, just a more complicated version of it. In my opinion, it's very different. Of course, it's very different from prescribing medication or litigating as well - in fact, I'd say that it's generally considerably less predictable than even these things. I'd say it's closer to writing a novel, creating a film, or recording an album, except that software needs to work, and can be much more mundane at times as well. Ultimately, I don't think the analogies are useful, we need to realize that software is its own thing, and steer clear of too much reasoning by analogy or example. Unfortunately, the anxiety caused by making estimates under conditions of uncertainty (and possibly duress) is a source of stress and unhappiness for developers, and I do think it's one of the things that drives people out of the field. I actually think this may also be one of the reasons people love creating apps as a hobby but hate doing it for money.

238 points by hepha1979 11y ago

I think also one of the biggest mistakes is making over estimates, or playing too safe. Especially when working with big teams and multiple projects (with a lot of dependencies).

pjc50 11y ago
Why - has that led to a spate of projects completed early?
- yoo1I 11y ago
  no... effort required seems to expand to fill the available time allocated to it... and then spill over some. Which is why it's also a problem.
- Ensorceled 11y ago
  It leads to what I call "do it right syndrome". Since I have time, I'll do it right, with a factory class, and extendible configuration package (that I'll write myself so it will be just perfect) and, for optimal speed, I'll use Red-Black trees that I'll have to write my own implementation of since there isn't a standard library ...
  - pestaa 11y ago
    What's wrong with separation of concerns, extendability, optimal speed, etc.? More often than not, I observed doing it right the first time is actually a huge time saver compared to hacking some stupid prototype nobody can understand later.
    - sombremesa 11y ago
      Agreed, except in cases where the code will never be maintained again (e.g. game releases on N64). In my experience an "over-estimate" that leads to the so called "do it right" syndrome happens if someone else estimates for a developer. When the developer makes the estimate him/herself and doubles it, you can be damn sure they are going to need all that time and then some to even get it in the ballpark of long-term acceptable. (That being said, the company needs to have standards for code acceptability in the first place, which doesn't always happen)
    - Ensorceled 11y ago
      You are saying I'm wrong because good engineering is better that writing crap. Except that's not what I said; I was saying over-engineering is bad and we should stick to engineering.
melted 11y ago
Underpromise and overdeliver — that's the secret to professional success.
- dreamfactory2 11y ago
  and a rookie mistake in sales
  - sixothree 11y ago
    Sales pressure is sometimes the primary reason when our estimates are under.
  - melted 11y ago
    I'd argue that promising what you can't deliver is a mistake in sales, too.
bliti 11y ago
How do you get the right estimates then? Mind sharing your techniques?
- bluesign 11y ago
  I was on the developer side, whose estimates are usually doubled by PMs. (or if we go by the story theme, they always assumed 'primer' may needed on every paint job) Then we had a lot of scheduling problems, and low effiency ( you finish painting the room, but people who will gonna move furniture still not available)

13hours 11y ago

Almost at the end : "Yes, all this sounds like a lot of work". Exactly. And it will most probably still turn out to be wrong, because you will forget to ask some questions, and there will be things that you simply cannot foresee that will influence the time. Turns out it's pointless to even try to do this. So why waste valuable time to do all this, if you know it's not the truth anyway? The answer is to accept that you will learn things as you go along, and that things take as long as they take, and to rather deal with that. Marketing wants a product by Christmas. Fine, we can do that. They just cannot say what needs to be in that product by Christmas. They can have whatever the last production quality release is at that stage. Instead of taking many weeks or months to try and answer all these estimation questions, we start and tackle the high risk items first. We learn from them, readjust, and as we get closer to the deadline, we keep communicating with all the other stakeholders what we think will be delivered on that date. It's a narrowing cone of uncertainty. One sprint before the deadline we'll be pretty accurate in predicting what it will be. 2 or 3 sprints before, accurate enough to be able to do marketing. At the start : the best we can predict is simply whether we feel we can have something useful at the deadline.

soft_dev_person 11y ago
Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...
- 13hours 11y ago
  I used to as well, until I started to refuse to do it. It truly is in the best interest of the customer to work this way, and I explain it to them. The ones that understand it and buy into this way of working are the ones I work with.
  - soft_dev_person 11y ago
    Sounds awesome. Unfortunately I don't work in my own company. Fortunately, I don't work with sales (much).

Theodores 11y ago

The thing that annoys me most about project estimation is when the micro-managing types don't let you even look at the problem space first, an instant answer is expected. Of course the figure plucked out the air could be 'x days' with 'x' being greater than the time one expects internally so backside is covered, yet that is not really a true answer. At the moment I am putting together a 'simple' feature on a website, where I have been able to explore the problem space first. For the $content there actually needs to be half a dozen date fields that were not in the original brief, I doubt I would have discovered this had I not rolled a little bit of code first and explored 'prior art' in the area. I need to put together a semi-working prototype to discover such things - particularly when UX is involved. Yet, far too often, the opportunity to do actual preliminary dev work is denied by those that 'know best', preferring a spec. in a Word document (or something else equally 1990's) instead of a rough working prototype in code (with back-of-envelope sketch). My current feature-being-added will need to be re-factored at some stage, once users have started using it and problems/features overlooked in the original brief catered for. It is not as if the users of my new feature will know that 'actually they wanted it to work this way' until they have something to see. So why we have these silly cast-in-stone processes I do not know. I also must say that I find the metaphor of painting a room is quite a poor one, I would not need to paint 'an alcove first' to get a handle on how long the whole room would take.

Ensorceled 11y ago
Actually, the metaphor is pretty good, except they missed a key change: in real life if the "test painting" shows you need to "prime first" you now have no idea how long it will take without starting the estimation process all over again. So, in real life, paint the room is "2 days or, if the test painting goes badly on day one, I'm not sure and won't know until the end of day 1". And people don't like those kinds of estimates.
- crpatino 11y ago
  If that's the case, you assume priming will be needed in your original estimation, then go do the test anyways, and at the end of day one you will look like a hero when you say "hey guys, I think we can get away with cutting priming from the plan, we just saved $abc from the budget and xyz days".

anon4 11y ago

> The fact that I technically only asked how long the fix would take is something only an engineer would bother pointing out. -_- Well excuse me for not fitting your prejudiced profile for a neurotypical extroverted 20-something white male. Yes, I might have needed the clarification between "how long will it take you to paint the room" vs "how long until the room is back the way it was with the walls in a different colour", but you help noone when you talk down to the painter like that. You asked a question and I misunderstood, because we use slightly different language and I have a ton of other things to think about all the time. Can we stop this "oh let's treat engineers like they're children with mental development issues" already? I'm not some god in an ivory tower, I don't want you to kneel before me, I just want the usual everyday respect you afford to your peers and to engage with me as one professional with another. This kind of treatment is not ok.

Ensorceled 11y ago
Agreed. As an engineer, I can also claim that if I say "we can deliver that March 15th", then I get a argument about why can't it go out with the Feb 28th release and why is it going to take 30 days to do something simple and why ... all because marketing people can't understand delivery cycles. So, let's just not have that type of conversation at all.
- ams6110 11y ago
  Ever talk to a contractor about a home renovation, or even a painter as in this story? If you start questioning why something will take so long, in my experience the usual answer is something like "if you think you know better than me, do it yourself." Especially if they are good at what they do. Most good tradespeople have more work than they can do, and will just walk if they think a customer is going to be a pain in the ass. How often will developers take that approach?
  - crpatino 11y ago
    Well tradespeople usually work for multiple clients on smallish projects. For good tradespeople, a significant number of those projects come from repeat customers, which means their optimal strategy is not to serve all customers equally, but to prioritize those that are more likely to bring repeat business down the road. A difficult customer is usually not someone you want to do repeat business with, so they get "managed out" pretty reliably. Most software engineers, on the other hand, work for one big customer at a time (your employer). And though I agree that a bad employer at the end of day is detrimental to your career, you cannot afford to switch jobs on trivial matters, on risk of getting labeled as a grasshopper. That's why you do not see developers "walking".

kbouck 11y ago

Regardless of project/planning methodology, having a ever-growing checklist of less-obvious estimation items is a simple way to avoid forgetting to consider them. The book "Software Estimation: Demystifying the Black Art" [1] by Steve McConnell contains a number of these. Some examples: - Team or company meetings - Team member sick days, holidays, vacations - Bugs in third party software - Maintenance of previous systems - Maintenance of build automation - Demos - Interviews - ... ... or your own list of whatever other items you have historically forgotten, or tend to forget when estimating. In the painting example, the moving of the furniture was something I overlooked, despite having made the effort to carefully think of all tasks. A estimation checklist built up from previous painting projects could have triggered me to consider this task. [1] http://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351 http://www.amazon.com/Software-Estimation-Demystifying-Devel...

dreamfactory2 11y ago

article assumes specs are known. they might be for some kind of brochureware but for any serious work they never are, and in business reqs change day to day. 60% of software features are never used - so that's 60% overspend right there. there's no reason not to do fixed cost agile (personally wouldn't do it any other way). trying to fix scope otoh is just bad business from the get go - a) you might have target outcomes but you don't know exactly what you're going to need to get there b) useful software tends to be ongoing in terms of reqs

mzahir 11y ago

http://qr.ae/ROlwZp http://qr.ae/ROlwZp - I've found this answer on quora to be one of the best explanations as to why software estimates are so off.

mannykannot 11y ago
Digging down into the details is one of the best responses to absurdly unrealistic schedules.

cateye 11y ago

Analogies like "painting a room" are pretty useless because they are very misleading. Especially when it is an innovative product, a better analogy would be: "painting a room on Mars". With software development, there are a lot more "unknown attributes" that determine the main part of the effort estimation unless it is a repetitive task. So, a critical/skeptical engineer would always drive the customer nuts by asking questions nobody can know and the conclusion will end somewhere like it is not possible to give a upfront estimation and stop the project. Or the effort to give the estimation approaches the effort to develop.

GFischer 11y ago
There are several different categories of software projects, as you say, the innovative ones might fit your definitions, but I'd argue that most don't. The most common kind of software projects I've encountered are very straightforward, mostly just CRUD with an interface + business logic, and reporting, or relatively straightforward websites. Those are the "paint the room" type of projects. There are challenges with those kinds of projects, but they should be reasonably easy to estimate, as long as the team is somewhat familiar with their development tools. Other kinds of projects ARE more difficult because they have unique or innovative elements (probably the case for a lot of startups). Those might be the "paint a room on Mars" kind of projects. As an employee, I've encountered the first kind 90% of the time. As a startup founder, I have encountered a lot more unknowns, but I've still found my project reasonable to estimate.
erikb 11y ago
Before NASA sent their first drone to Mars they made a lot of predictions, a lot of tests, guessed a lot of things that may get wrong, etc. Do some of their missions still fail? Sure. But the amount of success is much much larger because they didn't just sent a drone there and watched what happened. So even if all you say is correct it's still worth improving one's estimation skills.
- lmm 11y ago
  > Before NASA sent their first drone to Mars they made a lot of predictions, a lot of tests, guessed a lot of things that may get wrong, etc. Do some of their missions still fail? Sure. But the amount of success is much much larger because they didn't just sent a drone there and watched what happened. How much effort went into estimating Opportunity's lifetime at 90 days? How useful has that estimate proven to be?

jahaja 11y ago

I may be cynical at this point but overeager project scheduling/estimation processes and top-down software processes in general are really where software development as a creative and experimental occupation dies.

crpatino 11y ago
If you can do "creative software development" and get paid for it, count your blessings. And better yet, give a very big "Thank you!" to your manager. The reality of this trade, regardless of you doing in-house work or a product for the market, is that everything is required for yesterday. There is an "economy of pressure" where every stakeholder pushes everyone else as much as they can in the expectation that they will be pushed as well. If you do not get to experience this, it means someone in your chain of command is very good at pushing others, and that some other part of the overall system is shouldering most of that pressure all by themselves.
- jahaja 11y ago
  So if I understand you correctly you're saying that "creative software development" is inherently incompatible with the hierarchical realities of the corporation? If so, I think you're probably right. "The reality of this trade [..] is that everything is required for yesterday" But it just isn't. This is an artificially created pressure for selfish reasons, and should not just be accepted in passing.
  - bigmanwalter 11y ago
    The game is rigged. Only way to win is not to play.
    - sombremesa 11y ago
      Or according to the parents of this reply, to play under the wing of an expert player.

alistairSH 11y ago

In tech, we spend little time talking about the softer skills like communication, project management, and prioritization. Well, that's not a good start. Maybe my career has been abnormal, but I've spent a lot of time thinking and talking about project management skills, particularly estimation. It's something my employer expects all non-junior employees to do - more than half my team are certified in scrum or have taken courses in other PM methodologies. For most of what we do, the hard part is project management. Sure, the techie code stuff is usually more fun, but that's not even half of my daily workload (and hasn't been since well before my title changed from "product architect" to "project manager").

davidgrenier 11y ago

> These are the skills that elevate someone from a good programmer to a great software engineer I stopped reading at engineer

ddingus 11y ago
You really shouldn't. While the term engineer is loaded with the licensing and professional aspects, and understandably so, the people working with software very often do actually have to perform the task of engineering solutions. Dismissing a valid dialog on this basis does no one any real good. Despite the issue you raise, the query and discussion remain valid and high value.

work-on-828 11y ago

As a new grad who has worked a couple different jobs now, some things I don't get about this: - What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature? - The author says that estimation is easier to do if you are doing something you have done before. What do you do if you are always working with a new framework or language? - How do you break down the steps if you don't know what a project entails until you are finished? - What do you do if asked to estimate how long something will take to debug? What if you just started on a project and the error message you are trying to debug doesn't make sense? My approach there is to try to understand the system I am working with. If the system doesn't have documentation and the existing people on the project don't have time to give a walk through of things, I figure that means source diving. However, I've gotten the feedback that I should avoid trying to "understand the universe" when debugging. What can I do to produce accurate estimates of how long it takes to find a bug in a system without spending the time to gain a mental model of the system? - This excercise takes a lot of time. What do you do when asked for an estimate in a meeting rather than over email? What - What do you do if the thing you are building relies on getting an external API to work and that API is either undocumented or is documented in a foreign language? Assume that the google translation is not making sense and this is your first project and you don't have a budget to hire a professional translator? This sounds like something you would need to get working before you could actually give an estimate. Why do experienced engineers ask for estimates anyway? Every time I give one I feel like I am lying and I try to warn people "I really don't know how to come up with estimates but I am guessing 3 hours". How do I deal with it when they are upset about it taking a week and a half?

fenier 11y ago
It comes down to experience really. The more you are exposed to, if you are paying attention, the easier it becomes to relate to previous events, which can help inform estimates. If you don't have a spec, get a spec. A Senior engineer may be more reluctant to help you with implementation direction without knowing the requirements. Sometimes you need to do research to give an estimate. If someone asks you in person, or over e-mail, and you honestly don't know ask them if you can get back to them. Do not give them a number. Do the research, then reply. If you're relying on external APIs or Frameworks etc. You need to factor in Risk Assessments that include what happens if the fit is wrong, or the interface changes mid project, etc. When it comes to debugging a lot comes into play, system design, documentation, experience with the code. "I don't know" is an acceptable answer until you understand what is going on. Once you understand what is going on, you then estimate the fix based on the code. Giving a number before you understand what you are fixing in detail is a bad plan. I am exceptionally experienced with a certain code base and system. You may be experienced with a different code base. You're more qualified to handle estimation on what you know. That said, if you honestly don't know, say that. Don't low ball the amount of work if you actually have no idea how long it will take. There are a few good books on estimation and debugging, look around maybe they'll give you a few ideas.

a3n 11y ago

As long as sales, or its local equivalent, commits to as yet non-existing products and features, it will ever be thus.

deleted 11y ago

[deleted]

beat 11y ago

The tendency to estimate poorly - particularly to underestimate - is one of the key reasons to use a very tight, short-iteration agile process. If I estimate something will take two days, and I'm off by 50%, it'll take three days. If I estimate it'll take two years, and I'm off by 50%, it'll take three years. And because I can get a lot more practice at two day schedules than two year schedules, I'll improve my accuracy over time, through steady practice. This takes us back to the triangle of constraints that Kent Beck talked about in the first Extreme Programming book. There are three constraints on projects - schedule, scope, and resources. You can control two of them. Generally, resources are inflexible. So in practice, projects are either schedule-bound (we must hit this date) or scope-bound (we must have these features). A project that tries to do both, without a significant resource surplus, is probably doomed. Since estimation improves over time with short iterations, it seems better to me to be scope-constrained than schedule-constrained. With steady progress, you can achieve the goals eventually. Good agile processes are much better at saying where you are and where you're going than when you'll get there.

p4wnc6 11y ago
I've never experienced estimation improving over time in an Agile process. In fact, since short estimation cycles are just as susceptible to political games as longer cycles, and this dominates the whole process in any organization, the length of the estimation cycle really has nothing to do with the estimation issue. But, what shorter estimation cycles are responsible for is a decoupling of the overall big picture progress from the immediate tasks being prioritized. This often leads to sprints that are well scoped, and everything in the sprint gets completed close to on time (at least as close as in longer work cycles, but not usually any closer), but, crucially all of the work has to be scrapped because the whole sprint, conceptually, was not right. In my experience, this happens maybe 1/5 of the time in Agile exactly in ways that would be prevented with longer-term planning. It's very similar to the classical fractal effects of measuring the coast of Britain. By refining your ruler, you merely think you're being more accurate, and a lot of people are doing a lot of performative managerial crap for the sake of the Scrum performance, like a ritual. It feels like you are estimating better, but really because the whole meta-level concept you are working on isn't guided by longer-term thinking, you end up having so much round off error, added up over more and more cycles, that the overall waste is colossally greater than systems that involve some more significant longer-term pre-planning and which work on variable cycle lengths instead of a cookie-cutter, one-size-fits-all approach (which is the core philosophy of Agile, though people try to obfuscate this fact by No True Scotsman-ing it with the Agile Principles). I also can't miss the opportunity to point out this great article on the political games we play during estimation: < http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC322/F09/files/EstimatingGames.pdf http://research.cs.queensu.ca/home/ahmed/home/teaching/CISC3... >

Gratsby 11y ago

I'm about to being a rant here because this is a larger problem than anybody likes to admit. Developers are good at development. By and large, they are not good at task management, project management, and certainly not estimation. One of the primary reasons for this is that their plates are always overflowing and they work more efficiently than many people in other professions. They shift priorities on the fly when work in one area cannot be progressed. Development time is social currency. You can make your boss happy by progressing his priority, or you can make someone else happy by progressing their priorities. Not many developers truly answer to a singular master. And few allocate time for learning although we all spend a significant amount of time doing it - how else do we maintain relevant skill sets? Can a developer really estimate a project and tell his manager that 3 weeks in the timeline are for 2 unknown and unforeseen problems that require interaction with vendor support? No, because the manager will fight back and say that those 3 weeks are really just zipping up logs and making three phone calls and "if it takes anything more than that, hand it over to me!" Most can't tell their manager that it will take 2 weeks to parse a CSV because the source data is shit and they have too many other things they are working on. So they stay an extra 6 hours in the office and get called a rock-star until the day that they opt to go to their child's school play instead. The solution to this problem is simple. Take task management and project estimation out of the hands of developers. It's time for the return of the secretary to the workplace. A single $50-80k administrative assistant could easily support, manage the priorities of, and improve the outward facing communication for five developers. With experience doing so, that admin could provide better time estimates for all of them and would be better at negotiating realistic timelines than any of them individually. People have been coming up with methodologies and software to solve this problem for decades. Developers don't have brains built for project management. Yes, they can do it, but they don't get paid to work in MS Project. They get paid because they know the difference between a bubble sort and a quick sort and when to use either. Conversely, I don't know a soccer mom who doesn't successfully manage a more challenging schedule and competing set of priorities better than every nose-down developer I've ever met. Give appropriate work to appropriate people. Developers have their talents. Scheduling, estimating, and task management are not among them.

orky56 11y ago
Ideally a product manager solves or assists with many of those problems- 1. Reduce the ambiguity of what features to work on and what are the priorities. This involves being the barrier from other manager and team members trying to pull a fast on and changing what should be worked on. 2. Stay on top of what the latest estimates are in an honest and transparent way. Product managers as project managers should be able to translate what a particular developer says into what estimation might be in reality. They can acquire or release resources, or even change scope accordingly or at least make the case. 3. Product managers should provide developers a constant opportunity to break down tasks into components that can be tracked easily in Asana or another task management tool. This takes discipline as a product manager to enforce a system onto developers in ways that make sense. Disclaimer: Product manager here.

orky56 11y ago

One of the fundamental issues is that upper management sees estimates as bell curves as though 50% of the time a project may finish early. In reality, very few projects on time, let alone early. No one wants to hear about reducing scope but at the same time an MVP that solves the customer problem without feature creep should be evangelized within organizations. In reality, schedule follow more of an exponential function where slippage time goes from bad to worse very quickly as resources/scope/schedule snowball very quickly. Things get scrapped before we see this in practice.

gjkood 11y ago

A pet peeve of mine: Scenario: Finished requirements, analysis, design; completed development and testing; in UAT; Production deployment: 1 week away. Customer: Hey this field name does not exactly represent what we want to convey. Can we change its name quickly before we go live? Eager Novice (who is unfortunately in front of the customer at that moment): Oh yeah, that's just a small change in the Customer model. I think we an get this ready and unit tested in 2 hours. Customer: Great. Lets git er done! Project Manager (wary of customer and afraid to rock the boat on an already shaky project): Sure we can do that. Grizzled Veteran/Grey Beard (who for some reason wasn't consulted on the change request): Hmmm....have we done an impact analysis of the change? What are the downstream impacts on code that references this field? What do we need to do to propagate the change to the db? What about the seven or so Web Services that are impacted by this field change? How long does it take to do a regression test? etc... Net effect: 2 Hrs initial estimate given to customer; 4 Days worth of work in actuality; Production deployment moved down a week..

edc117 11y ago
Agree 100%. Golden rule: Never give off the cuff estimates (even if you're sure).

mikeskim 11y ago

You could just use data, machine learning and optimal control to make better estimates. It has aleady worked for fighter jets, self driving cars, and automated factories. With enough data it will work for anything.

chillacy 11y ago
What kind of features would we use? Which prior projects will help predict how long it takes a team of 3 developers (one of them senior with a history of underestimating time, two junior with little track history) to produce a novel photo sharing app where the requirements might or might not change every day? The problem I see is that there isn't enough data, and the problem space (the number of possible projects and teams) is too large to draw meaningfully on past data. Unless we're looking to predict specific CRUD apps where the requirements are known up front and a team cranks these out consistently. Humans have already been flying fighter jets, driving cars, and doing work in factories, so we know it's a learnable skill. We have not yet learned how to estimate arbitrary software production.

geebee 11y ago

Estimates are a tricky thing. Ultimately, I don't think they work in software. We should be looking for a different solution. Think of it this way - a physician can prescribe a medication and tell you how long you'll be on it, but can she estimate how long it will take before your blood pressure falls within normal parameters? She can tell you what has happened in the past, but suppose you take the medication and your blood pressure remains stubbornly high. Has she failed to meet her targets? A lawyer may be able to tell you, roughly, how long litigation tends to take, but can your lawyer estimate how long a case will take, what it will cost, what the outcome will be, and the date it will all be wrapped up? If that doesn't happen, did the lawyer fail to meet targets? Well, in both cases, sort of, yeah. You didn't get the outcome you wanted. But these professions, run by the people who staff them, understand what can be predicted and what can't. This blog entry uses the task of estimating painting a room as an example, and focuses on breaking the task into subsections. Ultimately, I think the entire approach is deeply flawed, and it all starts by thinking that software development is similar to something like painting a room, just a more complicated version of it. In my opinion, it's very different. Of course, it's very different from prescribing medication or litigating as well - in fact, I'd say that it's generally considerably less predictable than even these things. I'd say it's closer to writing a novel, creating a film, or recording an album, except that software needs to work, and can be much more mundane at times as well. Ultimately, I don't think the analogies are useful, we need to realize that software is its own thing, and steer clear of too much reasoning by analogy or example. Unfortunately, the anxiety caused by making estimates under conditions of uncertainty (and possibly duress) is a source of stress and unhappiness for developers, and I do think it's one of the things that drives people out of the field. I actually think this may also be one of the reasons people love creating apps as a hobby but hate doing it for money.