This reminds me of an obvious-yet-not-that-obvious trick when it comes to quoting for new features using an unknown technology:
Be honest, ask to sacrifice a couple of hours to throw at a proof-of-concept, and then you should have a better idea of how long the full feature will take to implement.
In my experience this applies to every feature. Doing a small chunk tends to improve estimates - somehow they tend to go up rather than down, go figure :-)
This creates a sort of an impedance mismatch if you do your work in sprints - it's good to do the initial chunk in one sprint and the actual body of work in the next one. Unfortunately this means that features' implementation latency goes up.
Past the first few projects, you should have a pretty good feel for how long standard CRUD, user auth, email fun and other such things should take.
Basically, the more experience you have, the fewer times you should need to sacrifice time for proof-of-concepts - but there'll always be a need for them :)
Well yes, I meant "every feature" for some values of "every", obviously :-) For some features the gain is not noticeable enough to justify doing the initial spike.
I winced at the last sentence -- "You’re not a teenager leaving your homework until the last minute. Professionals go hard early."
I'm a graduate student who still leaves homework for the last moment sometimes. This mantra of going hard early can also be applied to a few of my assignments and academic projects.
I think the entire psychological structure of academia leads to a tendency of procrastination. I don't procrastinate at work much at all, I procrastinated way too much in academia.
Properly designed academia would probably remove procrastination from K to PhD.
I'm not OP but presumably: homeworks are done alone at home whereas professional works are done within a team at a workplace. Procrastination is the demotivating consequence of working alone, isolated.
To add to the other response(s), there's a sense of artificialness to homework and the way it's drip fed.
The deadline is just so the setter has a schedule to assess it, and the next one will be coming at some point in the future.
With work it's usually all coming now. If you're not doing task a, you could be doing task b, c, d or e instead. Of course good planning and management will mean time is organised between all the tasks to get them done one at a time (or as close to) and it's not a daunting pressure, but I find there's always a sense that there's lots to do.
In the cases I've had where there doesn't seem like a lot to do, that's when I tend to procrastinate with what I'm meant to be doing, looking at this and that other interesting thing we could be doing.
In my experience, those parts aren't necessarily hard; they are hard to estimate, e.g. getting your interface pixel-perfect or interoperating with a legacy system.
Perhaps more importantly, getting feedback early on your progress is incredibly important. These curves are all in 2 dimensional space, but you could very well be flying off into oblivion and not to your intended destination.
Check in with mission control (customers / clients) regularly to make sure you're on the right path.
Good idea for doing new stuff.
If you do some stuff 1000 of people have done before, and hundrets of books are written about it, a good planing yields better results...
This applies on broader timescales as well. Get the hard problems out of the way not just on a project, but with the harder decisions in life too (what you're learning, what you invest in, what career to pursue, who to spend time with, etc).
It is decent advice but to be taken with a grain of salt - I've worked with developers who just dive in to the project, no plan in their head and just figuring out as they go along. What you're left with is a mess of code, hacks and workarounds - it works, definitely does, but maintaining or extending it is a nightmare.
On the other hand you have projects with incredibly detailed architectures all mapped out, way too much time discussing / planning / envisioning what to build, when to build it and how best to go about it. Not a single one I can think of actually followed the plan (you will always get kinks in the road), and as such these things are always over due and over budget.
I guess it's more about finding a balance with what works - perhaps keep an end goal in sight; with a simplistic high level overview of the project/feature, thus giving you the freedom to move around any problems that may arise, but also not tying you down to a detailed plan / architecture that almost certainly will need changing. Iterate fast, stay flexible(?)
But one thing I definitely agree with - and that's to get started immediately; whether that's to plan or to code - just start. It will always take longer than you think, and that last 10% is equivalent to first 90%, if not more.
I think you're right, but I 100% reject this article. Maybe it is good advice for small- or middle-scale products, apps., etc., but it will never hold for a project whose goal is to make a global impact.
I'm actually thinking about Fabrice Bellard, who was featured in a article that was met with success here two months ago[1].
> Bellard made it seem natural to pull together his mathematical insight, broad experience at instruction-level coding, and careful engineering to advance the field this way
When you look at his achievements[2], I have trouble finding one that would have succeeded with OP's "advice". Between an app for coffee-lovers and QEMU, I think the careful thinking and engineering crushes the hype of "let's do it". Sure it sounds good, but that is not the way you will achieve something meaningful.
I may sound like an ass while it is not my goal, but
- I'm kind of surprised to see the success of this article (50 votes for 2 hours) given the low level and amount of content it offers
- I distrust analogies, and this gamma-correction one is definitely unsound (not to say dumb)
>When you look at his achievements[2], I have trouble finding one that would have succeeded with OP's "advice". Between an app for coffee-lovers and QEMU, I think the careful thinking and engineering crushes the hype of "let's do it". Sure it sounds good, but that is not the way you will achieve something meaningful.
I think both you and the parent got the wrong impression.
The article is not saying "just start coding -- and skip planning and engineering".
He says "just start working hard on the problem from day one, INCLUDING the planning and engineering parts -- instead of leaving it for later, or doing only low hanging fruits in the beginning".
"Start working hard early on != just start with coding immediately".
>- I distrust analogies, and this gamma-correction one is definitely unsound (not to say dumb)
Nothing unsound or dumb about it. It's just that he could reduce it to the curve shown --taken to mean project completion--, without mentioning gamma at all.
The curve is the important part of the analogy, not gamma.
I think the best advice is not that you should start working right now, but that you should plan that the last 20% of your project is the one that will take most of the time.
I don't think this is stating that (or what other responses to the parent say). Rather it is saying, figure out what the biggest risk is and try to address that first. Often for startups this will be on the business side (i.e. are you building something people want? Is the market big enough? etc.). But if what you're building requires complex engineering, requires that an API you're unfamiliar with works a certain way, requires that certain data is available to you, etc. it is helpful to also investigate these things early on so that you can be more confident of your project's feasibility and can estimate better.
It sounds like he just restated the idea of POCs and unknown-unknowns. You should consider yourself lucky if you have few enough tasks that you can "go hard early" on without destroying your work/life balance.
True at project start, but the further you progress the more realistic the estimates will be. Half-way through, you can do much, much better than being caught with a 20% effort turning into 50% effort situation. However, if you start by doing an off the cuff estimate and expect that to hold throughout the project, well yes, then reality will be very different. That's the situation where you end up with a 20% or even 10% estimated effort ballooning into a 50% or more effort.
But as the author suggests, just getting into it and working hard from the beginning won't make a difference. That will just ensure a project-long crunch which will be highly detrimental to team performance.
If you consistently have the "last 20% takes 50% of the project" situation, then your scheduling is based on wishful thinking rather than past performance.
No method guarantees project success, as can be seen from plenty of failed high-profile projects. But basic project management and estimation methods applied not only at project start, will definitely get you out of the very basic problem of "90% complete, forever".
>If you consistently have the "last 20% takes 50% of the project" situation, then your scheduling is based on wishful thinking rather than past performance.
There is no "past performance" for most projects, because they are different enough to prohibit extrapolations.
The above holds for large IT projects and software construction of course.
For a small shop making indie games or for a web shop churning websites what you say is perfectly possible.
Past performance before a project start is the average of an organizations output in whatever estimation measurement is used (story points, function points, etc). Some of the most reliable up-front estimates are based on such past performance data. That the projects differ, does not prohibit extrapolation.
As a project gets underway, you get the best possible indicator, namely past performance for the specific project. If you do regular re-estimation, progress monitoring and risk management (and you should, if you are a professional PM), you might not know if you are 52 or 53% done, but you will definitely know if you are ~80% done or ~50% done.
If you want sources, read McConnell's "Software estimation" and references, or if you are in a hurry, take the bite-sized blog post about "Yesterdays weather" from Fowler: http://martinfowler.com/bliki/YesterdaysWeather.html which is based on the same experience and literature.
It really depends very much on the project or organisation. If you're doing anything that involves risk, creativity, innovation, or research, it's almost impossible to predict. And even projects which contain little or none of these aspects often seem to go way beyond their initial budgets.
Agreed. R&D is notoriously hard to estimate and high-risk projects require tight risk management to allow proper progress monitoring. And yes it also depend on the organization as most organizations don't even keep records of initial vs actual estimates, making estimation based on historical data hard to impossible.
As for projects going over initial budgets, that's a different problem from progress monitoring, though they often go hand in hand.
I don't think it is as much about "early" as it is about "intense and constrained batches of work". The "early" part of things is just a sound advice to avoid missing deadlines, but doesn't really help increase the quality of your work or reduce waste.
Early discovery to outline a draft strategy in small committee (one person is sometimes enough) helps the team with reaching velocity quickly once it gets started. The hard part is sustaining it until delivery of whatever it is you've set up as the target.
That's why sprints can be handy, reducing the amount that needs to be delivered so that the team doesn't get slowed down on a big block of work.
53 comments
[ 2.1 ms ] story [ 90.3 ms ] threadI always fall for the trap of expecting the last 20% to take 20% of the time. Not sure why I don't learn my lesson.
Such a common teenage response we all know it - yet it makes part of out formative years and so as professionals we need to unlearn our teenage years
Be honest, ask to sacrifice a couple of hours to throw at a proof-of-concept, and then you should have a better idea of how long the full feature will take to implement.
This creates a sort of an impedance mismatch if you do your work in sprints - it's good to do the initial chunk in one sprint and the actual body of work in the next one. Unfortunately this means that features' implementation latency goes up.
Heh, I think it depends on the feature ;)
Past the first few projects, you should have a pretty good feel for how long standard CRUD, user auth, email fun and other such things should take.
Basically, the more experience you have, the fewer times you should need to sacrifice time for proof-of-concepts - but there'll always be a need for them :)
I'm a graduate student who still leaves homework for the last moment sometimes. This mantra of going hard early can also be applied to a few of my assignments and academic projects.
Properly designed academia would probably remove procrastination from K to PhD.
The deadline is just so the setter has a schedule to assess it, and the next one will be coming at some point in the future.
With work it's usually all coming now. If you're not doing task a, you could be doing task b, c, d or e instead. Of course good planning and management will mean time is organised between all the tasks to get them done one at a time (or as close to) and it's not a daunting pressure, but I find there's always a sense that there's lots to do.
In the cases I've had where there doesn't seem like a lot to do, that's when I tend to procrastinate with what I'm meant to be doing, looking at this and that other interesting thing we could be doing.
[Edit] Also, money always helps ;)
Check in with mission control (customers / clients) regularly to make sure you're on the right path.
As they say - fail to prepare, prepare to fail.
On the other hand you have projects with incredibly detailed architectures all mapped out, way too much time discussing / planning / envisioning what to build, when to build it and how best to go about it. Not a single one I can think of actually followed the plan (you will always get kinks in the road), and as such these things are always over due and over budget.
I guess it's more about finding a balance with what works - perhaps keep an end goal in sight; with a simplistic high level overview of the project/feature, thus giving you the freedom to move around any problems that may arise, but also not tying you down to a detailed plan / architecture that almost certainly will need changing. Iterate fast, stay flexible(?)
But one thing I definitely agree with - and that's to get started immediately; whether that's to plan or to code - just start. It will always take longer than you think, and that last 10% is equivalent to first 90%, if not more.
I'm actually thinking about Fabrice Bellard, who was featured in a article that was met with success here two months ago[1].
> Bellard made it seem natural to pull together his mathematical insight, broad experience at instruction-level coding, and careful engineering to advance the field this way
When you look at his achievements[2], I have trouble finding one that would have succeeded with OP's "advice". Between an app for coffee-lovers and QEMU, I think the careful thinking and engineering crushes the hype of "let's do it". Sure it sounds good, but that is not the way you will achieve something meaningful.
I may sound like an ass while it is not my goal, but
- I'm kind of surprised to see the success of this article (50 votes for 2 hours) given the low level and amount of content it offers
- I distrust analogies, and this gamma-correction one is definitely unsound (not to say dumb)
1: https://news.ycombinator.com/item?id=5187585
2: http://bellard.org/
I think both you and the parent got the wrong impression.
The article is not saying "just start coding -- and skip planning and engineering".
He says "just start working hard on the problem from day one, INCLUDING the planning and engineering parts -- instead of leaving it for later, or doing only low hanging fruits in the beginning".
"Start working hard early on != just start with coding immediately".
>- I distrust analogies, and this gamma-correction one is definitely unsound (not to say dumb)
Nothing unsound or dumb about it. It's just that he could reduce it to the curve shown --taken to mean project completion--, without mentioning gamma at all.
The curve is the important part of the analogy, not gamma.
But as the author suggests, just getting into it and working hard from the beginning won't make a difference. That will just ensure a project-long crunch which will be highly detrimental to team performance.
No method guarantees project success, as can be seen from plenty of failed high-profile projects. But basic project management and estimation methods applied not only at project start, will definitely get you out of the very basic problem of "90% complete, forever".
There is no "past performance" for most projects, because they are different enough to prohibit extrapolations.
The above holds for large IT projects and software construction of course.
For a small shop making indie games or for a web shop churning websites what you say is perfectly possible.
As a project gets underway, you get the best possible indicator, namely past performance for the specific project. If you do regular re-estimation, progress monitoring and risk management (and you should, if you are a professional PM), you might not know if you are 52 or 53% done, but you will definitely know if you are ~80% done or ~50% done.
If you want sources, read McConnell's "Software estimation" and references, or if you are in a hurry, take the bite-sized blog post about "Yesterdays weather" from Fowler: http://martinfowler.com/bliki/YesterdaysWeather.html which is based on the same experience and literature.
As for projects going over initial budgets, that's a different problem from progress monitoring, though they often go hand in hand.
It's a balance.
It's a balance.
It's a balance.
...
Early discovery to outline a draft strategy in small committee (one person is sometimes enough) helps the team with reaching velocity quickly once it gets started. The hard part is sustaining it until delivery of whatever it is you've set up as the target.
That's why sprints can be handy, reducing the amount that needs to be delivered so that the team doesn't get slowed down on a big block of work.