Comment by hkmurakami | Hacker News Reader

Comment by hkmurakami | Hacker News Reader

Parent Full thread

Disclosure: I am currently a software PM

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.

I agree completely but I think there are two things that make software slightly unique from any piece of art:

1. We have a cultural context that tells us how hard it is to produce something like a song, or a painting. There's a reverence for it. And so people tend to back off of their estimations for the amount of time required to produce it.

2. Software isn't physical. You can hold a big book in your hand say CRAP! that must have taken a long time to do. But you're just looking at the result of a program, if it's done well, it's a tiny streamlined user interface. The result of one button click could have taken thousands of programming hours and thousands of lines of code but you would never know it. Software obfuscates complexity from the user in a way that someone looking at a huge huge painting or a big book doesn't run in to as much.

So if we're talking about the efficiency of natural heuristics in estimating things, I think software is still slightly more difficult to estimate than art. But I agree with your overall point.

1. Definitely agree. But within hacker circles, I am sure there would be similar reverence for a beautifully written algorithm. So I'd venture to say that the issue isn't something that's inherent to software, but rather relative to our cultural/societal upbringing and education. There's the possibility that software may be understood by the larger population in the (hopefully not so) distant future.

(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 :))

“Perfection is achieved perfection not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery

Seems presciently apt, considering he died before "programming" as such existed. (1944)

And one of the things that throws some software estimates out the window is when a developer/programmer gets in the zone. There have been times I've hammered out a problem that I had spent days on in a few hours when the inspiration/flow/etc. hit. Something I would have guessed would have taken me a few days more, I end up hammering out in 3 hours. And when you pull these kinds of tricks...

People think you can do it again... and again... and again as if it was something you could just conjure out of thin air. There are many papers written on this topic. I've been playing around with a few ways to achieve this more frequently, and it has worked to some degree, but it's not something I could rely on in the heat of battle.

Easy way out - if you estimated 3 days and it turns out to be 3 hours ... simply sit on it for 2 more days ;-)

But would the problem have taken only a few hours if you hadn't spent those days on it?

We should always deliver a physical copy, on paper, of everything written during a project together with the invoice. Every whiteboard brainstorm, every source code diff and every email sent and received. Should make a decent stack of paper to give the customer a sense of perspective!

Like this?

http://craigmod.com/journal/digital_physical/

(was on daringfireball the other day)

Regarding point 1, there are people who trade in songs and music, and I can assure you they have less reverence for music than the average person.

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.

This reminds me on what Zed Shaw said in The ACL is Dead, when he compared programming to publishing magazines. Lots of people collaborating in creative tasks aiming for a deadline.

How does magazines manage to work deadline driven and still be able to produce good creative work?

Reply on news.ycombinator.com