I think these problems are not about software development, but are infrastructural and architectural. Lack of good people to handle those things is certainly a problem. But you do need quite a bit of infrastructure for microservices, for resilience, for continuous integration and all of that paired with some good architectural decisions. Resilience is probably the hardest thing among them, as it requires some expertise in distributed systems, operations, infrastructure, so you wouldn't do something, that has almost no impact, but requires a lot of engineering effort.
Ask HN: Are we overcomplicating software development?
71–80 of 378 posts
Re: Ask HN: Are we overcomplicating software development?
#72Continuous 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…
Agile is a very loaded word. One meaning of Agile is a very specific kind of process, the other meaning and perhaps closer to the original manifesto is what you're describing with the "non-agile" team.
Re: Ask HN: Are we overcomplicating software development?
#73Earlier quoted context omitted.
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.
From my personal experience: experienced teams can thrive with almost no methodology and an ad-hoc process because... They had experience with other processes and can see the good and bad in them.
I still advocate agile for less homogeneous teams or in situations like other posts have highlighted but a team of more senior developers with a working process that is open to be improved (one of the cornerstones of agile) will thrive with less churn than when forced into a by-the-book agile process.
Re: Ask HN: Are we overcomplicating software development?
#74Point 5 is really insightful. When you read it carefully, it implies that agile "methodology" will soon become the prevalent methodology. Because a successful project is all about managing a massive amount of "specific, discrete, communications issues". And doing so on a daily basis is the best option. Off-topic note: point 5 is also the way to go with your wife/husband/girlfriend/boyfriend, your kids, your friends,…
Interesting idea. I think dinner is the best place for an evening family SCRUM meeting.
SCRUM meetings with cheese and wine.
THIS - IS - BRI-LLI-ANT !!!
Re: Ask HN: Are we overcomplicating software development?
#75Continuous Integration is (with a reasonable test suite) one of few elements of software development that I would consider almost essential for any long running project. It's just too useful to have continual feedback on the quality of the system under construction. (And this is before bringing in micro-services or any other complicating architectural pattern.)
Where I might agree with you more are on points 3 and 4: 'Advanced reliability' and 'Microservices'. While I have no doubt that these are useful to solve specific problems, I think as a profession we tend to over-estimate the need for these things and under-estimate the costs for having them. To me this implies that there needs to be a very clear empirical case that they support a requirement that actually exists. I'd also make the argument that the drive for microservices within an organization has to come from a person or team that has the wherewithal to commit resources over the long-term to actually make it happen and keep it maintained. (ie: probably not an individual development team.)
Re: Ask HN: Are we overcomplicating software development?
#76Well, yes, we are overcomplicating it. Except on the parts we are undercomplicating... And I still couldn't find anybody that can reliably tell those apart, but the first set is indeed much larger.
1 - Do not pick a new language for an urgent project. Do look at them when you have some leeway.
2 - Yep.
3 - There's something wrong with your ops. That happens often, and it is a bug, fix it.
4 - If CI is making your ops more complex, ditch it. If less complex, keep it. In doubt, choose the safest possible way to try the other approach, and look at the results.
5 - Do not listen to consulting experts, only to technical experts. The agile manifesto is a nice reading, read it, think about it, try to follow, but don't try too hard. Ignore any of the more detailed methodologies.
Re: Ask HN: Are we overcomplicating software development?
#77You need to work in an environment devoid of any practices like agile / CI etc and then you would know the difference. It might slow down your progress, but makes up for it with consistency, discipline eventually leading to development of better(reliable) software !
Re: Ask HN: Are we overcomplicating software development?
#78I think one cause of the problems is that what is good at Google scale is not necessarily relevant for a team of ten people.
I think the lesson here is be critical of "best practices" and think about what will work in YOUR context.
Re: Ask HN: Are we overcomplicating software development?
#79Yes, we are; no, it's not just you. Next question.
Re: Ask HN: Are we overcomplicating software development?
#80Yes. What you have discovered is the same epiphany most developers have as they get more experienced and better at their jobs.