How boring should your team's codebases be • Hacker News Board

Re: How boring should your team's codebases be

#231

Post by osigurdson » Mon, Oct 17, 2022, 7:13 PM UTC

hedora wrote: post #230

osigurdson wrote: post #196

Earlier quoted context omitted.

I'd argue for Option 3, which is to try to understand the workloads placed on the original system and then design the new system based on this. I think having 2K independent database servers would not normally be optimal for 2M users, but it is possible.

If the old system is exceeding uptime SLAs, meeting all business needs, and coming in under the budget for such an investigation (it sounds like the total operations budget was less than 10% of one engineer's time), then why bother?

I don’t know the situation, not touching it may have been optimal. I’m suggesting that if it was going to get re-written, I would at least study the basic parameters of the problem by reviewing the workload of the current system.

Re: How boring should your team's codebases be

#232

Post by osigurdson » Mon, Oct 17, 2022, 7:16 PM UTC

P5fRxh5kUvp2th wrote: post #228

osigurdson wrote: post #223

Earlier quoted context omitted.

Of course, it is hard to say without knowing more about it, but it seems that jiggawatts solution is closer to optimal than the second one. The 50GB database could fit on a USB drive after all and we know empirically that a single SQL server database was able to handle the requests since the old system worked. Also, the fact that a consulting company was able to turn a part time gig for one person into a $100M+ proje…

typical technical forum, thinking they know the best solution based upon a 1 paragraph description.

That’s all we have presumably.

Re: How boring should your team's codebases be

#233

Post by agumonkey » Wed, Oct 19, 2022, 7:25 PM UTC

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…

> 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.

there are a few other instances of that:

- an old article about Michelin (french tire manufacturer) quoting some scientist of theirs "We can make a million hour tire.. but what would we sell"

- recently people said their rust code cause too much downtime for coders because it was too stable too early

flip side of the same issue:

- very often people game their work to ensure benefits: stash duties for later so you can appear busy, or overwhelmed (and claim promotion because you have so much to do)

The global system doesn't reward to true optimization, it allocates people on useless tasks, at best for lower risk, but smart people doing things solid and fast could be using their talents on other problems.

Re: How boring should your team's codebases be

#234

Post by j45 » Mon, Oct 24, 2022, 12:22 PM UTC

Philip-J-Fry wrote: post #40

There's never a simple answer to this. Here's some of the things we encounter: * A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them. * Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what…

If the boring code is working it’s easier from a time and reliability perspective to go play and experiment in an other repo.

R&D or having a “lab” repo for developer experiments is a separate lane until it’s good enough for production. It’s a wonderful way to highlight what possibilities and capabilities are being explored.

Or, you can use the latest and risk having to constantly update it and let it take away time from experimenting.

Re: How boring should your team's codebases be

#235

Post by j45 » Mon, Oct 24, 2022, 12:27 PM UTC

baby wrote: post #197

gavinray wrote: post #162

Earlier quoted context omitted.

> A boring codebase doesn't make a bored developer, on the contrary it frees developers up to think about important stuff and deliver value to the business. Just as I want my language to be boring so I can focus on interesting stuff, I also want my tech stack to be boring - the interesting bits should be in the value added, not the stuff under that. This. I don't want to work with niche languages anymore, and artisan…

I agree, but would use Rust instead of Java. Imo Java is a horrendous language that’s basically legacy at this point.

JVM is very different than Java. Many Java devs use another JVM language such as scala, etc.

Rust is the future but not mainstream and still early. Can’t wait.