

Go Hard Early - michaelhoney
http://icelab.com.au/articles/go-hard-early/
"You’re not a teenager leaving your homework until the last minute. Professionals go hard early."
======
dancesdrunk
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.

~~~
bru
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)

1: <https://news.ycombinator.com/item?id=5187585>

2: <http://bellard.org/>

~~~
coldtea
> _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.

------
scott_w
From the comments, a lot of people are taking the wrong message from this
article.

It's not "get stuck in and don't think about it", it's actually: "think about
what needs to be done, then start with the hardest".

It's actually something I learned during a group project during university.
The process is something like:

* Group all your main features

* Plot them on a graph of importance (y-axis) vs difficulty (x-axis)

* The features in the top-right (high importance/high difficulty) are the first things you do

* The features in the bottom-right (low importance/high difficulty) are the last things you do

This is something you have to keep evaluating over time, using a
process/method of your preference (that works, of course).

The reason you do the hard/important things first is because it lets you know
whether the project can go ahead for the minimal cost.

To take the group project I did as an example: we had to do a mapping
application on a mobile device. Most groups went and wrote some code in Java,
and wrote a routing algorithm. A few of us realised that getting something
running on a device was the "hard" part, so set about getting that working.
Afterwards, we went and drew some graphics, and handled some simple I/O with
pre-programmed behaviour. When it came to writing the routing, we again tried
everything against the device ASAP, so we knew what its real-world performance
was.

Those who started writing Java without the device realised they had to convert
it to J2ME before they could make it run, wasting a bunch of time. A good
percentage had nearly nothing running by the end of the year demo because of
this.

~~~
hexagonc
No, this is not the message from the article. Perhaps, it is what the message
_should_ be, or what the author _wanted_ it to be, but it is not what was
said. Just reread the first sentences. I quote:

 _You have a nice big project you’re about to get started on. Delivery is in a
few months, so you have time to plan, sketch out some initial ideas, to let it
germinate in your head._

 _Right?_

 _No. Start now._

He is saying that you don't plan. You don't have time to let it "germinate in
your head". Don't look for the hard parts of the problem and tackle them first
because, if the problem is nontrivial, you probably don't know what the hard
parts are, anyway. The hard parts are the ones you don't expect from the
start.

The author's thesis is that you should start early so that you can encounter
the hard parts as soon as possible. It is about the fact that you will
encounter unexpected challenges that will force you to reassess your strategy.
I'm not taking a stand one way or another. I think your strategy has its place
(and in fact, is closer to the way I tend to do things) as well as the
author's.

~~~
scott_w
I completely glossed over that part, thanks for pointing it out.

I don't think he's completely wrong in his assertion. My feeling is that he is
aiming that sentence at developers who have a tendency to over-think. I've
seen developers (including myself) sit and think and research and think and
research and not really do anything.

In those situations, just putting your fingers on the keyboard and writing
anything will be an improvement.

------
ultimoo
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.

~~~
mahyarm
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.

~~~
minimize_me
Can you elaborate a bit on said psychological structure?

~~~
ajanuary
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.

[Edit] Also, money always helps ;)

------
jared314
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.

------
redguava
Great advice.

I 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.

------
mootothemax
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.

~~~
praptak
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.

~~~
mootothemax
_In my experience this applies to every feature._

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

~~~
praptak
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.

------
ivanjovanovic
I would explain this concept as two kinds of life philosophy and ways to
approach the future.

1) "exponential" - which gets everybody happy at the beginning and then
crushing them with hard reality after things start getting more and more
complex. There are a lot of real life examples of doing this and I can rarely
find the one which has brought the value at the end. In software development
experience I have found this very wrong.

2) "logarithmic" - when you do a lot of investments into solving the hard
structural/strategic problems at beginning and then riding much more far on
the benefits they provide. This approach works pretty good in real life as
well like investment into fundamental understanding, saving early so
accumulated benefits get higher.

------
throwawayG9
This is what I see: <http://i.imm.io/12ieb.jpeg>

...

------
hunvreus
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.

------
lifeisstillgood
You aren't a teenager putting off homework till the last minute

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

------
khariel
Seems to tackle the Pareto principle:
<http://en.wikipedia.org/wiki/Pareto_principle>

------
lubujackson
This only works if you are committed to trying out the idea and then JUNKING
YOUR CRAP CODE. By the nature of coding problems, the bigger the codebase gets
the worse bad decisions fester, so if you approach the early rounds as "trial
and error time" and then commit to a big refactor once you DO plan out the
bulk of the project, this can work. Otherwise it is easy to end up with a
patchy mess.

------
columbo
The problem I see is that this is really just your perspective of the project.
It could very well be that the 0.5 gamma curve is really a hyperbolic sine
(<http://mathworld.wolfram.com/HyperbolicSine.html>). If it is, are you going
to have energy at the end to take that next mountain?

------
ajhit406
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.

------
powatom
All very interesting, but where's the evidence that this actually works?

As they say - fail to prepare, prepare to fail.

------
T-zex
The relevant concept is a Parkinson's law [1]

    
    
      Work expands so as to fill the time available for its completion.
    

[1] <http://en.wikipedia.org/wiki/Parkinsons_law>

------
banachtarski
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).

------
k__
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...

------
rubinelli
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.

------
MortenK
Or you could apply proper, professional project management methods to make
sure the last 20% doesn't take half the time of the entire project.

~~~
coldtea
Yes, because those methods have worked wonders so far in IT projects,
including multi-hundred million dollar ones...

~~~
MortenK
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".

~~~
coldtea
> _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.

~~~
MortenK
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.

~~~
peterkelly
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.

~~~
MortenK
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.

------
perlgeek
It's important to mention that "start now" doesn't mean "start coding now",
but rather "start working now". Don't omit the planning phase.

------
namank
Well, but there IS something to be said for letting the idea simmer. Isn't
that where ideas come from?

~~~
coldtea
No, they come from thinking about problems and gaining experience with a
domain.

~~~
namank
Define "thinking".

------
lsiebert
I think there is something to be said for not dithering over how to do it too
much.

It's a balance.

------
madiator
Try this in a coding interview and you will go home early.

------
whizzkid
As much as I agree to what title says, i am against to what the context
explains.

------
rational_indian
That's what she said?

