11

I am convinced that the amount of routine work in software development is - and should be - relatively small, if not negligible, and that this is the fundamental problem of software estimation.

Let me describe how I come to this conclusion and tell me if the argumentation has any serious flaws:

  1. All that can be estimated with high accuracy is routine work, meaning things that have been done before. All other kinds of work involving research and creativity cannot really be estimated, at least not with an accuracy of, let's say, +/- 20 percent.

  2. Software development is all about avoiding repetitive tasks. One of its basic principles is DRY (don't repeat yourself). Whenever a programmer finds himself doing repetitive stuff, it's time to find an abstraction that avoids this repetition. These abstractions can be simple things like extracting the repeated code into a function or putting it in a loop. They can also be more complex like creating a domain specific language. In any case, implementing them will involve research (has anyone done this before?) or creativity.

From these two points I draw the above conclusion.

Actually I have been wondering for quite a while why this relationship is not mentioned in every other discussion, blog post or article about software estimation. Is it too theoretical? Are my assumptions wrong? Or is it too trivial - but then, why do most developers I know believe that they can do estimates with an accuracy of +/- 20 percent or better?

Improve this question
9
  • 7
    99% of all software development outside areas like kernels have been done thousands of times before. Far too many developers just want to do everything in a new fancy way, reinventing the same old problems over and over.
    – Bent
    Commented Aug 14, 2016 at 11:01
  • @Bent: So you are saying that software development is mostly copy-and-paste? I know that many developers work that way and often found that it leads to unmaintainable code. But that's a different story. Even if someone works that way, he has to figure out what to copy and from where. This is something I would also consider as research work.
    – Frank Puffer
    Commented Aug 14, 2016 at 14:59
  • 1
    @rwong: Of course it makes sense to use libraries. But finding the right function in a library and the right way to use it is either research work (if the lib is complaex and/or you don't know it well) or trivial (if you aready know that function). What you call 'glue code' is in my experience often complex. Implementing it is not neccessary routine work.
    – Frank Puffer
    Commented Aug 14, 2016 at 19:32
  • 1
    @JohnR.Strohm: I did not read these specific books but am familiar with the basics of COCOMO - have never used it in practice, however. Also I have read two or three other books by DeMarco. Could you give a hint on what specific content is related to my question?
    – Frank Puffer
    Commented Aug 14, 2016 at 19:35
  • 2
    @FrankPuffer, Boehm's "Software Engineering Economics" is required reading for software estimation. Demarco's book is not far behind. The SHORT answer is this: If you are familiar enough with what the software must do to estimate it AT ALL, you are familiar enough to consider it relatively routine.
    – John R. Strohm
    Commented Aug 14, 2016 at 19:49

2 Answers 2

Reset to default
11

On any single given project this may be true. However if you work on multiple, similar projects for different companies over the years you may find yourself 'solving' basically the same problem many times with only slight variations.

For example I've written data access layers so many times I now prefer to do it 'long hand' rather than use the popular ORM of the month. It's quicker and easier for me to deal with the 'routine problems' with known solutions than find and solve new quirks in 3rd party components.

Obviously I could write my own ORM to simplify the repetitive code without added the unknown quirks in someone else's system, but this code would belong to the company I happened to be working for at the time, and other developers would find it just as quirky as any other 3rd party ORM.

Similarly, in my experience, most programming is the automation of business processes and although each business likes to think that their processes are unique to them; In reality they are not.

Not to say that estimation is easy! It is easier, but I find that these days the estimation problem is due to the inadequacy of requirements rather than the time spent coding.

Requirements tend to fall into three categories:

  1. Vague, details left to developer.

"Make me a website, it has to be cool and sell my widgets"

These tend to be the easiest to estimate, as when a hard unexpected problem occurs you can simply change the requirements to something functionally equivalent and avoid the problem.

  1. Very Specific

"Make the header background colour #ff1100"

Super quick to do and, again, easy to estimate. But! the requirement is bound to change. "Hmm no on second thoughts, try this other red" or "Wait! I meant only on that one page!" so the real time span of "how long until I am happy with the header colour" has nothing to do with the coding estimates

  1. Vague, details assumed

"Make me a website, (just like facebook)"

Here the multitude of unstated assumptions, "of course you will want a different logo", "it should have infinite scrolling", "must be scalable to 1 billion users!" effectively control the estimate. Either the dev thinks of everything and pushes the estimate up beyond expectations "1 meeelion man hours", or they think of/assume only the base features are required and give a too low estimation. "oh a week or two, I assume you just want to put facebook in an iframe right?"

With experience coding is very fast, but designing requirements is (usually) the hard bit, and this is more and more pushed back on to non-coders. With agile methodologies increasing coding velocity by moving this responsibility to 'the business' rather than developers.

Improve this answer
6
  • I absolutely agree with what you have written about inadequate requirements, but that's a different story. In the first part of your answer you say that you often keep using well-known techniques so that a greater part of your work becomes routine. You deliberately do without additional abstractions. This probably works well for a short period of time, maybe 2-5 years, depending on the technologies you are using. But then you might notice that you haven't improved your process as much as some of your competitors. Also, other developers that will maintain your code later might have an issue.
    – Frank Puffer
    Commented Aug 15, 2016 at 10:25
  • Obviously its not like I never use 3rd party stuff. The point is if you know how to do something already with tool X the estimation is easy
    – Ewan
    Commented Aug 15, 2016 at 14:52
  • Not only the estimation but also the implementation becomes easy in this case. If your whole project is like this, you're lucky. But in my experince this only happens in small projects. All larger (>10 days) projects I was involved in required some new concepts or technologies and that's what caused most of the work, rendering the effort for the standard stuff negligible.
    – Frank Puffer
    Commented Aug 15, 2016 at 15:41
  • Lets not get into a 'whos the best programmer' flame war. All im saying is the more stuff you've done before the less new stuff there is. If all your projects mandate the use of new tech for most of the features though... That seems odd
    – Ewan
    Commented Aug 16, 2016 at 12:21
  • @Ewan "concepts or technologies". For me the first one tends to relate to the business rules and/or what the designer wants. It's not just about new technologies.
    – Izkata
    Commented Aug 16, 2016 at 19:55
6

why do most developers I know believe that they can do estimates with an accuracy of +/- 20 percent or better?

Because we estimate our patience with the problem far more than the actual problem.

If I'm going to animate a ball bouncing I could spend a day, a week, a month, or a year on it and still just have an animation of a bouncing ball. Hopefully it will look better the more time I spend on it but at a certain point I'm being ridiculous.

How much effort I put into making the ball bounce is a function of the time that is reasonable to spend on it. If my skill level isn't cutting it I may end up with a ball that just sits there. But when the deadline comes should I let the deadline slip or at least get a ball on the screen? Waterfall insisted the ball bounce and so the schedule slipped. Agile says just get the ball out there. At least we'll find out how much people care about bouncing. So the quality slipped.

I try to be sure my balls bounce but when the deadline comes around it's better to produce a static ball than nothing at all. So I estimate time based on what seems a reasonable amount of time to spend on a problem before talking about alternatives. Sometimes the ball just isn't going to bounce. Sometimes that's OK. Disappearing for a month is not OK.

Improve this answer
2
  • Good point, so basically you are saying that the estimate should be based on what value a certain feature has for the customer (or product owner). Personally I like this approach but in my experience this is not how software estimation is generally understood, even in an agile setting. One drawback is that often you don't have this information about the customer value of a feature. Another drawback is that it cannot handle work packages that don't directly result in a feature visible to the customer.
    – Frank Puffer
    Commented Aug 14, 2016 at 18:12
  • @FrankPuffer I disagree that agile methods don't make this clear. SCRUM in particular doesn't even ask developers to estimate until the feature's value is so high that it is actually scheduled to be done, I.e, just in time estimation. Agile methods are particularly suited to this: first identify the features with the highest business value, then estimate them, then DO THEM, and see how long it actually took. Lather rinse repeat. After a few cycles of this you will have a very good idea of the estimate vs actual dev time.
    – RibaldEddie
    Commented Aug 14, 2016 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.