Live data from Hacker News

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

danshipper.com

71–80 of 117 posts

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

#71

I think a lot of clients offer estimates based on how much money they have to spend regardless of the complexity.

No shit. It's always like this. They have a wish list and a budget. These two things hardly ever match.

It's hard to give a quote when there are no detailed specs yet. Most clients still want a price tag. Of course afterwards they'll nail you on this premature conjecture.

As a business your quote needs to be competitive and still be profitable.

From experience, we usually throw things out and create boundaries in our offers / quotes. We've learnt the hard way that often times clients implicitly assume certain features to be there without ever communicating them to us, so you need to think ahead and have it in black and white that if they want X they have to get another offer / quote at later stage.

So imo it's not just about what work a quote includes, but also what work it does not include.

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

#72
post #43

P = programmer; NP = non-programmer NP: How long will it take? P: It'll take as long as it takes. NP: I don't understand. What does that mean? P: When you tell me that the product is finished, it's done. NP: You mean you can't estimate how long it'll take? P: I can't estimate when you'll decide that it is done, therefore an accurate prediction is impossible. From experience I know that a project like this can take fr…

What are the implications on the universe if P=NP?

[deleted]

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

#73

P = programmer; NP = non-programmer NP: How long will it take? P: It'll take as long as it takes. NP: I don't understand. What does that mean? P: When you tell me that the product is finished, it's done. NP: You mean you can't estimate how long it'll take? P: I can't estimate when you'll decide that it is done, therefore an accurate prediction is impossible. From experience I know that a project like this can take fr…

This takes a fairly narrow view of a development process, IMO. The "but you didn't specifically tell me to do X" attitude can border on the irresponsible and/or lazy. It's all nice and well to expect accurate step-by instructions to be communicated by a PM, but the onus also does fall on developers to meet them half-way.

While machines may require explicit and literal step-by instructions, a human being value-add is in thinking rationally, making inferences and (when necessary) asking questions.

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

#74

P = programmer; NP = non-programmer NP: How long will it take? P: It'll take as long as it takes. NP: I don't understand. What does that mean? P: When you tell me that the product is finished, it's done. NP: You mean you can't estimate how long it'll take? P: I can't estimate when you'll decide that it is done, therefore an accurate prediction is impossible. From experience I know that a project like this can take fr…

P: Rest assured that I will not be the one slowing this down.

It would be hard to trust a programmer who was so comprehensively trying to avoid taking any responsibility for anything.

Of course many factors will affect the overall time and money required to complete a project. Any decent manager knows this. But a programmer who can't even estimate a project given a reasonable set of assumptions is just trying to cover his ass. IME, he almost certainly will also be the guy who will slow things down, because being completely unaccountable for his performance he has no incentive not to.

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

#76
post #60
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…

I once interviewed a project manager.. asked how he came up with deadlines. He said "ask the programmers and subtract 20%". Talk about a red flag in an interview!

Brilliant. So much for 'just take whatever I tell you and multiply it by three'.

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

#77
"But it brings up another more interesting question: why does the way we naturally measure complexity stop working when we apply it to programming?"

Ah and I had high hopes for that next paragraph,

There are two fundamental differences between, lets say, estimating how long it will take to make a sandwich, and estimating how long it will take to create an online noticeboard for your village.

The first difference is that one task is manufacture, the second task is design. Writing code IS design, and it is inherently much harder (or even logically impossible) to estimate because implicitly you do not know what done means.

The second difference is that (broadly) how satisfactory a sandwich or other real world object is, is proportional to how long it takes to make. This is not true for software, because it is not a physical entity. It can be tripped up by a single incorrect character, and then, forget tasty - your software sandwich doesn't even exist.

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

#78
post #61

Earlier quoted context omitted.

Mark Bernstein is recoding a program called StorySpace which dates from 1980s?. He is blogging about it. Day 6 will give a flavour http://www.markbernstein.org/Mar12/Day6.html He is working on a familiar design, and knows the old code. He is recoding in newer tools.

Look Mate, By no means Am I downplaying anybody's accomplishments nor am I trying to say that anything can be built quickly. Rome was not built in a day. Neither was Git as we know now. But given a narrow set of requirements you can get a prototype out pretty quickly. Especially today when so many reusable things are available. Linus coded up a distributed vcs(Not with all the feature we know now today) sufficient en…

I was agreeing with you and providing an illustration of the working practice of a 'craftsman' programmer!

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

#79
post #60
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…

I once interviewed a project manager.. asked how he came up with deadlines. He said "ask the programmers and subtract 20%". Talk about a red flag in an interview!

That's funny, because as a programmer I always estimate how long it'll take and add 20%.

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

#80
post #68
post #62

Earlier quoted context omitted.

They're the "responsibility buffer" - the guys you get to blame and fire rather than the actual executive who initiated the project and failed to provide real support and leadership. Sorry I disagree with this. I haven't seen Senior Execs getting fired. In fact its almost always the other way round. The Execs take credit for nearly all success even if they don't move a finger to make it happen. It happens so often Ex…

I think you may have misread the parent. The "responsibility buffer" he was referring to are PMs (Project Managers), who are not senior execs. Edited : PMs, by nature of their (typically) limited skill-set and solidly middle-managerial roles are highly expendable.

Just to note, proper PMs are rarely without a job, they're pretty hard to find. A good PM is paid more than a good developer, usually silly money, because true project management is a pretty large skill-set.

What you're describing is the enterprise habit of giving a generic middle manager the PM role and expecting them to have all the skills and then firing them when said project implodes.

Post reply on HN