Live data from Hacker News

Ask HN: Are we overcomplicating software development?

news.ycombinator.com

1–10 of 378 posts

Ask HN: Are we overcomplicating software development?

#1
I have recently been involved in the overhaul of an established business with poor output into a functioning early/mid stage startup (long story). We are back on track but, honestly, my lessons learned fly in the face of a lot of currently accepted wisdom:

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

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

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.

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

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

I think overall we seem to be over-complicating software development. We look to architecture and process for flexibility when in reality its acting as a crutch for lack of communication and proper analysis of how we should be architecting the actual software.

Is it just me?

Re: Ask HN: Are we overcomplicating software development?

#3
I agree with most of your comments. I think as a fairly new profession we are still finding our feet when it comes to best practices. I don't think there is one system that will work across the board for all trades. I mean I would think it took longer than 30-40 years to work out the best way to plumb, wire a house etc.

Sometimes when estimating work, I think how long would the same project take to build 5, 10, 15 years ago. It's not often that time spent coding today is any quicker than before.

Arguably we get better quality software now with unit tests, better compilers and better tooling. Perhaps I've just got some massive rose tinted glasses on!.

Re: Ask HN: Are we overcomplicating software development?

#4
All development teams or products are not the same. Sometimes microservices can improve the quality, and sometimes the opposite.

It is important to know why you do some things, instead of applying Hype-Driven-Development.

Do what is best for you and your team, instead of what is best for someone else (with a different product, problem, and team).

Re: Ask HN: Are we overcomplicating software development?

#5
I think micro-services was your big issue. But yes, getting into the politics of pure scrum, kanban, whatever is a big drag.

DevOps has it's merits and will work well if you're team can stop trying to develop newer better scripts and learn when to say it's good enough. I saw one team revise their scripts over and over for a whole year when they could have been using that guy for new features/bug fixes.

Re: Ask HN: Are we overcomplicating software development?

#6
No. You are correct. Honestly I think you can solve a lot of that by following on from one of Deijkstra's core priniciples: Seperation of Concerns.

When you practice good seperationof concerns, specific choice in different areas can be more easily fixed later. It requires having decent APIs and being thoughtful on the interaction of different components, but it helps immensely in the long run.

Microservices are one way to practice seperation of concerns, but it can also be practiced in monolithic software as well, by having strong modular systems (different languages are stronger at this than others).

Re: Ask HN: Are we overcomplicating software development?

#8
1) Doesn't always work if you want to target embedded systems or need performance, and all you know are scripting languages with huge overhead like Ruby, JS, Python, etc. Some languages really are better than others.

2) Could say avoid distributed computing if your problem is not distributed. This is more about being a blind follower of the latest hype.

3 & 4) Complicated DevOps are a bad idea in general. Stuff that seems to simplify things on the surface like Docker are actually hiding tons of complexity underneath.

5) To most people, Agile = JIRA = Sprints = Scrum. It's corporate mentality codified, so it's no surprise that a lot of startups avoid it.

Re: Ask HN: Are we overcomplicating software development?

#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 rules by the team it gets painful. The underlying problem is often a lack of trust and respect. In an agile situation people will stick to rigid rules (never extend the sprint, we do all our planning in 4 hours, etc.) because they feel they'll lose what little control they have otherwise. In a non-agile situation people can often avoid each other for months and have the situation go south suddenly. In agile you wind up with lots of painful meetings instead.

Also I think it is rare for one language to really be "best for a job". If you want to write the back end of a run of the mill webapp, you can do a great job of that in any mainstream language you are comfortable in.

Re: Ask HN: Are we overcomplicating software development?

#10
devops is good stuff. Just apply to the developers the same standards (and typically answers) as you would to your deployment world. You should be able to answer questions like: "How does a new developer get going within 5 minutes?" in the same way that you answer "How do we build and deploy a new app?" and both the local developer and remote system should be debugged and monitored in the same way.

devops isn't bad, and will speed up onboarding new staff, growing, and helps your devs and ops people immensely.

On the rest I'd largely agree with you... other answers may only apply at a certain scale, or complexity, or some other set of parameters that may not apply to you now.

Solve the problem you have now, and the problem you'll definitely have in the next 6 months.

The rest is for the future.

Post reply on HN