Live data from Hacker News

Ask HN: Are we overcomplicating software development?

news.ycombinator.com

51–60 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#51
It never seems complicated when I am doing my own side work for some reason. There are no design meetings, no hours tracking, no arguments on best practices, no scrum, no testing frameworks, dev ops, etc. I do use git and minimally create bash scripts to simplify repetitive tasks for deployment but its just a huge contrast to working in teams where something simple takes about 50 times longer.

I think keeping things as simple as possible and always going for that goal will increase velocity overall. Everything should be subject to scrutiny for promoting productivity and open to modification or removal. I know there is a balance where you have to increase complexity in a team environment but keeping friction as low as possible in terms of process and intellectual weight couldn't hurt.

The most productive place I've seen so far is a huge athletic brand I worked for where they kept teams at max 5 people in mini projects. This forced the idea of low overhead and kept the scale of management needed small. The worst place I worked for in terms of unnecessary complexity is a well known host, although it is the best place to work in terms of people, hired offshore that has a one-size fits all mentality and layered in as much shit as possible to slow down development to a mud crawl. I don't buy into process over productivity.

Re: Ask HN: Are we overcomplicating software development?

#52

Earlier quoted context omitted.

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

Is everything else between these two groups completely equal? I seriously doubt it is, in which case I don't think it's fair to make any conclusions that hold weight. This is one of the problems I have with these sorts of things. My company went Agile about two years ago, and lots of people like to rant about how much better everything is now and how much more productive we all are because of it. Except we actually h…

Sorry, I should have made it clearer. I ranted likea personal thought than a definitive statement. The teams work on different projects. The diversity and experience of its members are different. They are not strictly comparable.

But, looking at both teams from above, it feels like the non agile team is very simple and it works. The agile team is more complicated and works only on paper.

Re: Ask HN: Are we overcomplicating software development?

#53

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.

Re: Ask HN: Are we overcomplicating software development?

#54

Earlier quoted context omitted.

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

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.

Re: Ask HN: Are we overcomplicating software development?

#55

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…

One doing Agile and the other basing on wikis and Adhoc in-person whiteboard discussions.

The ad-hoc approach also sounds quite agile (at least with a small 'a'). It's certainly closer to Agile than to Waterfall, assuming they didn't do a big design up front before writing any code.

I think the ad-hoc agile approach can work very well with a good team. But Scrum fans always seem to warn against cherry-picking just the bits of Scrum you like and not using the whole process.

Re: Ask HN: Are we overcomplicating software development?

#57

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…

A "1 hour daily standup" is not agile. The point of a stand-up is just that... everyone can stand because the meeting is so short. Ideally 15 minutes max.

Re: Ask HN: Are we overcomplicating software development?

#58
I think you wanted to say: "Are we simplifying things in software development?" All of the points you have made are actually simplifications of what might be the optimal solution.

Imagine the solution space as some multidimensional space where there is somewhere an optimal solution. The dimensions include the habits of your programmers, the problem you are trying to solve, and the phase of the moon. Microservices, a special form of redundancy, continuous integration, agile development are all extreme solutions to specific problems. Solutions which are extreme in that they are somewhere in the corner of your multidimensional solution space.

They are popular because they are radical in the way they conceptualize the shape of the problem and attempt to solve it. Therefore they seem like optimal solutions at first glance when really they only apply really well to specific toy models.

Take e.g. microservices. Yes, it's really nice if you can split up your big problem into small problems and define nice and clean interfaces. But it becomes a liability if you need too much communication between the services, up until the point where you merge your microservices back together in order to take advantage of using shared memory.

Don't believe any claims that there is a categorically better way to do everything. Most often, when you see an article about something like that, it is "proved" by showing it solves a toy model very well. But actual problems are rarely like toy models. Therefore the optimal solution to an actual problem is never a definite answer from one of the "simplified corner case scenarios" but it is actually just as complex as the problem you are trying to solve.

Re: Ask HN: Are we overcomplicating software development?

#60

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.

The point of a standup isn't to get answers or resolve dependencies - it's to make others aware of them.

The first thing we do after stand ups is have a bunch of quick one-on-one or small group meetings.

Post reply on HN