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

181–190 of 704 posts

Re: Software engineering topics I changed my mind on

#181

Post by closeparen »

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…

Do you mean “a monolith” or “the monolith?” The essential characteristic of monoliths is that you don’t get to start new ones for new projects.

The real skill of architecture is understanding everything your company has built before and finding the most graceful way to graft your new use case onto that. We get microservices proliferation because people don’t want to do this hard work.

Re: Software engineering topics I changed my mind on

#182

Post by woeirua »

lolinder wrote: post #101
sanderjd wrote: post #77

Earlier quoted context omitted.

But is their business model targeting hundreds of DAUs, or is it targeting millions of DAUs? It doesn't make sense to architect for an amount of usage that is too small to sustain the business. If the business model requires millions of users to be successful, you should build for millions of users, even if you only have hundreds at the present moment.

If you build for millions of users the way most devs do, your business will flounder before you finish. Facebook, Twitter, and Google all started simple and scaled only when it became necessary. If you want to do what they're doing, start by doing what they did. Don't skip to the microservices.

This is exactly right. Prove your business with the bare minimum tools required and then when you have enough paying customers go out and hire lots of engineers to figure out how to make it scale.

Re: Software engineering topics I changed my mind on

#183

Post by busterarm »

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…

> Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume, even if it’s not necessarily best for the company.

Probably nobody is using NoSQL for their resume. It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specifications.

When you start seeing engineers have difficulty reasoning about what the data model should be and nobody willing to commit to one, it's the clearest sign that organizationally things are sour and you need to start having very firm and precise conversations with product.

Re: Software engineering topics I changed my mind on

#185

Post by potta_coffee »

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…

I don't understand splitting an API into a bunch of "microservices" for scaling purposes. If all of the services are engaged for every request, they're not really scaled independently. You're just geographically isolating your code. It's still tightly coupled but now it has to communicate over http. Applications designed this way are flaming piles of garbage.

Re: Software engineering topics I changed my mind on

#186

Post by potta_coffee »

busterarm wrote: post #183
PragmaticPulp wrote: post #41

Earlier quoted context omitted.

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…

> Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume, even if it’s not necessarily best for the company. Probably nobody is using NoSQL for their resume. It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specific…

I'm facing this issue now. App is supposed to deliver to clients after this sprint - and the data model still isn't locked down. After arguing through about 10 hours worth of meetings this week, I think I need a new job.

Re: Software engineering topics I changed my mind on

#187

Post by eyelidlessness »

axaxs wrote: post #139
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…

Same here. Well everything except retrospectives, which I think are generally wasteful or better done in small pieces. Was afraid I wouldn't see something about overdoing microservices, but I think the monolith line covers it enough.

Retros should be like recall elections: always available, never scheduled, with a high but achievable barrier to entry and specific veto principles both ways. The point of a retrospective is "something big happened and we should learn and adapt". They shouldn't be routine, because most weeks/sprints, nothing that big happened (or something that big happened too frequently/urgently to wait for a calendar). They shouldn't be too hard to trigger, or you're never going to get one (or results from one). The best process for this is "shit goes down and you should make appropriate dedicated space for it".

Edit to add: I want to emphatically contradict my metaphor in one way, which is that retros should be exactly the opposite of a recall election in terms of identifying/naming/assigning fault. They should be about identifying good/bad outcomes and good/bad patterns, but not about pointing fingers at or casting aspersions on people.

Re: Software engineering topics I changed my mind on

#188

Post by busterarm »

specialist wrote: post #171
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…

I was on a team which used DynamoDB for their hottest data set. Which would trivially fit in RAM.

If I had a dollar for every senior engineer I've worked with who has never heard of SQLite...

Re: Software engineering topics I changed my mind on

#189

Post by tikhonj »

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…

A bit of a controversial take: if you need standups for this sort of communication, your work and work culture are way too siloed. With a flexible and collaborative culture, people will communicate these things naturally as part of doing their work. Issues that come up will get addressed as needed when they come up. If something is important, why would you wait for tomorrow's standup? If something isn't important, why are you dedicating an inflexible daily meeting to talking about it?

If your team is having the sort of communication problems standups are supposed to solve, it's a symptom of a deeper issue and standups are a bandaid solution. If your team already works collaboratively, standups are pure overhead at best and actively counterproductive at worst. It's easy to get into the bad habit of waiting for a standup to bring up important issues, which loses time and context. Worse yet, chances are the standup has too many people and not enough time to discuss anything in detail—I've seen so many standups where any actually useful conversation would be caught, stopped and moved to a different venue. You end up with a pro forma meeting where most of the information isn't useful to most of the attendees, but still breaks up people's schedules and focus.

In my experience, an emphasis on standups goes hand-in-hand with a view of engineering work as a ticket factory: individuals get a ticket off the queue, work just on that, get it done as soon as possible and pick up another ticket. I think that correlation is not a coincidence.

Re: Software engineering topics I changed my mind on

#190

Post by potta_coffee »

specialist wrote: post #178
nitrogen wrote: post #132

Earlier quoted context omitted.

If I were an evil tech giant, I would open source a bunch of libraries that require significantly more effort to use than necessary, and pitch them as the One True Solution. Just to slow my competitors down.

I had a nemesis who would steal all my ideas. So I bought all the XP books, dog eared them, left them on my desk. My team nearly mutinied. I asked them to wait and see. Two weeks later, nemesis announced his team was all in for XP, Agile, pair programming, etc. They never recovered, didn't make another release. I tossed my copies, unread.

I'm praying this story is true, very funny.
Post reply on HN