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

91–100 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#91

Post by btilly »

There is a lot of BS in software development. Always has been, probably always will. Everything is a tradeoff. Understand the tradeoffs that you are taking, listen for the principles, and you can ignore most of the noise.

On to your questions.

1) Choose languages that developers are familiar with, not the best tool for the job

How familiar developers are with the language is part of what determines what is best for the job at hand in a real organization.

It isn't the only factor. For example if you're doing something new (to you), doing it in the language that you find wherever you are learning it from makes sense because you'll be more likely to get help through complex issues.

That said, do not underestimate the support advantage of using a consistent toolset that everyone understands.

2) Avoid microservices where possible, the operational cost considering devops is just immense

See https://martinfowler.com/bliki/MonolithFirst.html for emphatic support.

If you go the microservices route, think ahead about predictable challenges with debugging failures 3 calls deep, and plan in advance for monitoring etc tooling to solve it.

3) Advanced reliability / redundancy even in critical systems ironically seems to causes more downtime than it prevents due to the introduction of complexity to dev & devops.

As the old saying goes, DBAs are the primary cause of databases going down. Reliability is not something that you just plaster on top blindly. An systems are good at finding failure modes that you never thought of.

4) Continuous integration seems to be a plaster on the problem of complex devops introduced by microservices.

No. Continuous integration is actually a fix for developers checking in clearly broken code and then nobody discovering it later. That said, it does little good without a number of other good practices that are easy to ignore.

5) Agile "methodology" when used as anything but a tool to solve specific, discrete, communications issues is really problematic

This one generated the most discussion. I would say sort of, but you went too far.

Any set of poorly understood principles, dogmatically applied, is going to work out badly. Agile is actually a set of good principles that addressed a major problem in the common wisdom back in the day. But the pendulum has swung and it is often applied poorly.

That said, there are other problems in organizations which are prone to, "poorly understood principles, dogmatically applied"...

Re: Ask HN: Are we overcomplicating software development?

#92

Post by RandomOpinion »

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…

> I can visibly tell the devs walking out of the room spend more time worrying about "velocity" and "organisation of work" than the money making work that needs to be done. It almost feels like the agile process gives them "one more job" of picking the doable things from the list of stuff that needs to be done so they look better than their peers with better velocity.

Classic symptom of managers using agile as a (micro)management tool. Velocity, burndown charts, etc. are meant to be used by the team as a self-calibration tool. Managers do not get a say in what they think the velocity should be, either for the team or for individuals. If they do so, they create an incentive (let's be blunt, an overwhelming incentive) for the team/individuals to game them and that way lies madness.

(As an aside, the best response I've ever seen to this type of dysfunction is a team who simply decided to retcon the charts on the fly to make the work committed to match the work done. Management was happy that the burndown chart was right on target, developers were free to be fully productive instead of worrying about what their velocity looked like; it was a win-win solution all around.)

Re: Ask HN: Are we overcomplicating software development?

#93

Post by acbabis »

reacharavindh wrote: post #54
WalterSear wrote: post #43

Earlier quoted context omitted.

It doesn't sound like the 'Agile' team is doing standups right. There are either too many people in the room, or people are talking too much, and probably about the wrong things. And, if they are doing standups wrong, I question how much else they are cargo-culting.

Yes, everyone in there knows that scrum meetings should be short, but somehow those meetings take long, because everyone thinks their questions needs answers and their dependabcies definitely must be resolved.. so, an hour it goes.

Our meeting format was for each person to say a) What they worked on, b) What they were about to work on, and c) If they needed help with anything. Our rule was that you could ask for help as long as you were just scheduling a time to meet after the stand-up. It worked really, really well.

Then we got a new scrum master whose desired format was to talk about each item on the Kanban board each day, even the ones that weren't being worked on.

Re: Ask HN: Are we overcomplicating software development?

#95

Post by blub »

reacharavindh wrote: post #54
WalterSear wrote: post #43

Earlier quoted context omitted.

It doesn't sound like the 'Agile' team is doing standups right. There are either too many people in the room, or people are talking too much, and probably about the wrong things. And, if they are doing standups wrong, I question how much else they are cargo-culting.

Yes, everyone in there knows that scrum meetings should be short, but somehow those meetings take long, because everyone thinks their questions needs answers and their dependabcies definitely must be resolved.. so, an hour it goes.

This is really bad and a major failure on the part of the scrum master. The point of this meeting is to help the team sync on what they are doing and what they plan to do.

It should take 10m at most. Any issues (blockers, dependencies, etc) should be taken to separate ad-hoc discussions to let the team get back to work.

Re: Ask HN: Are we overcomplicating software development?

#96

Post by ChuckMcM »

Yes we are over complicating it, but that it primarily about trying to take what is essentially an artistic process and turning it into a regimented process (a known hard problem).

Rob Gingell at Sun stated it as a form of uncertainty principal. He said, "You can know what features are in a release or when the release will ship, but not both." It captured the challenge of aspirational feature development where someone says "we have to have feature X" and so you send a bunch of smart engineers off to build it but there is no process by which you can start with an empty main function and build it step by step into feature X.

That said, it got worse when we separated the user interface from the product (browser / webserver). And you're rants about microservices and continuous integration are really about releases, delivery, and QA. (the 'delivery time' of Gingell's law above).

These are complexities introduced by delivery capabilities that enable different constructions. The story on HN a few days about about the JS graphics library is a good example of that. Instead of linking against a library on your computer to deliver your application with graphics, we have the capability of attaching to a web service with a browser and assembling on demand the set of APIs and functions needed for that combination of client browser / OS. Its a great capability but to pull it off requires more moving parts.

Re: Ask HN: Are we overcomplicating software development?

#97

Post by protomyth »

At this point, I think a lot of software development problems are complicated because we are building on a platform that really isn't designed for the apps we want. The web makes everything a lot more frustrating and hard. It complicates testing and requires a lot more process than is justified by the apps. At some point the era of the web will come to and end then maybe we will get a net gui (probably based on messaging) that will hopefully take the lessons of the web to heart.

Re: Ask HN: Are we overcomplicating software development?

#99

Post by Oras »

UK-AL wrote: post #53
majewsky wrote: post #26

1) False dichotomy. Developer familiarity is one of the most important metrics for choosing "the best tool for the job". 2) Conway's Law applies in reverse here: If your organization consists of a lot of rather disjoint teams, then microservices can be quite beneficial because each team can deploy independently. If you're one cohesive team, there is not much benefit, only cost. 3) Depends. If you have a well-designed…

I find microservices can help in just keep everything small and focused. I know you can do this with a monolith. But having a process boundary really enforces it.

until you mix it with other legacy part of the system then it will be pain in the neck

Re: Ask HN: Are we overcomplicating software development?

#100

Post by outworlder »

> Avoid microservices where possible, the operational cost considering devops is just immense

Is it, though? There's more complexity due to more moving parts, sure. But being able to solve issues by just issuing a "scale" kubernetes command in the CLI is priceless. As is killing pods with no drama.

However, what are we talking about here? Small business ecommerce? Your monolithic app is probably going to work just fine.

> Advanced reliability / redundancy even in critical systems ironically seems to causes more downtime than it prevents due to the introduction of complexity to dev & devops.

Systems can and will fail. If you can eat the downtime, by all means forget about that.

> Continuous integration seems to be a plaster on the problem of complex devops introduced by microservices.

Could you stop singling-out microservices? We have deployed continuous integration with old school rails apps before and it was extremely valuable.

Agree about agile.

Post reply on HN