Hacker News Reader

Comment by gmueckl | Hacker News Reader

Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. If you violate this rule and build other features on top of shortcuts, two things will inevitably happen: you will have to replace the shortcut with a proper solution eventually (it is only a matter of time) and by the time this happens, the assumptions underlying the shortcut have implicitly been taken on by the code depending on it. This means that you will have to review and replace a lot of dependent code as well.

I have gone through that dance often enough. It ends up being more time consuming than doing it right in the first place each and every time.

View on HN

Yes, it's more time overall, but that's not the point.

From the example in the article, if it would take them 2 months to build a robust email delivery system or 2 weeks to put a temporary hack in place, it could be worthwhile to the business to do the hack if it means they can start user-testing 6 weeks earlier.

Also, if they're still in the product-fit stage of their business development, they might find that the product isn't as useful/worthwhile as they thought, and scrap it after 2 weeks testing. This would allow 6 weeks of overall developer effort to be spent on another initiative.

Just because you know that developing throwaway code is waste, doesn't mean it's necessarily a bad business decision.

Is it worth the while when you have to spend more than weeks to do it right later? Again, in general it is not. You are citing a very, very specific business reason as a justification. In 99% of all cases, no good business reason exists to waste more money later. Essentially, this is what you are asking. In your example, it's either 8 weeks total to do it right in the first pass or 10+x weeks total to do it right later when you have the still unquantified extra overhead of not breaking stuff that has been built around the insufficient solution.

You have to look at it differently: if you hack something in two weeks, you will:

- be able to switch to other, more important tasks more quickly;

- allow the business to better discover what the actual requirements are while they have an MVP solution in place.

Resources are finite: you only have a limited number of engineers, and the business needs to be moving forward. This approach allows you to do so, while mitigating a lot of risks at the same time.

The costs are not lost: they bring back business value in terms of fast progress, and mitigates risks.

That is actually the point of the metaphor. Taking on debt without a clear business reason is supposed to sound bad.

Not all spending is wasteful, even when, in an ideal scenario, it could be avoided.

I like that delineation between branches and leaves. If it’s a branch, solve the real problem. If it’s a leaf, consider just getting it done.

I worked at a company where there was an API and an explicit place for such hack code, for consultants to customize the product. The way it was done, was to ensure such code was a pure leaf.

> by the time this happens, the assumptions underlying the shortcut have implicitly been taken on by the code depending on it.

If this has happened, your encapsulation was insufficient or you waited too long to replace the stop gap solution or maybe your documentation wasn't clear about what assumptions made by the throwaway component are safe to make in the main codebase.

> The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it.

I think the article's description of when stopgap solutions should be used is far better. Yes, a leaf feature is likely to have fewer encapsulation issues, but that is only part of it.

Another way to say this could be if you decide to take the route of explicitly not solving an edge case or write throwaway code, that feature becomes a leaf until the branch of immature code can be pruned and a new, stronger one put in place.

It doesn't become a leaf automatically. You have to force it to stay a leaf. If you don't find a way to do this, and if things grow on top of it, then you are in trouble. This is hard to do in most architecture patterns.

"Crap is OK until you build on top of it. Then you need to clean it up."

Reply on news.ycombinator.com