Developers, in general, on average, chronically underestimate the time it takes to properly execute an idea and how many iterations and discovery of the exact needs of customers that requires.
I work at a company that sells a tool for model based testing and invariably, at every customer company, there are developers that think our tool isn't worth the money, because when we explain to them how it works and they think 'I could build that'. Yes, of course they could, just like they could also build a Reddit clone in a weekend. They just don't realize (and is hard to convince otherwise), just how much work it is and how much real world experience is necessary to make it actually useful. As the article says: developers are very hard customers and fortunately (for us, but not for the industry in general) the decision makers often distrust/discount the technical opinion developers have of tools they intend to purchase.
Tl;dr: developers too often say 'I can build that', when really, for practical purposes, they can't.
Humans are notoriously optimistic, and in particular, we forget about all the things we have to do in order to achieve the things we want to do. (I have been reading some research on this lately).
I used to harbour the "build it in a weekend" suspicion about everything, and then I started building things. The world is a damn mess, is what it is.
I've been working on a tool for making PERT estimates easier and, consequently, done a bunch of reading about PERT, wherein lots of the work is of a statistical or mathematical nature. But I also ducked across to the psychological research to get a feel for the human factors. Psychologists consider estimation problems under the heading of "the planning fallacy". I intended to write a series of articles for SEO purposes but so far I only have two fairly light-weight ones done[0].
Most PERT method research is out of the Operations Research community. There's some interesting stuff there about how estimates can be wrong. For example, if you accept that there's a range of probabilities on every node in a PERT graph, then managing the "critical path" by itself is very risky. There's a whole bunch of what you might call subcritical paths lurking, and one step in risk management is to find the parts of your project where they might be lurking[1].
Another thing that pops up. In the classic PERT formula, the divisor is 6. Why 6? It turns out that nobody is quite sure, but it roughly assumes that events follow a double-triangular distribution[2]. This is a heroic assumption, to say the least, but how do you best account for it? In my prototype code I've made the distribution configurable with the idea that advanced customers could change it; or perhaps some regression across all customer data could provide a better fit.
But then comes a bit of a bombshell from the psychologists, who operate in a carefree world, innocent of project management problems. They've found that decomposing a task improves estimation performance. It's called the "unpacking effect".
In a series of experiments Kruger & Evans established that you can improve estimation performance on a main task simply by asking people to list the subtasks required to achieve it. How long will it take to get ready for a date? If you ask this question by itself, the answer will be wrong. If you first ask "What do you need to do to prepare for a date?" and then ask how long, the answer is still wrong, but it is less wrong. Read their paper, it's absolutely fascinating [3].
To me this raises the fascinating possibility that the improved performance of PERT estimates over expert judgement derives mostly or wholly from the enumeration of subtasks rather than the statistical stuff that comes along for the ride.
[0] http://confidest.com/ (I know it looks very ordinary, my CSS chops are very ordinary).
[1] Richard J. Schonberger, "Why Projects Are 'Always' Late: A Rationale Based on Manual Simulation of a PERT/CPM Network", Journal of the Operational Research Society
[2] T. M. Williams, "What Are PERT Estimates?", Journal of the Operational Research Society
[3] Justing Kruger and Matt Evens, "If you don't want to be late, enumerate: Unpacking reduces the planning fallacy", Journal of Experimental Social Psychology.
I think this also extends into developers that want to be founders. I think they have a hard time selling things because they always built instead of bought and feel lots of things should be free. They also think particular details matter when they really don't, and these things hold them back from selling.
As a developer founder, getting over this has been one of the most challenging but important steps in making my business grow and thrive. I'm still not 100% there yet.
The Planning Fallacy. It is really hard to convince yourself to be pessimistic. Most people who think they are planning pessimistically are not and are underestimating the amount of time it takes for them to do something.
>I work at a company that sells a tool for model based testing and invariably, at every customer company, there are developers that think our tool isn't worth the money, because when we explain to them how it works and they think 'I could build that'.
Neat, what is the company? I was glancing at some papers on model based testing recently and had no idea there were commercial tools for it.
In defense of that mindset creating something for personal use often involves 5% or less of the effort it takes to bring something to market. Or as an EE friend once said about his home built hot-tub if X went wrong then scolding hot water would shoot out of the pipes but it's not something I am worried about because I would freak out and pull the plug if Y or Z started to happen. Which transforms a huge fundamental flaw in the design to something that's not that important.
I work at a company that sells a tool for model based testing and invariably, at every customer company, there are developers that think our tool isn't worth the money, because when we explain to them how it works and they think 'I could build that'. Yes, of course they could, just like they could also build a Reddit clone in a weekend. They just don't realize (and is hard to convince otherwise), just how much work it is and how much real world experience is necessary to make it actually useful. As the article says: developers are very hard customers and fortunately (for us, but not for the industry in general) the decision makers often distrust/discount the technical opinion developers have of tools they intend to purchase.
Tl;dr: developers too often say 'I can build that', when really, for practical purposes, they can't.