I'm Sure It Will Only Take You A Few Days To Code

I actually think that the same principles apply to _any_ form of creative activity.

Let's say I'm going to write a 300 page book. I can take my typical wpm speed, do some math on it, and say that it will take me X hours to do this. A book, on the surface, should fit into the "size and speed" heuristic. But of course, this is nowhere near the case. No decent piece of writing ever comes out without many many iterations of rewrites.

Writing a piece of music? Same thing. Making a clay pot? Even great masters take many tries before coming up with something worthy of the public eye.

Software, even to my novice eye, is similar. But the difference is that the person with zero experience doesn't know instinctively that software also falls into this iterative, creative process. We've been trained and educated to know that writing, composing, and sculpting are iterative creative processes that don't have a linear measurement scheme. We spent hours upon hours as children and young adults writing and rewriting, drawing and redrawing. We know from personal experience that things hardly go "as planned".

But for something completely foreign to us, such prior knowledge is absent. We have no idea. So we take what we can see, and extrapolate. "Hey, I see just one web page, that can't be so hard... (insert mysterious thought process) how about XYZ days?"

The fact that I took a few years of programming courses in college (I was an EE Major) has probably helped me in keeping things sane. I've written enough code myself to know instinctively that both development and debugging are far from linear processes. I know that I have no way of estimating how much time it will take devs who are much more capable than I am to develop/fix something. So I cede to the guys who know best. I take their word and estimates in good faith, and focus on swatting the 'flies' away so the team can focus on the task. What if we don't hit our estimates? Well too bad, but stuff happens. Time to reassess, buckle down, and go again.

If you're learning a song, the first stage is very quick. You think about the problem for a moment and you decide on a plan like "Read the sheet music and try to play the song. Focus on areas you have trouble with. Repeat". The bulk of the time taken is spent "actually doing it", not "figuring out what to do".

The thing about the "figuring out what to do" stage is that often in order to estimate the time needed for that stage, you basically have to have already completed it. The answer could come to you out of the blue, it could take weeks of thinking into dead ends. And with software, that first stage can be the bulk of the time. Software is a more like writing a novel than learning a song. The thing that takes longest isn't the actual writing, it's the figuring out what to write. If someone asked you how long it would take you to write a novel that gives insight into the human condition by following the story of a family caught up in a bloody civil war, what time estimate would you give them? I expect your typing WPM wouldn't be a big part of the calculation.

You only know how long it's going to take once you know how you're going to do it, and once you know how you're going to do it, you've already done most of the hard work.

(I'm probably aided by the fact that many of my good friends are coders, so even if I myself am not capable of writing such great pieces of code, I am constantly developing the crucial context and understanding for the creation process, and what kind of people/work goes into building something great)

Also, I have another suspicion, which is that the majority of work that's performed by the people who make such requests are in fact, linear. What kind of work do the ground level sales/marketing/pm types do on a daily basis? Whether it be crunching numbers or writing documents, making phone calls or preparing for meetings, most tasks are measurable and predictable. During my poker playing days, I remember the enlightening phrase, "We expect the other player to act the way we do when placed in a given situation (ie against certain bet patterns/boards)." Similarly, if our daily work is linear and calculable, then it is in our nature to expect the other kinds of work which we cannot completely grasp to be linear and calculable as well.

2. A better analogy for writing would then be a poem, perhaps even a Haiku (which only contains 5+7+5 = 17 syllables). Writing 17 syllables is something we can do in under 30 seconds; writing a masterful work of poetry is something that could take years. (but I completely agree with what you're saying :))

In many ways, it's generally the consumer or purchaser or something that undervalues it. You have two camps of people, those who commission a work out of reverence to the medium, or to its author/artist, and those who simply trade in the resultant good.

A song might seem like something an artist painstakingly crafts over the course of their life to someone in the first camp, or as something that can be banged out in an afternoon to someone in the second, like an ad exec, or a pitch man.

As developers, we often deal with our own consumers in the form of project managers or product owners who expect a ship date, and need for the result to be fast, but we aren't exposed to consumers of other art because we (generally speaking) aren't artists who trade in that business.