Hacker News Reader

Comment by sobellian | Hacker News Reader

You should usually wait to refactor until after you write the code and preferably ship it to someone.

You may not understand what makes a correct implementation. Don't waste time refactoring incorrect code.

You may not understand what makes a performant implementation. Don't waste time refactoring code that's too slow.

You may not understand what the user wants. Don't waste time making something no one wants.

You may not understand how the software needs to evolve. Don't waste time making something extensible in a way that will never happen.

View on HN

It's important to note that this is only really relevant advice for a specific type of startup that is still trying to rapidly iterate to find product market fit.

Personally I find it incredibly annoying to work on and with with products that were developed like this. There are so many half baked features that technically "work" but are slow, buggy or difficult to integrate with.

It's relevant if you need to rapidly iterate, period. The test is not whether you work at a start-up, but how well you understand your problem. I am currently doing a lot of automated design work with optimization over highly non-convex constraints. Good luck writing that without rapid iteration.

Fair point, but I have seen a lot of shitty software developed with this mantra. Usually because the "iterate" part is forgotten in favor of the next "rapid" development. I agree that the quickest way to learn whether your solution is valid is to ship & experiment. But once you know the solution (which is sometimes not even that complicated) then you should really take the time to produce a solid piece of software before moving on.

But I agree, my original comment is probably a little too critical. There are valid times to rapidly iterate and ship. When it turns into the _only_ way you ship software, I think it becomes a problem.

One of the very frequent challenges I have with optimizing code, is that unless the problem is very highly contained, first I have to look at this code that’s all over the place, both physically and emotionally, and just try to figure out wtf it’s actually trying to do. I can’t replace it unless I know the requirements. The intent.

Give me a piece of code that’s wrong but clear about it, and we’re good. I can get in and out and move on to the next most tricky:value ratio’s problem.

Refactoring it to that point will always pay dividends. Even if it’s just for the next person trying to add more functionality in this area.

I don't think you necessarily need to optimize before you make the code "clean" but you should at least understand what it will take to make it performant. This is a stronger requirement than it might sound like since most programmers are quite bad at predicting what will perform well without profiling first.

So knock together a prototype and profile that to understand what the bottlenecks are in your program, then you have an informed baseline of how the program needs to fit together to function well.

Reply on news.ycombinator.com