Hacker News Reader

Comment by sdoering | Hacker News Reader

I was more often than not 'guilty' of what the author describes. And I actually love being the lone detective on the hunt for a cool solution.

I am not a dev by trade (data analyst) but still love to work on problems solved in code.

A lot of the advice hit home, but what struck me was this part:

> Encourage engineers to get something end to end launched internally as quickly as possible.

This is something my boss never ceases to tell us. When we build something we shall strive to have some first small thing end 2 end done as soon as possible. Rough around the edges, not refactored, code being repeated - all fine. But it has to work end to end.

Because we can brush it up and make it stable later. Because when starting we only have a vague feeling for the problem space and we need to learn the lay of the land by navigating it.

I will always cherish this advice.

View on HN

I find when this happens, it never gets refactored. The edges can be smoothed, but the architecture is dried and hardens into something that needs to be worked around by everybody else touching the code. The easiest way to solve the issue becomes the only way.

My experience differs. But maybe because I love to refactor and create a clean architecture.

Also I learned a lot from my boss' refactorings. Before that I never would have imagined how far a good abstraction can be driven.

Depends on a team, of course. But happens often with business solutions. Done, whichever way. Next. It broke down in prod? Well, go fix it, it's yours now...

The frustrating thing is when only the first half of this philosophy (ship now, fix/polish later) is adhered to, where things get shipped frequently but seldom followed up on. The incentive to finish things needs to be strong for not only the engineers but also for the product teams and managers directing them, but as far as I can observe this is exceptionally rare — in fact it almost seems like the norm for non-engineers to push for shipping new features over polishing older ones. A lot of the engineers I know would love nothing more than the opportunity to polish the project they’re responsible for to perfection, but are never given the chance.

If you can present a metric which shows that said thing is bad on some dimension, and explain why it's bad for the customer (/business) and why what you will fix will improve it, and how much work is involved, you'll have a better chance of moving it through.

I agree. I know that the freedom to create sensible architecture is a privilege.

Even if other things may not be perfect (but what job is perfect in all areas), my boss knows the value of refactoring towards a stable and maintainable architecture while keeping a reasonable schedule for shipping.

I agree, but I've also tried to polish things without a strong need and it's difficult. The work can feel burdensome, useless, undirected, and sometimes requires major changes that can't be done (without inflating the scope of the work).

This should nearly always include writing integration tests (that run on every change) to ensure you can refactor with confidence.

If there are no tests, the team will waste a ton of time anxiously monitoring and reasoning about the messy code and the impact of their changes.

I do. I even implemented tests for tracking code to be developed locally (including mocks).

This way I'm able to quickly and confidently refactor as well as add to existing tracking code (web analytics).

I always phrased this as "You don't know how to build something until you've built it."

It's very easy to get stuck in design hell and write yourself into a corner. It's much better to get something that does what you want, then you change it to do it how you want it to.

Though like others have mentioned, this requires an engineering culture that values the second part.

I still find it amazing how many "first small thing end to end" wind up being the last major version for years. That's not a bad thing, I've grown to love it, and I think it's a tenet I should make a more conscious effort towards.

and then it never gets refactored.

But essentially I agree with you, good writers use the same technique: write once, revise many times.

Good code, IMO, only exist after many refactors.

It might be good advice, but that's not engineering in concept, spirit, or practice of the term.

I don't usually pick an absolute, decisive side in the "what counts as engineering" debate, but this is the opposite of engineering.

Lol, you think physical engineers don't throw together prototypes that they know won't be good enough for the final design just to get everything working together?

They do a preliminary design. They don't throw up some 2x4s and corrugated aluminum to use as a building in the meantime while doing a real design.

Or they iterate designs and prototype manufactured products.

They do not stamp and accept professional liability for thrown-together designs that bosses want to prematurely push out the door into production.

They tell the boss to budget them what's needed, or go find some other sucker to stamp it.

I'm mixed on the pros and cons of professional licensing, but it does give PE's a great amount of personal authority in refusing to be a part of substandard work. Even to clients and bosses.

But the difference between preliminary design and final product is much smaller in software than in building, so the cost of making an actual working prototype during the early phases is much less.

I would add that not all physical engineers have to get licensed to do their work.

So what's the difference then between that type of iteration and the type of iteration you see commonly in software? It sounds like the main differentiator for you is "doneness" or something similar to that?

Reply on news.ycombinator.com