Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

danshipper.com

Post reply on HN
Print view View original

21–30 of 117 posts

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

#21

Post by wildmXranat »

Let's take it a step further, shall we. Say you get this type of request thrown at you, which is obviously a mis-estimate and you don't end up delivering it with expected pace. You weren't supposed to, by the way. It was a trap. Now, the PM or whoever says this "Well, Joe, what if we punt it to Bob over there and see if we can get you concentrated on another problem X". Does that precipitate your balls into shrinking or what?

Estimates are just that, estimates and not contracts. We should expect them to have a float time, otherwise rename them to contracts. I do X in Y amount of time if Z is true. Usually, there are unknown variables and I'm running out of letters to name them all.

Furthermore, I don't work on a deserted island. I have a phone, QA keeps on asking me questions, clients want clarifications and my version control is burning up from constant merging, and yes I have included all that in the time estimate.

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

#22

Post by jarrettcoggin »

dshipper wrote: post #15
hkmurakami wrote: post #12

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 ev…

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!…

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.

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

#23

Post by ams6110 »

As a programmer I know I can use my prior experience building similar things to estimate how long each feature will take to implement.

Here's where this breaks down for me: it's never similar. Sure, the functionality from the user perspective might be similar, but with the pace of change in development tools, platforms, and frameworks, it's never the same. Seems that every project involves some major piece of kit that I've never used before. In the last five years I've used ASP, ASP.NET, C#, PHP, Lua, Python, Erlang, Oracle and PL/SQL, MySQL, PostgreSQL, SQL Server and TSQL, OpenLDAP, XML, XSLT, JSON, javascript, jQuery, Scriptaculous, and other things built out of those, and probably a dozen others I'm forgetting at the moment.

Yeah at some level databases are all basically the same and languages are all basically the same but at another level they are not and that's where the time sinks are.

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

#25

Post by ams6110 »

jgamman wrote: post #13

so reverse the question - "why does programming small things take so long?" (assuming x, y and z were relatively standard). is there a niche in this somewhere that maybe some % of the guru class should be focusing on 'making typical, trivial'? ie, we found 70% of websites include these features - download this template, push run and you have a website running. change text on front page manually might actually be good…

You're describing Squarespace and a dozens of other offering like it, as well as any CMS.

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

#26

Post by bigiain »

joe_the_user wrote: post #9
zeteo wrote: post #6

Funny to see this on the same front page as http://news.ycombinator.com/item?id=3795064 . "[Jobs] pushed Steve Wozniak to create a game called Breakout. Woz said it would take months, but Jobs stared at him and insisted he could do it in four days. Woz knew that was impossible, but he ended up doing it."

Yeah and Linus coded git in a weekend... The infuriating thing for me is that people don't get that these monumentally fast development achievements still involved a massive expenditure of personal effort. Thus the "It'll take a few days of coding" customers of the gp are only more annoying if they cite examples like yours, expecting a complete product in a few days.

Not only that, but they require all the skill and experience of truly world-class experts in their fields.

Yes, Linus can throw together an amazing dvcs that scratches his particular current itch in a weekend. The just-graduated CS major you're pitching your idea to? The one with three whole php and/or ruby websites under his belt? He'll be able to do that too - after spending 20 years running the worlds most popular open source project and knowing exactly what he needs his version control system to do. Give him a weekend to do it right now? You'll get _something_, but it sure as hell wont be git.

Same with Woz - there was probably nobody else on the planet who could have written breakout for the AppleII in under a month. I don't know whether Jobs was brilliant enough to know what he was asking was possible for Woz, even when Woz told him it wasn't, or whether Jobs just strongarmed Woz with unrealistic expectations and took credit for the success (and laid blame for any failure); but if he'd asked anybody else, they would have failed.

Whatever your idea is, chances are _very_ high that if you think it could be coded "in a few days", you don't actually understand the problem (and it's solution) yourself.

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

#27

Post by 6ren »

Reminds me of "open textured" in legal philosophy: the idea of precedent in law is you can use it to predict how a court will decide in future. This mostly works, but if you have a bunch of cases (data points in multidimensional space), simple interpolation isn't always accurate. You need to look at the specifics of the present case (there's still uncertainty because each judge has an individual perspective, but that's a different issue). It's a little bit like a fractal: just knowing some data points won't always predict - even roughly - what happens in between (but in flatter regions, it can). And Turing showed that (in general), you can't predict the result of a computation except by actually doing it.

The experience the article mentions only helps when a specific domain reoccurs, and known tools have been developed for it, with known characteristics. Now, if you know that domain and the tools, you can do prediction pretty well. I think of it like an experienced tradesman.

However, when you go into a new area (and a new one is created every decade or so in programming), you're back to zero in many respects. e.g. the existence of the right library can save 10,000 hours.

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

#28

Post by bigiain »

hkmurakami wrote: post #18
dshipper wrote: post #15

Earlier quoted context omitted.

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!…

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 ai…

“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)

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

#29

Post by SkyMarshal »

edw519 wrote: post #19

The Lifecycle of a Project Manager: Phase I: (Idealism) Treat building software like building a bridge. Analysis --> Design --> Development --> Testing --> Implementation. Phase II: (Pragmatism) Realize that Phase I doesn't work. Try to figure out why. Decide that the weak link is Analysis, i.e. we're no good at estimating and hitting deadlines because we never have good enough specs. Devote your life to the art and…

Nice. You should make that a blog post so we can send the link to all newbie PMs we encounter.

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

#30

Post by mkramlich »

non-programmers, in my experience, tend to think software is "just that stuff you see on the screen". So if they create some screen mockups of the UI, they think the programmer pretty much needs to sit down at the computer, and do some simple keyboard/mouse clicky-clicky to make the screen match his mockups. and then they're done. To them, it's just visual, and static. They don't understand there are processes, threads, hardware contraints (cpu, memory, disk, network bandwith), libraries, languages, configuration, edge cases, error conditions, etc. I've seen this kind of perspective a lot with non-technical stakeholders, especially first-time clients of software contractors, or first-time managers of software developers.

"Just make it match these mockups!"

Dragging a little Facebook icon into place and poof all the code and edge case handling and database work needed to integrate with Facebook is all done, put to bed, etc. Just put that icon in the right place.

Post reply on HN