Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How boring should your team's codebases be

blog.meadsteve.dev

Post reply on HN
Print view View original

11–20 of 235 posts

Re: How boring should your team's codebases be

#11

Post by pydry »

This (and a few other similar articles) make me feel that there ought to be more emphasis on recognizing "good novelty" vs "bad novelty" rather than "more novelty" vs "less novelty".

The word "budget" frames the question wrongly, I think.

If there are 4 new technologies on a project and the team were insistent that they each solved a lot of pain I'd be less averse than I would to 1 new technology that they adopted because it was "cool", "made by google" and "everybody [cool] is using it".

Re: How boring should your team's codebases be

#12

Post by samsquire »

What frustrates me about the software industry is the many failed lineages problem. There are many mountains of code that get the job done at various companies but isn't shared. The lineage of these in-house frameworks or effective solutions to problems kind of don't go anywhere, they simply end. The lineage ends and doesn't cross pollenate. So lessons aren't shared. We are in an era of explosive growth where there is a new framework or new library or new technology introduced.

I learn from whitepapers and reading English descriptions of people's problems. I find this easier than reading someone else's code. Code is extremely powerful but it has a very high maintenance cost and change costs. Just getting up to speed on the Postgresql codebase or the Linux kernel or any other system tool is hard work and an investment.

You kind of need to work 40 hours a week to get familiar with a codebase to be effective in it. But I can get familiar with a problem outside the context of a codebase by reading a whitepaper and writing some code. Reading a whitepaper feels more effective use of time than reading someone's codebase. You need to jump around a lot of code to understand the codebase.

I think the effort for the ideal solution is underestimated. People abstract to their own understanding. And that abstraction might not be intuitive to other minds.

I would prefer to work on a codebase that solves problems effectively than a codebase that is novel.

Re: How boring should your team's codebases be

#15

Post by jiggawatts »

Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any such thing. Just hit the build button and "copy to deploy".

For about a decade I used to turn up to that customer annually for "maintenance", which primarily involved importing some CSVs that changed every year, and also updating the logo images and icons to match any rebrands.

In that time the system had two million users, went through 4 OS upgrades, 3 database upgrades, and went through the 32-bit to 64-bit upgrade also. The underlying runtime had 3 or 4 major updates, depending on how you count it.

Zero outages, no problems, only the occasional performance regression that could be fixed by poking the database statistics to get things back in their groove.

The problem was...

You see, all of the above was a problem, because it didn't keep me employed. I was not the "hero" for saving the day. Entire teams of people weren't involved. There was no visibility at the senior management level. Nobody got scared, or had to throw money at it, or hire consultants to review it.

So it had to go.

It was replaced by a system that cost about 500x as much (a 9-digit sum), got rolled back for failing to meet requirements, and then got additional funding and was eventually forced upon its hapless users.

That, apparently, was doing things "properly". That got everybody involved. Everyone got their beak wet. All the way up to government ministers and their lobbyists. Multiple consultancies were engaged. Reports. Audits. Reviews.

This is why we can't have simplicity: because it doesn't scale.

Re: How boring should your team's codebases be

#16

Post by bdg »

jiggawatts wrote: post #15

Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any s…

I understand the annoyance of it being replaced for a more complex more expensive system, but I would also like to know: What was the reasoning provided and what did decision makers truly believe about the whole thing?

Re: How boring should your team's codebases be

#17

Post by sshine »

samsquire wrote: post #12

What frustrates me about the software industry is the many failed lineages problem. There are many mountains of code that get the job done at various companies but isn't shared. The lineage of these in-house frameworks or effective solutions to problems kind of don't go anywhere, they simply end. The lineage ends and doesn't cross pollenate. So lessons aren't shared. We are in an era of explosive growth where there i…

I can't help but think that FOSS is the key to sharing the lineages.

Every single place I worked, people just want to make code work, not readable.

Re: How boring should your team's codebases be

#18

Post by bdg »

samsquire wrote: post #12

What frustrates me about the software industry is the many failed lineages problem. There are many mountains of code that get the job done at various companies but isn't shared. The lineage of these in-house frameworks or effective solutions to problems kind of don't go anywhere, they simply end. The lineage ends and doesn't cross pollenate. So lessons aren't shared. We are in an era of explosive growth where there i…

> I would prefer to work on a codebase that solves problems effectively than a codebase that is novel.

I have a design for a very very boring code base that involves no frameworks or external libs. It works fantastic and has been used by some of the most productive teams I've managed. Those teams can manage "more services than we have people on the team by a scale of 2-4x" (quote from one of the engineers on one of those teams).

But it's crazy boring. There's no frameworks to download, not dependencies to update, no big brand pages. It's just following some very simple rules about where to put different kinds of complexity, very strictly.

It's a hard sell in any programming ecosystem because it has no brand power.

I've debated create the "no framework" spec around this. I even have a tool that can enforce the standards in CI. I just don't know if anyone would actually care.

Re: How boring should your team's codebases be

#19

Post by eatonphil »

Just as one tiny counterpoint, the company I work for [0] builds a database written in Zig, not C. We implemented our own consensus using Viewstamped Replication [1], not Raft. And we built our own storage engine on LSM trees rather than use RocksDB [2].

A lot of this we built ourselves so we can do FoundationDB-style deterministic testing [3] of the entire system which would not be possible with off-the-shelf libraries because they are not deterministic.

Another goal was to not allocate memory after startup. A goal that most third party libraries would disrupt.

Sometimes the boring options do not further the technical goals of your project. :)

[0] https://github.com/tigerbeetledb/tigerbeetle

[1] https://pmg.csail.mit.edu/vr/liskov12vr-abstract.html

[2] http://rocksdb.org/

[3] https://apple.github.io/foundationdb/testing.html

Re: How boring should your team's codebases be

#20

Post by IvarTJ »

KronisLV wrote: post #7

Edit: I rewrote this as a blog post of my own, where I expand upon some of the suggestions, might be more readable: https://blog.kronis.dev/articles/how-boring-or-novel-should-... Overall, I'm tempted to agree, whilst keeping in mind that you sometimes definitely need a little bit of novelty, which the author brings up at the end of the article as well. Here's a few bits of my personal experience, where some novelty…

I've encountered a code written in the 12factor style of using environment variables for configuration, and in that particular case there was no validation nor documentation of the configuration options. Is this typical?

For onboarding new members, I would have thought it preferable to have a JSON configuration, where both documentation and validation of configuration options are provided by a JSON Schema file.

Post reply on HN