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

Ask HN: Are we overcomplicating software development?

news.ycombinator.com

Post reply on HN
Print view View original

201–210 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#201

Post by freehunter »

cookiecaper wrote: post #159
fsloth wrote: post #119

Earlier quoted context omitted.

I can't understand why people don't refer more often on Mr. Kays message. To be bluntly uncharitable and only half kidding, I do understand why consultants don't buy into it. Simpler systems that are less fragile mean less work.

Employees and management don't buy into it for the same reason that consultants don't buy into it. It means less work. Less opportunity to sound smart, seize control, and/or ego stroke. Less variety to break up the work-week's monotony.

Engineers don't buy into it because it's not cool. Complex systems are cool. It goes back to the phrase "well-oiled machine". Swiss clocks. People standing around a classic car with its hood open. A complex system of things working just perfectly is super cool, and fixing them when they break is a popular pastime.

Re: Ask HN: Are we overcomplicating software development?

#202

Post by jamesmccann »

mhotchen wrote: post #29

Many of the programmers I have worked with actually love complexity, despite trying to convince others (and most likely themselves) that they hate it. Advice tends to be cherrypicked to suit an agenda they already have (with your example on microservices, the vast amount of resources saying they're very difficult, should be driven by a monolith first approach, and solve a specific set of problems is largely brushed u…

> I think this is down to the sad truth that most developer roles offer very little challenge outside of learning a new stack.

This is a gem observation from this thread. In my own tech sphere the first thing developers are talking about with each other is the new x,y,z lib or framework they're using to accomplish something relatively banal. There's still a lot of work out there that really boils down to basic CRUD and reporting at the end of the day, and developers naturally begin to invent complexities on top of that CRUD to make the work interesting and challenging. I'm absolutely guilty of this first hand.

I've found personally it also doesn't help that past work on projects e.g. large Rails apps that were never architected well turn out to be such nightmares to work on. The memory of the end state of these projects lingers with developers as they move onto the next piece of work, and they're inclined to say "no that doesn't work" and pick up shiny new-tech to do the old job instead.

As a side analogy: most small business construction jobs, e.g. building a timber frame house, don't involve the builders arriving on site and are stumped by the challenge of how to put up the framing for the bedroom walls - there's also very little challenge in these projects, yet the reward is in the completion.

Re: Ask HN: Are we overcomplicating software development?

#203

Post by brwr »

brilliantcode wrote: post #179

1997: I created my first website on Netscape Navigator. I was 10. 2007: I created a textbook trading RoR web app. I was 20. 2017: I'm struggling to create my first front-end website on Chrome and I haven't decided on the back-end. I'm 30. The barrier to entry is indeed very high and no signs of slowing. I blame the explosion of low-interest capital from VC's fueling this fracturing.

Building a website doesn't have to be complicated. You build a Rails site 10 years ago. You probably used jQuery, if you used JavaScript at all. Why can't you do the same today?

The real problem here is that not enough developers understand that "just because you can, doesn't mean you should." Once more of us get a handle on that, life will be better.

Re: Ask HN: Are we overcomplicating software development?

#204

Post by brwr »

jamesmccann wrote: post #202
mhotchen wrote: post #29

Many of the programmers I have worked with actually love complexity, despite trying to convince others (and most likely themselves) that they hate it. Advice tends to be cherrypicked to suit an agenda they already have (with your example on microservices, the vast amount of resources saying they're very difficult, should be driven by a monolith first approach, and solve a specific set of problems is largely brushed u…

> I think this is down to the sad truth that most developer roles offer very little challenge outside of learning a new stack. This is a gem observation from this thread. In my own tech sphere the first thing developers are talking about with each other is the new x,y,z lib or framework they're using to accomplish something relatively banal. There's still a lot of work out there that really boils down to basic CRUD a…

> There's still a lot of work out there that really boils down to basic CRUD and reporting at the end of the day, and developers naturally begin to invent complexities on top of that CRUD to make the work interesting and challenging.

I'd go so far as to say that _most_ work today (at least in startups) is building CRUD apps. The technology has changed, but the work hasn't. Inside of building CRUD apps in Rails, we now build them in React.

Re: Ask HN: Are we overcomplicating software development?

#205

Post by jjuel »

reacharavindh wrote: post #31
PaulHoule wrote: post #9

Continuous integration is a good thing. Back in the bad old days you'd have three people working on parts of the system for 6 months and plan to snap them together in 2 weeks and it would take more like another 6 months. Agile methods are also useful. If you can't plan 2 weeks of work you can probably not plan 6 months. When agile methods harden into branded processes and where there is no consensus on the ground rul…

> Agile methods are also useful. If you can't plan 2 weeks of work you can probably not plan 6 months. Hmmm. I was just thinking the opposite yesterday. I'm a performance engineer working closely with two teams. One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions. I find the non agile team more productive, efficient and dare I say happy. The Agile based team makes me sit in on the…

The reason it is referred to as a stand up is because it is short and you stand up for the whole thing. An hour long meeting is just that an hour long meeting. Something is not working right in that agile situation which is why they aren't happy.

Re: Ask HN: Are we overcomplicating software development?

#206

Post by eropple »

nostrademons wrote: post #190
kornish wrote: post #187

Earlier quoted context omitted.

I mean, you _can_ if you organize your code such that you can. For example, Google's monorepo lets maintainers of a library find all internal usages and fix them. This is one of the benefits Dan Luu notes in http://danluu.com/monorepo/ .

I think he means that you can't force all teams that use your library to recompile and pickup the updated code, while if you deploy it as a service, you recompile and redeploy and everyone talking to your service gets the most up-to-date version. This is a real problem - I recall that Sanjay Ghemawat et al was working on it when I left Google, though I dunno if the solution they came up with is public yet. It's unlik…

> I think he means that you can't force all teams that use your library to recompile and pickup the updated code

Does your CI system not automatically build dependent artifacts--

> It's unlikely to seriously affect you unless you're Google-scale, though

--okay, whew. ;)

Re: Ask HN: Are we overcomplicating software development?

#207

Post by cgdub »

tunesmith wrote: post #183
nostrademons wrote: post #172

Earlier quoted context omitted.

You can get that benefit by dividing your system up into libraries with defined, documented, tested APIs. There's no need to introduce all the complexity and failure modes of distributed systems just to force good design. When you need to scale, then you can easily throw your libraries behind an RPC framework and call it microservices, but there's no need to pay that cost until you actually face that problem.

One caveat is that if you need to fix a bug in your library in an API-compatible way, you can't reach into all the codebases that are using your library. You can deploy a new version of the microservice, though.

If you need to change your microservice's API in a non-backwards compatible way, you have the exact same problem plus significant operational complexity.

Re: Ask HN: Are we overcomplicating software development?

#208

Post by [deleted] »

stcredzero wrote: post #175
SatvikBeri wrote: post #63

Many of these practices are popularized by Google/Facebook/Amazon but don't make sense for a company with 100 or even 1,000 people. I try to focus on whether a practice will solve a concrete problem we're facing. Switching from Hadoop to Spark was clearly a good idea for our team, even though it required learning a new stack, but there isn't a strong reason to switch to Flink or start using Haskell. Agile makes sense…

In short, ask the question "when is practice X useful?" instead of "is practice X a good idea?" Shorter version: Cost/benefit.

[deleted]

Re: Ask HN: Are we overcomplicating software development?

#209

Post by endgame »

FatalBaboon wrote: post #149
OJFord wrote: post #114

Earlier quoted context omitted.

> Microservices probably reduces the asymptotic cost of scaling but add a huge constant factor. If this were Medium , I'd highlight the hell out of that. That's so true, and so nicely, succinctly put - it ought to be the reply to end every argument about whether microservices are good or bad.

I believe, for small shops, the real benefit of microservices is the logic split that forces good design and reduces cognitive load. You reap the scaling benefits way later, if ever.

I think this is actually a failure in mainstream programming languages, which make it far too easy to reach across what's meant to be a defined subsystem boundary and meddle where you shouldn't.

Re: Ask HN: Are we overcomplicating software development?

#210

Post by cs02rm0 »

brwr wrote: post #191
OJFord wrote: post #114

Earlier quoted context omitted.

> Microservices probably reduces the asymptotic cost of scaling but add a huge constant factor. If this were Medium , I'd highlight the hell out of that. That's so true, and so nicely, succinctly put - it ought to be the reply to end every argument about whether microservices are good or bad.

At the last company I was at, our search microservice was fast (average response was well under 100ms) and it didn't crash once while I was there. At a larger company, this may not be an accomplishment. At a startup, this is the bees knees. Meanwhile, the rest of our codebase (a monolith) crashed every few days for one reason or another. We had an on-call rotation not because that's what you're supposed to do, but be…

I tend to start with a monolithic service.

Sooner or later you get a feel for which bits are becoming at least API stable and could run independently. That's when I split them out.

Do it too soon and you end up choosing the wrong boundaries and tying yourself up in knots, do it too late and your monolith can become a mess that's difficult to detach the pieces of.

Post reply on HN