Hacker News new | ask | show | jobs
by lijok 1053 days ago
At a consulting gig I did, we were bootstrapping a brand new python engineering team for a new line of products. We chose the frameworks, set standards via decision records, wrote a template service that you would copy paste, and build on top. Cross cutting concerns were pulled out into a library that all of these services installed. Most things were standardized, all APIs felt like they were written by a single person, and yet little was abstracted. It was simple and beautiful. An engineer would come onboard, look at one repo and be able to navigate all service repos going forward. You could see and feel the repetition, aside for the business logic, it was like reading the same book over and over again. The team was delivering at a crazy velocity.

Then a year or so later the client brings us back in to help diagnose and fix why their delivery dates continue slipping and number of bugs in production is increasing. Finds out a new, very vocal hire, came in, saw the repetition and decided to build a "service service". A service, into which you would pass a single python file of pure business logic encoded as a b64 string, with some decorators, and it would set up the endpoints, serialization, DB, etc automagically.

4 comments

If you feel confident refactoring some code then you have been able to read and understand it easily. If you can read and understand it easily then it’s good code, leave it alone.
"Never refactor"? Great advice
That’s not what I said.

If the code is confusing then absolutely refactor it.

There’s 3 levels of understanding DRY

1 programmer is unaware of DRY

2 programmer sees how much simpler code is when you reduce duplication

3 programmer sees how DRY can sometimes cause it’s own problems.

A good clue is that if the cyclomatic complexity of the system goes up when you DRY then you shouldn’t DRY. For example if the new single method is now full of if statements then you’re creating problems.

Another clue is if you’ve just coupled things that shouldn’t be coupled.

Low cyclomatic complexity and coupling of components is much much more important than having a DRY code base.

There are cases where doing the "same" work twice is sufficient, preferred even...

Somehow some colleagues found it absurd to parse some code twice, but don't see the insanity of parsing code, getting an AST, serializing, sending it, and then deserializing correctly.

Never mind the fact that the serialized AST is 250x larger, and deserializing arbitrary constructs without codegen is a whole different can of worms, and especially harder when the code is running in 2 different programming languages.

that’s the danger.

you built a system for cogs.

someone hired a thinker.

First time I've heard this, I love it. Definitely resonates both as the one who is there first, and then future ambitious folks would rather rebuild than understand and extend. Also, relatable when I come in somewhere and immediately start thinking about how I would re-build something instead of improving it. We sure have a lot of hubris in software, don't we?
If you're looking at a giraffe's laryngeal nerve[0], you see it making a circuit from the jaw, down the loooong neck, to the chest, back up the loooong neck, and to the jaw again. It's like this because it used to be an small, innocent "u" shape back before giraffes evolved long necks. As their necks elongated, there was never any effort to rewire the nerve, so it elongated too.

When encountering that situation, the correct urge is to rebuild against current circumstances.

0: https://forum.donanimhaber.com/store/c9/ef/2d/c9ef2d955e3f99...

"What I'm hearing is, there's a vacuum in the market for giraffe re-cabling services."
I hope you regularly give talks. You would be an amazing speaker.
Very good point, eloquently worded
Eh, in this case your "thinker" sounds kinda dumb to me.
we aren’t disagreeing.

thinking isn’t always smart. being a cog isn’t always dumb.

sometimes the smartest thing to do is understand how a system is built and accept that until you understand it, you should learn about it. as a cog.

From why you've said it sounds like maybe the issue was really how they factored out the common code (Python loading base64 encoded Python is clearly insane) rather than the fact that they did.

It's difficult to draw conclusions from these sorts of things though because the answer is "sometimes you should copy and paste a bit, sometimes you shouldn't" and you just have to have skill and taste to know the difference.