Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

491–500 of 704 posts

Re: Software engineering topics I changed my mind on

#491

Post by KaoruAoiShiho »

PragmaticPulp wrote: post #41
cbdumas wrote: post #13

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything . I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservi…

As an engineer-turned-manager, I spend a lot of time asking engineers how we can simplify their ambitious plans. Often it’s as simple as asking “What would we give up by using a monolith here instead of microservices?” Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans. Frankly, many engineers want to use the latest t…

To me this is a little bit weird, because while OP is totally correct in that monoliths are totally fine too when it's the best tool for the job, the default should still be microservices. It's not really harder to use once you have the practice in place and advantages will usually be quite visible in time. But of course there are times when there are great monoliths you can just use and you should use them.

Re: Software engineering topics I changed my mind on

#492

Post by silentsea90 »

thequux wrote: post #473

> Clever code isn't usually good code. Clarity trumps all other concerns. Generally this is true, but with the caveat that what actually matters is 90th percentile (or maybe even 99th percentile) complexity. If you have a choice between spreading low-grade complexity across the codebase or having one module that is nearly incomprehensible but that provides an abstraction that makes the rest of the code very simple, t…

Interesting problem. I'm not convinced but don't have strong opinions on this. I feel nobody wants to touch the high grade complexity code so it would rot. Ultimately, reading code dominates writing it, so having low grade complexity spread around seems better as the bar for reading is lower

Re: Software engineering topics I changed my mind on

#494

Post by skohan »

thequux wrote: post #473

> Clever code isn't usually good code. Clarity trumps all other concerns. Generally this is true, but with the caveat that what actually matters is 90th percentile (or maybe even 99th percentile) complexity. If you have a choice between spreading low-grade complexity across the codebase or having one module that is nearly incomprehensible but that provides an abstraction that makes the rest of the code very simple, t…

If I understand what you're talking about, I tend to disagree - I've had a bad experience in general with "pure abstraction" layers in projects. It sometimes seems like a good idea to have this "magic" component which automates everything and takes care of all the hard stuff, but in practice it creates a whole host of problems.

For instance, maybe it works at first, and then your requirements change in a way that doesn't fit the abstraction. Now you can't make local changes, you've got to change this super complicated abstraction layer, and suddenly it requires changes all over the place in completely unrelated components, because you had to add an argument to `super_general_magic_function_that_is_used_everywhere()`.

Also things like this tend to make code super hard to trace. Instead of stepping through your functions, now all your tasks are running through some generic scheduler or something, which is there because somebody had the idea that if you ever need to run your code on a Hadoop cluster this would help, even though your code has only ever been run on a Raspberry Pi.

Re: Software engineering topics I changed my mind on

#495

Post by martinald »

Joeri wrote: post #340
martinald wrote: post #37

Earlier quoted context omitted.

The problem with NoSQL is that your simple model inevitably becomes more complex over time and then it doesn't work anymore. Over the past decade I've realised using a RDBMS is the right call basically 100% of the time. Now pgsql has jsonb column types that work great, I cannot see why you would ever use a NoSQL DB, unless you are working at such crazy scale postgres wouldn't work. In 99.999% of cases people are not.

We just ported a system that kept large amounts of data in postgres jsonb columns over to mongodb. The jsonb column approach worked fine until we scaled it beyond a certain point, and then it was an unending source of performance bottlenecks. The mongodb version is much faster. In retrospect we should have gone with mongo from the start, but postgres was chosen because in 99% of circumstances it is good enough. It wa…

Yep, I agree there are cases where mongodb will perform better. However, many use cases also require joins and the other goodness that relations provide.

So really the use case for mongo etc is 'very high performance requirements' AND 'does not require relations'.

Many projects may be ok with just one of those. But very few require meet both of those constraints.

FWIW I've seen many cases which are sort of the opposite: great performance with mongodb, but then because of the lack of relations for a reporting feature (for example) performance completely plummets due to horrible hacks being done to query the data model that doesn't work with the schema, eventually requiring a rewrite to RDBMS. I would guess that this is much more common.

