Comment by jakelazaroff | Hacker News Reader

Comment by jakelazaroff | Hacker News Reader

Strongly disagree with “Do the Refactoring First”. It is inevitable that your project will grow in ways you can’t anticipate. If you spend too much time up front on architecture, one of two things will happen:

1. You build abstractions that are not useful in the future, or

2. Worse, you build abstractions that constrain you from making future changes.

Of course, either of these can happen anyway, but at least then you haven’t wasted a bunch of time refactoring before you know how your code base will grow.

I prefer this approach from The Grug Brained Developer:[1]

> next strategy very harder: break code base up properly (fancy word: "factor your code properly") here is hard give general advice because each system so different. however, one thing grug come to believe: not factor your application too early!

> early on in project everything very abstract and like water: very little solid holds for grug's struggling brain to hang on to. take time to develop "shape" of system and learn what even doing. grug try not to factor in early part of project and then, at some point, good cut-points emerge from code base

> …

> grug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along with experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build skill in seeing, patience

> sometimes grug go too early and get abstractions wrong, so grug bias towards waiting

[1] https://grugbrain.dev/

Yes the author strikes me as a early/mid career SWE rather than a seasoned professional (10K hours is often used as an allusion to "mastery").

1. Junior: hack a solution from A to B by any means necessary

2. Mid-level: wait, design matters. Abstract everything up front!

3. Expert/mastery: wait, complexity also matters. Consider many paths and finds sweet spot that is simple, robust, extensible, maintainable.

I think the intermediate level, do the refactoring first, clean code mentality is a big one to grow out of.

The ultimate mastery is to think about "what does the computer need to do?" If there is a button click and some data has to be aggregated, those are two operations that should result in two blocks of code changing, the event handler and the db select group by (or other data source).

Everything else beyond it is extraneous code and you should think very carefully if you are adding any line beyond that.

The worst in the typescript world is elaborate types which do not work all of the time. Better to have implicit types doing most of the heavy work and remember you are building software, not doing type system research.

For me, the most important thing in this situation is coupling. The code implementing a feature may be an ungodly mess, but by minimizing its coupling to the rest of the system I make it easy to improve (or remove) later. I would much rather have messy and confusing code that is self-contained than an elegant abstraction with a large blast radius.

And you do that decoupling by…

Refactoring.

So I’m a little confused about why it sounds in this whole thread like we are vilifying refactoring without actually saying we are doing so. It’s weird.

Refactoring "up front" is what people are taking issue with. It's extremely rare to have a project where you know every requirement and they never change "up front" before writing any code.

Either Fowler’s 2nd edition made some pretty big changes I’m unaware of, or we are all using very different definitions of Refactor. Do you guys mean “redesign”? Because that’s a very different word from “refactor”.

No, I’m talking about the first time I write something. At that point in the game, my highest priority is to minimize the coupling between that code and the rest of the system (rather than, say, performance).

The article reads a bit like those blog posts from junior developers in third world countries who are trying their hardest to prove that they’re capable developers who know what they’re doing, in order to make it out of their current situation.

> sometimes grug go too early and get abstractions wrong, so grug bias towards waiting

Tried to hammer this into an intermediate level colleague recently while pairing and they just wouldn't accept it; eventually I said, ok let's do it, and as expected it ended up just creating a couple more days of toil for us. Hoping this turned out to be a learning experience for them.

Refactor first and overarchitecting up front are completely different things, though.

From the article:

> What I propose is to spend your first 40-50 hours planning and refactoring. Just create a few controllers, brainstorm how that would scale in the future, refactor, and then continue.

That is overarchitecting up front. What I would propose is to follow those steps but stop after “create a few controllers”.

Reply on news.ycombinator.com