81–90 of 117 posts
Earlier quoted context omitted.
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%.
Earlier quoted context omitted.
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%.
A recent conversation I had with my MD, regarding how long to estimate for a project, involved me adding 6 months for each feature added to the specification.
We're also careful emphasise how inaccurate these estimates are, and we don't really know until we start.
Of course this is the initial "finger in the air" stage. We try to be a little more concrete with more immediate requirements. Of course, we've gotten those badly wrong too.
Is Pachelbel's Canon considered complicated as far as music performance goes? Reading that knocked me right out of the flow of this article. What's he thinking of? Maybe someone's complicated improvisations on top of the (really simple) canon? On topic: the post didn't really cover where the layperson's base estimate comes from -- a layperson sees X pages, or X features, and multiplies that by... what? The reference…
Is Pachelbel's Canon considered complicated as far as music performance goes?
Manager: How long is this going to take?
Me: Virtually impossible to predict accurately
Manager: I need a date
Me: 3 months
Manager: That's too long, we need to get it done in 1 month
Me: OK, 1 month
... 5 months and several iterations later ...
Manager: Project has been deprioritized, we have a new project, how long is this going to take?
Me: Virtually impossible to predict accurately
Manager: I need a date
Me: I need you to be stateful.
In our startup, I am responsible for the frontend coding. Very frequently, I get requests from other developpers to implement this or this, and very often those requests are annotated by a "c'mon, it is just CSS, it'll only take you 5 minutes" when they have absolutely no idea what they are talking about, because they never ever did real frontend developpment. They simply think that everything boils down to HTML and that frontend is NOT really programming. Attempting to explain that a frontend also has logic similar to backend, and that no, plotting graphs when you don't even have the data modeled is not just a 2 liner with Google Visualisation.
I am always offended by people estimating time for work they never did. So I find myself very rarely giving estimations. Sometimes when I have a very precise idea on how to implement an idea right when I'm being told about it, I usually say "yeah this is definitely doable in a short time span". Meaning things that do not take more than half a day to implement, because you already compiled the code in your brain.
Now, when a colleague of mine estimates stuff for me, I tell them "No I don't think this is going to take X minutes to implement. If you think it is implementable so fast, why don't you go ahead and do it.". When they take it to the word, and I see them still struggling after many hours on some problem that are trivial to me, I will go ahead and help them out. After a few times, they usually won't bother me with estimations anymore... NOT.
I've regularly seen very experienced developers make exactly the same sort of mistakes when talking to people outside of their field (Sales, Design, etc.) because they miss things like:
* Sales is about building stories and relationships - it's not just listing features and meeting people.
* Design is about understanding the user, iterating, testing and experimentation - it's not just making things pretty.
I wish technical folk were naturally better at this sort of thing - but they (and I :-) keep making similar sorts of mistakes.
(It's also amusing to see the "it's not like building a bridge" analogy turn up. Go talk to some engineers, architects and builders - and find out how many of those projects ended up matching the original time and cost estimates :-)
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…
Phase 0 (Big Corporate IT): PM is given deadline by business, goes through song and dance of negotiating deliverables (without any analysis being performed or developers consulted for estimates), is forced to start work with a small team of internal people outside of the business area not resourced to any projects currently, but who've coded a few lines of VB so can probably do a web application scaling for 5,000 use…
Management gets started so quickly to meet their quarterly bonus - not that they don't get an annual one. The quarterly bonus allows them to synchronize the announcement of initiatives with Wall Street.
I think it's much more domain-expert vs non-domain-expert rather than programmer vs non-programmer. I've regularly seen very experienced developers make exactly the same sort of mistakes when talking to people outside of their field (Sales, Design, etc.) because they miss things like: * Sales is about building stories and relationships - it's not just listing features and meeting people. * Design is about understandi…
That's an important point.
I used to work in sub-contract electronic engineering. We had a lot of information about how long it took to do things, and how much items cost. In theory, estimating the cost of projects should have been straightforward. And then you add 15% for wiggle room.
And still it's hard to keep things going out on time and on budget.
One of my favorite ones was a fellow who wanted an iPhone and iPad game done. He proclaimed that it had to be done for $10K. This game easily required six months of work. It also required server-side development and support. He also had no idea that every so often you need to fix, I mean, update, your apps because new iOS releases might break them. I was open-minded and decided to invest some time educating him on th…
You're friend could have easily got a cheap, inexperienced programmer anywhere else in the world, including the US, and still had the same problems. He had a budget, you knew it wasn't enough for what he needed, and he came up snake eyes.
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…
An example would be something like a main-stream game, say Battlefield 3. The have marketing videos months in advance, they sell games in advance and by doing so they promise that the product will be available at a certain point in time. It may contain bugs, but, unlike what you say, it cannot just be whatever is ready at that time (say without support for sound, or not controls)...