Re: Software engineering topics I changed my mind on

#497

Post by tejohnso »

lillecarl wrote: post #487
mabbo wrote: post #480

Earlier quoted context omitted.

If you don't see the value in having a diverse workforce and company at any scale, I doubt anything I can say will convince you. There's enough research out there showing the benefits, if you're willing to take just a few minutes to go look for it. Your competitors will read that research. edit: carlhjerpe is right- this is super condescending. Downvote me.

That's very condescending. I'm asking because I don't see why my colleagues would be any better than they are if they were black, brown, jewish, muslim, female in various combinations, maybe I hold my colleaguestoo high?

I don't think it's a personal slight against your colleagues. It's not that they would be better. They're fine.

I think the idea is that the company overall would be better with a more diverse set of thought patterns, opinions, and experiences contributing to its success. One way to achieve this is through diversity of identity, gender, or culture.

Re: Software engineering topics I changed my mind on

#498

Post by skohan »

windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

I agree the list is very good list in general. My point of disagreement is:

> Software architecture probably matters more than anything else The devil is in the details here, but the more I program, the less I feel that "software architecture", at least as it is often discussed, is actually not important and often actively harmful.

The architecture driven approach takes the assumption that the "correct" shape of a program should fit into a pre-defined abstraction, like MVP, MVVM (or god forbid atrocities like VIPER) etc which has been delivered to us on a golden tablet, and our job as programers is to figure out how to map our problem onto that structure. In my experience, the better approach is almost always to identify your inputs and desired outputs, and to build up abstractions as needed, on a "just-in-time" basis. The other approach almost always leads to unnecessary complexity, and fighting with abstractions.

The author also mentions SOLID - like architecture patterns, I'm always a bit suspect of true-isms about what makes good software, especially when they come in the form of acronyms. I generally agree that the principals in SOLID are sensible considerations to keep in mind when making software, but for instance is the Liskov Substitution Principal really one of the five most important principals for software design, or is it in there because they needed something starting with "L"?

After 10 years of programming, the biggest takeaway for me has been that the function of a program (correctness, performance) is degrees of magnitude more important than its form. "Code quality" is important to the extent that it helps you get to a better functioning program (which can be quite a bit) but that's where its utility ends. Obsessing over design patterns and chasing acronyms is great if you want to spend most of your time debating with colleages about how the source code should look, but the benefits are just not reality-based most of the time.

Re: Software engineering topics I changed my mind on

#499

Post by jawns »

xxs wrote: post #407
Falkon1313 wrote: post #387

Earlier quoted context omitted.

I think that depends on what you're doing with the data. If you're just grabbing one thing and working with it, or looping through and processing everything, maybe not. But if you're doing more complicated query-like stuff, especially if you want to allow for queries you haven't thought of yet, then the DB might be useful. Sometimes a hybrid of query-able metadata in a DB along with plain old data files is good. That…

>doing more complicated query-like stuff That's some kind of fallacy - standard datastructures would totally destroy any-sql-alike thing, if it comes to performance (and memory footprint). I guess it does depend on where the background comes when it comes to convenience - or how people tend to see their data. However like I said - for close to 3 decades I have not seen a single reason to do so. On the contrary I've h…

It's easier to find devs who know basic SQL than it is to find devs who know pandas or whatever your language specific SQL-like library is. And the more complicated the queries, the more the gulf widens.

Re: Software engineering topics I changed my mind on

#500

Post by user5994461 »

>>> Typed languages are better when you're working on a team of people with various experience levels

I picked up the opposite qualm after working in a multi million line codebase in python, that goes back almost 2 decades in a large bank.

Dynamically typed languages actually work, at all scale.

Statically typed languages are good for simple types (int/string) but they're catastrophic for complex types (dict, map, database tables, enum, nullable/optional). The guarantee it gives you on simple code is great but the convolution it forces you to go through for more complex data is equally horrific.

Post reply on HN