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

201–210 of 235 posts

Re: How boring should your team's codebases be

#201

Post by baby »

Kwpolska wrote: post #5

Boring and battle-tested, not antiquated, but also not some fancy new overhyped thing. I've worked in a project with a very fancy tech stack: fancy language, fancy data stores, fancy API style. Hiring was hard (not many people know $fancyLang, most people were internal transfers working with something boring like Java), $fancyDataStore1 had weird failure conditions that made it difficult to scale, $fancyDataStore2 ha…

> But for datastores, relational databases are always the way to go

That seems like a pretty controversial statement

Re: How boring should your team's codebases be

#202

Post by pkrumins »

tchaffee wrote: post #172
pkrumins wrote: post #164

Earlier quoted context omitted.

There are no security issues.

That's a laughable claim. https://www.cvedetails.com/vulnerability-list.php?vendor_id=... And just 10 days ago: Code security company SonarSource today published details on a severe vulnerability impacting Packagist, which could have been abused to mount supply chain attacks targeting the PHP community. https://www.securityweek.com/critical-packagist-vulnerabilit... And this source says PHP is the 2nd most vulnerable…

Lulz

Re: How boring should your team's codebases be

#203

Post by grey-area »

Philip-J-Fry wrote: post #153
grey-area wrote: post #119

Earlier quoted context omitted.

> A bored developer is an unhappy developer 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. > Your good developers are…

>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. That only holds true so long as the developer believes the end result…

> But a good developer is always tinkering and experimenting.

I strongly disagree. Developers build stuff, that's the job, not tinkering. Sure, everyone loves to tinker (most people love it far too much), and sometimes that is productive in the end, but it's the sort of thing you do in your spare time or quiet moments, not something you should see as central to the job - central to the job is turning ideas into reality, delivering.

> But if doing things in your code base is tedious, boring and eats up dev time

This is not what people mean by 'boring' software, they mean software they don't have to think about much, and when they do think about they understand instantly. Boring in a good way - as simple as it can be, hiding complexity with the right abstractions.

I'm afraid I don't know the sort of code-base you're talking about, but if velocity slows down, it's a sign of problems. If you're talking about a boring mess, you're probably talking about a code base I would call interesting (in a bad way). Boring is not a mess, boring is stuff that just works, with few hidden gotchas and abstractions and a simple call tree.

Re: How boring should your team's codebases be

#204

Post by jiggawatts »

osigurdson wrote: post #103
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…

>> deployed to over 2000 locations Were there 2000 independent systems / SQL server instances running or just one? 2K separate deployments to manage (with 1K users each), does sound a little scary. Of course, perhaps that is not what is going on at all.

I wasn’t clear in my description, unfortunately.

This was a multi-tenant centrally hosted application. There were 2000 sites served, each with kiosk PCs and some associated special-purpose hardware.

The actual application code ran in just four virtual machines in two data centres.

No templates, no Terraform, no microservices, etc…

Just vanilla ASP.NET on IIS with SQL Server as the back end.

The efficiency stemmed from having a single consolidated schema for all tenants with a tenant ID as a prefix to every primary key.

Shared tables (reference data) simply didn’t have a prefix.

The vendor product that replaced this was not multi-tenant in this sense. They deployed a database-per-tenant, and lots of application servers. Not one per tenant, but something like one per ten, so two hundred large virtual machines running twenty instances of their app.

Multiply the above for HA and non-production. The end result was something like a thousand virtual machines that took several racks of tin to host.

Management of the new system took serious automation, template disk image builds, etc…

The repetition of the reference data bloated the database from 50GB to terabytes.

It “worked” but it was very expensive, slow, and difficult to maintain. It took them several years to upgrade the database engine, for example.

That task for my version was a single after-hours change. Backup or rollback was about an hour, simply because the data volume was so much lower.

The simplicity in my solution stemmed from a type of mechanical sympathy. I tailored the app to the customer’s specific style of multi-tenant central hosting, which made it very efficient.

