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

61–70 of 235 posts

Re: How boring should your team's codebases be

#61

Post by WJW »

Isamu wrote: post #48
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 have personally seen this within organizations. Certain leaders can appreciate the simple approach, but not others, because it doesn’t increase headcount. For other leadership types it is drama and increasing headcount that drive their careers. Also you the developer will get scant recognition for finding the simplest solution. That’s the kind of thing that doesn’t get appreciation up the management chain (usually.…

It's the same problem as preventing versus curing: the latter is much more expensive but much more flashy. In most companies the owners are the only ones who would care about doing things as efficiently as possible, but those are often also the most removed the line work. They get all their information filtered through middle managers who are competing with each other for their next promotion, so unspectacular news often doesn't make the cut for being passed upwards.

The main exception I've found so far is in making tools/systems for myself, since then it is easy to convince the owner about the benefits of simplicity and easy maintenance :)

Re: How boring should your team's codebases be

#62

Post by Winsaucerer »

omegalulw wrote: post #54
jiggawatts wrote: post #32

Earlier quoted context omitted.

Fantastically . The new one had "hand rolled cryptography", which should make you twitch uncontrollably if you know anything about security. The new application had, among other failings, hard-coded (unchangeable!) RSA keys used for communication channels. As in, all customers shared the same keys. I can't remember the exact specifics, but I swear at some point there was something like encrypted JSON in XML. Or was i…

> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. Confused here. Where were input validation checks in your implementation? How did you guard against SQL injection, etc?

Presumably they just did whatever the standard provided mechanisms for their SQL driver were (such as parameterised queries). User inputs text in a comment box, and you insert it into database using such a mechanism and it's safe.

And if you're using, for example, Go's templating library, then it automatically escapes everything in HTML templates unless you explicitly override this default behaviour.

Re: How boring should your team's codebases be

#63

Post by porker »

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…

Is it open source or only available to clients?

Re: How boring should your team's codebases be

#65

Post by mike_hock »

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…

By devoting time to code maintenance and refactoring in between features N and N+1 (or at least N+M). The code doesn't just magically go from 5-10 SQL queries to being completely unmaintainable without an ORM overnight. When and if it grows into that, you'll see it coming.

That doesn't work, of course, if you're not considered to be "working" unless you're hacking on a new feature right now that'll be deployable by the end of the week, but it seems like OP was allowed to develop in a sane way.

Re: How boring should your team's codebases be

#66

Post by thow232329 »

omegalulw wrote: post #54
jiggawatts wrote: post #32

Earlier quoted context omitted.

Fantastically . The new one had "hand rolled cryptography", which should make you twitch uncontrollably if you know anything about security. The new application had, among other failings, hard-coded (unchangeable!) RSA keys used for communication channels. As in, all customers shared the same keys. I can't remember the exact specifics, but I swear at some point there was something like encrypted JSON in XML. Or was i…

> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. Confused here. Where were input validation checks in your implementation? How did you guard against SQL injection, etc?

Just put the queries in procedures with parameters. Only store the procedure calls in your backend, disable arbitrary queries completely in your database permissions.

Re: How boring should your team's codebases be

#67

Post by tartoran »

hazz99 wrote: post #39
bdg wrote: post #18

Earlier quoted context omitted.

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

You should share the design principles!

And make a generic framework /s

Re: How boring should your team's codebases be

#68

Post by ratww »

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…

> 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 they can apply in the future. That's not to say they can't be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring code, but you're just ticking down a clock in a lot of cases.

In my experience that depends.

But the tinkering kind is often satisfied when they are able to tinker on their own code. Even (or especially!) if they're allowed to do it during working hours. But allowing engineers to literally hone their craft on the clock is something that is becoming rarer and rarer, unfortunately.

But I agree that a developer that refuses to admit failure of their experiments and wants to force their experiments on others is a problem, of course.

On the other hand, there's more to this job than coding, and a lot of people interested in "learning" will leave as soon as they find out there's nothing more about the problem-domain to learn.

Re: How boring should your team's codebases be

#69

Post by berkes »

rTX5CMRXIfFG wrote: post #47
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…

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.

Re: How boring should your team's codebases be

#70

Post by geokon »

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…

Isn't the moral of the story that you didn't charge for it correctly?

If you charged a fixed annual maintenance fee then you would have felt very clever having made a ton of money not having to do anything

Administrators would have also felt good that they had you as insurance of sorts bc the way things stand you make no money and can disappear at any moment

Post reply on HN