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

71–80 of 235 posts

Re: How boring should your team's codebases be

#71

Post by Kwpolska »

photochemsyn wrote: post #59

The article mentions Architectural Design Records (ADR) which can be included as a folder in the git repo for the project, as a means of documenting the historical decisions that led to the project's current structure. Some of that seems overly complex or formalized (i.e. reinventing UML and all the problems that came with it), but having that history in some kind of constant format would likely help overcome any nov…

Where do you see the reinvention of UML within ADR? I wouldn't consider ADRs to be that; I'd say ADRs are meant for important decisions with important consequences, not a documentation of every single design choice and every single part of the project, as UML proponents would do.

Re: How boring should your team's codebases be

#72

Post by berkes »

porker wrote: post #56

Working on a not-yet-launched Web app, where the backend and frontend both use CQRS, and hoops are jumped through in the name of "purity", a more boring codebase would be appreciated. Velocity would be higher and new hires onboarded in less time.

But the two main questions are:

Will this boring alternative you crave, continue to yield that higher velocity, or will it grind to a halt? Boring doesn't have to be big-ball-of-mud, but the architectures you mention exist exactly to avoid big balls of mud from growing.

And second: does 'boring' really fit the requirements? There's only so much you can store in a simple RDBS, it will e.g. lack many intermediate states that your eventstream now does store. Maybe your use-case requires all this data?

Re: How boring should your team's codebases be

#73

Post by qaq »

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…

My experience is that requirements are almost orthogonal to what stack will be chosen. CTO going to a conference, tech lead being bored, founder having a friend who knows "shit", developers padding resume and so own impact the choice way more than actual requirements. 99.999% of the projects can be done using any mature lang + PostgreSQL or PostgreSQL compatible newSQL variant.

Re: How boring should your team's codebases be

#74

Post by meadsteve »

bdg wrote: post #18
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 t…

I still consider "no framework" as a novel choice (most of the time): https://blog.meadsteve.dev/team-work/2022/10/13/how-boring-s...

Re: How boring should your team's codebases be

#75

Post by ratww »

xcambar wrote: post #52
ratww wrote: post #50

Earlier quoted context omitted.

Nowhere in the grandparent's post says that it was a "walled garden", or even that it was closed source. The fact that only one person was needed doesn't mean there's only one person available. OP even said he worked for a company in a reply. The rationalisation automatically assumes that the grandparent is either incompetent or lying by omission, which is very uncharitable. Even if all those problems were true, if i…

Didn't say it was a walled garden. But management has its own ways and quirks I said it was possible that the situation was seen by mgmt as a walled garden. Seen as.

And I answered to that already on my second paragraph.

Taking the nuclear option after merely "seeing [something] as" risky without exhausting the much-cheaper remaining options is not "somewhat understandable, if not plain reasonable". And it's not "ways and quirks": it's incompetence at best or corruption at worst.

This kind of situation might be common, but it is not understandable nor reasonable.

Re: How boring should your team's codebases be

#76

Post by thow232329 »

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…

> A bored developer is an unhappy developer. Unhappy developers leave.

Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development?

Why do people think they can "play with new technologies" at work, which is wasting not only company money, but other people's time as well? It's so incredibly unprofessional, maybe it's time for software developers to grow up and start acting like adults in the workplace?

Re: How boring should your team's codebases be

#77

Post by meadsteve »

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…

If I was to rewrite my blogpost to fit your second sentence I would title it: "Please consider onboarding new staff as a need for your software". This is just another consideration when architecting. I absolutely will use cutting edge tools if they are needed. But we just need to think about it a little.

Re: How boring should your team's codebases be

#78

Post by berkes »

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…

Cannot agree more.

Some cases need a very boring CRUD setup, yet other will require distributed events passing around CRDTs.

I've worked on terrible projects built with boring tech that was perfect for simple CRUD, but where the project wasn't anything CRUD at all but parsed huge datasets of time series, combined with events and changesets. The 'boring tech' was such a bad fit, that the project ground to a halt, cost enormous budgets just to keep running, and was impossible to move forward.

Re: How boring should your team's codebases be

#79

Post by thow232329 »

sorokod wrote: post #49
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…

Developer can be a programmer or a software engineer ( my definitions). Programmers tend to be interested in cool new paradigms, tools, libraries, etc... Software engineers tend to be interested in delivering robust and correct features. Consequently they are more conservative. When companies hire, they should be clear what sort of developer they want. Programmer in a software engineering role will damage the code ba…

> Programmers tend to be interested in cool new paradigms, tools, libraries, etc...

Yeah well guess what, a company does not care one iota about what its employees personal interests are, or what they think is cool. And it shouldn't.

Re: How boring should your team's codebases be

#80

Post by andrewstuart »

meadsteve wrote: post #77
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…

If I was to rewrite my blogpost to fit your second sentence I would title it: "Please consider onboarding new staff as a need for your software". This is just another consideration when architecting. I absolutely will use cutting edge tools if they are needed. But we just need to think about it a little.

Indeed the availability of developers who know the tech stack is a key requirement that should be defined and assigned an importance level.

And if you’re working in a business building a modern web application then it’s extremely hard to imagine the stakeholders being happy with software developed using absolute lowest common denominator tools techniques and libraries, as advocated by the “boring software” movement.

Competitive advantage and the expectations of customers leads to the need to use modern tools techniques and libraries.

And in fact developers deserve these things too because they tend to make things easier more powerful and more reliable.

If the stakeholder who is paying for the project says “can we have an animated user education intro”, and you say “no because we use boring technologies and our developers might not understand how to use the animation APIs” them I think your job would be at risk pretty quick.

Post reply on HN