Re: How boring should your team's codebases be

#205

Post by Cwizard »

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.

Care to explain why? I get that there are some horrible Java projects and libraries that have really ballooned in complexity over the years but I still see Java itself as one of the better languages. Especially for corporate work.

Re: How boring should your team's codebases be

#206

Post by throwaway5959 »

thow232329 wrote: post #182
tchaffee wrote: post #132

Earlier quoted context omitted.

> Why do people think they can "play with new technologies" at work The same reason software developer salaries are so high. Supply and demand. Companies will do back flips to attract and keep software engineering talent. > which is wasting not only company money Some of the best cost saving solutions I've come up with in my career have been thanks to "playing" with new technology. It's the opposite of wasting compan…

> There is nothing childish about loving your work, having fun while doing it Expecting to love your work and have fun doing it, is incredibly naive, yes. > bringing that attitude to work. It's infectious and great for company morale. Exactly the opposite, relationships become incredibly strained with the rest of the company and there is a lot of frustration when dealing with the software department. Developers are d…

There are a lot of reasons to rewrite an existing system. Maybe the existing system is built in a language that is impossible to hire for in the area you’re in. Maybe the test coverage is awful and the code makes it very difficult to write tests. Your tone is frankly pretty condescending and the only reasonable answer to when it makes sense to do a rewrite is “it depends”.

Re: How boring should your team's codebases be

#207

Post by vegetablepotpie »

malyk wrote: post #126
grey-area wrote: post #119

Earlier quoted context omitted.

> A bored developer is an unhappy developer 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. > Your good developers are…

I agree 100% with your first comment. The best developers care about the impact their work has above all else. Sure, they might prefer Ruby, or Golang, or whatever, but at the end of the day the results are what they are after. However, somehow we’ve created a world where the tools and techniques matter more than the output. I have no idea why this is, but I see it every day where engineers want to refactor code and…

I think it’s a combination of 4 things:

1. Everyone is trying to make a name for themselves,

2. everyone is trying to maximize their income,

3. most people want to focus on practicing the mechanics of their profession rather than exercise real understanding, and

4. Most people don’t understand the global problem space they’re in

Re: How boring should your team's codebases be

#208

Post by jameshart »

osigurdson wrote: post #103
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…

>> deployed to over 2000 locations Were there 2000 independent systems / SQL server instances running or just one? 2K separate deployments to manage (with 1K users each), does sound a little scary. Of course, perhaps that is not what is going on at all.

2000 SQL server licenses sounds terrifying

Re: How boring should your team's codebases be

#209

Post by therealdrag0 »

baby wrote: post #198
andrewstuart wrote: post #55

I disagree with the fundamental premise put forward here. Software should be written to meet specific needs. And those needs should be defined. And it’s likely a software project will have many tens of needs defined. And amongst all those needs it will become clear what technologies fit the needs. A blanket statement like “choose boring technology” only fits projects where the project needs result in that outcome. Sa…

Couldn’t disagree more. I think you’re missing the point. You can use boring technology (Golang) and simple patterns (no generics) and build something that works, and is readable, and maintainable, and secure as a consequence of this. I’ve seen this again and again. Then you can expand your code as business needs change, but making your code flexible from the start is in the same basket as over engineering and premat…

Your example and conclusion aren’t a good match IMO. Choosing a restrictive language is not something you can easily pivot from later when you need more flexibility. It’s a huge commitment, so making the right choice for the future is not premature.

Re: How boring should your team's codebases be

#210

Post by therealdrag0 »

klysm wrote: post #131
pharmakom wrote: post #82

Perhaps a controversial take: it’s difficult to write boring code in the common boring languages because they are not powerful enough to express the problem domain without accidental complexity.

I agree with this. The biggest thing that’s missing for me is sealed sum types. We’re getting there but progress is slow.

Does Scala have that?
Post reply on HN