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

81–90 of 235 posts

Re: How boring should your team's codebases be

#81

Post by iLoveOncall »

thow232329 wrote: post #76
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 i…

You must have only ever done minimum-wage unqualified work to be saying that.

Everyone wants a job that they love, and that requires having fun at work. People leave jobs, any kind of jobs, because they're bored and not having fun.

Re: How boring should your team's codebases be

#83

Post by sorokod »

thow232329 wrote: post #79
sorokod wrote: post #49

Earlier quoted context omitted.

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.

That makes no sense, it's just a question of role-candidate fit. Why would a company not care?

Re: How boring should your team's codebases be

#84

Post by thow232329 »

iLoveOncall wrote: post #81
thow232329 wrote: post #76

Earlier quoted context omitted.

> 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 i…

You must have only ever done minimum-wage unqualified work to be saying that. Everyone wants a job that they love, and that requires having fun at work. People leave jobs, any kind of jobs, because they're bored and not having fun.

Do you really think they take into account in other fields, that their doctors, lawyers, finance people etc should "Have fun" and change their decisions away from what is straight forward solutions, because of that? They don't. Only in software.

I had a heated argument with a colleague who was fighting to use MongoDB for a new project, even though there was a company wide decision by upper management to NOT use MongoDB in the company. And his only justification was that "he took this job to play around with new technology". If I hade the power to, I would have fired him on the spot, because clearly he had misunderstood the very basics of the employment contract he had signed.

Re: How boring should your team's codebases be

#85

Post by anyonecancode »

Another aspect of "boring" is note is that ideally the implementation is boring, as in not surprising. Currently working on a codebase that's a pretty standard frontend stack, but omg is it not boring. I wish it was. Instead, it's exciting as in "this function claims to remove items based on a filter, but actually it does the opposite."

I might go so far as to argue that being boring (ie predictable and consistent) in your implementation is more important than being boring in your tech stack.

Re: How boring should your team's codebases be

#86

Post by sethammons »

pwm wrote: post #8

It feels like there is an article like this every other week. They reflect the same generic view which is broadly true yet I think is not very useful as an advice. In a highly creative field like software competitive advantage often outweighs comparative disadvantage. In other words it might very well be the case that a company that takes a chance on something unusual with a higher opportunity cost will outcompete co…

Reminds me of Sendgrid. At the beginning, they were faced with using an off-the-shelf MTA (mail transfer agent) or writing their own. As a core competency, writing their own turned out to be a major competitive advantage.

Re: How boring should your team's codebases be

#87

Post by ratww »

patrickthebold wrote: post #53
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…

It sounds like your project ended up working out well (ignoring the replacement). But one thing that would be hard for me when starting a project like this: How do you know that over time it won't grow into something terribly unmaintainable? You don't have an ORM, but then perhaps over time you re-implement most of the functionality of an ORM, and now new people need to learn that. Of course, you can start with out o…

You either start with or without an ORM, depending on your assessment of whether the project is gonna need one.

If you start without one, you still have to partition your code well enough so that retrofitting one doesn't cause a huge mess. Basically keep your "raw SQL queries" in a centralised place (file or folder), rather than strewn together in controllers/views/services. And you should do exactly the same if you use an ORM. Isolate the fuck out of it and make it "easily removable" or "easily replaceable".

Also keep the "effects" of your ORM or your non-ORM away from those other parts too: your controllers, views and services should be totally agnostic to whatever you're using in the data layer. When you add subtle coupling you lose the possibility of changing it, but it also makes your project less maintainable.

This is easier said than done: in dynamic languages or with structural typing like Typescript it's very easy: it's all objects, anyway, so ORM or no ORM it's the same. In stricter languages like Java it might lead to lots of intermediate data structures which are verbose and causes problems in itself. Or the middle ground: use primitives (lists and maps) rather than classes and objects, although ORMs like Hibernate will make things difficult for you, since they're not too flexible about how they're used and their types tend to "creep" all over your project.

-

Most unmaintainable projects don't become unmaintainable because people "forgot to prepare". They become unmaintainable because people assumed everything is permanent, so there's no penalty to using everything-everywhere. So there are "traces" of the ORM in the controllers and views, the serialisation library and serialisation code is called in models in services as a "quick hack", the authorisation library is called from everywhere because why not. You quickly lose the ability to easily reason about code.

The same applies other areas. I could make a treatise of how game developers love sticking keyboard-reading code absolutely everywhere in the codebase.

Re: How boring should your team's codebases be

#88

Post by rTX5CMRXIfFG »

berkes wrote: post #69
rTX5CMRXIfFG wrote: post #47

Earlier quoted context omitted.

Whether you code is declarative/imperative or whether it has all the hot new packages as featured in HN has very little to do with making software products "competitive" or having "comparative advantage". It's always going to be about whether the product is solving the customer's problem more conveniently than the competition does.

...and whether it will continue to do so. Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.

Yes, but whether it will continue to do so, once again, has little if nothing to do with the tech stack.

I think you’re getting at the point about how tech debt can bog down product development and the progress of a business, and I fully agree that it should be avoided, but tech debt avoidance is hardly related to the tech stack or programming style as much as it is to architectural decisions. And, when you’re looking at longer shelf life for your code, then the article becomes justified in making your codebases as boring as possible because thn you’d like to employ only the patterns that have truly stood the test of time, instead of polluting your code with novel approaches.

Re: How boring should your team's codebases be

#89

Post by nordsieck »

berkes wrote: post #69
rTX5CMRXIfFG wrote: post #47

Earlier quoted context omitted.

Whether you code is declarative/imperative or whether it has all the hot new packages as featured in HN has very little to do with making software products "competitive" or having "comparative advantage". It's always going to be about whether the product is solving the customer's problem more conveniently than the competition does.

...and whether it will continue to do so. Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.

> Maintenance over long time is hard, requires experience, architectural choices, risk analysis, balancing tradeoffs, and obviously a disciplined team.

Exactly. That's the reason Facebook gave for adopting Reason (OCaml).

Re: How boring should your team's codebases be

#90

Post by calvinmorrison »

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…

we don't have simplicity because people are inept. I would trust you to write a small CRUD php database without any security issues, however, the next goon that comes along and jams in a bunch of $id = $GET[id]; insert into where $is; and you have a major security issue

Frameworks exist so you don't roll your own stupidity into a bigger problem.

Post reply on HN