Go Hard Early | Hacker News Reader

Go Hard Early

icelab.com.au

101 pointsmichaelhoney50 comments

"You’re not a teenager leaving your homework until the last minute. Professionals go hard early."

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)

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

2: http://bellard.org/

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

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.

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.

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.

This is pretty much what I do, except that I start with the medium difficulty/high importance-problems to establish a base architecture and then test that architecture for durability with the high difficulty/high importance problems. After that, it's usually smooth sailing because the architecture should just carry the project.

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.

Can you elaborate a bit on said psychological structure?

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.

[Edit] Also, money always helps ;)

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.

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.

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.

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

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

This is what I see: http://i.imm.io/12ieb.jpeg

...

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.

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

Seems to tackle the Pareto principle: http://en.wikipedia.org/wiki/Pareto_principle

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.

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?

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.

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

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

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

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

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

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.

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.

just because your spreadsheet says it will take this long, doesn't mean reality will take a lot longer

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.

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

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.

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.

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

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

Define "thinking".

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

It's a balance.

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

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

That's what she said?

Reply on news.ycombinator.com