Live data from Hacker News

Ask HN: Are we overcomplicating software development?

news.ycombinator.com

271–280 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#271
I agree with you, but not fully.

1) Well, this is only a case if the project is short enough that its not worth switching. Learning a new tech for a team takes months, only switch if the project is taking years.

2) Again, only use them for bigger (>2 years lifecycle) projects

3) Depends on what you need. We build a full stack apps with around 99.95% uptime (a few hours of downtime/year) in around 3 months of architecture dev time, this was good enough for us. Getting more would have hugely increased dev time, but this number was good enough for us.

4) Disagree. You can build simple CI pipelines in a matter of weeks, which will pay for themselves in a few months thanks to better uptimes, happier employees, shorter release times. Again its only needed if your project lasts for more than a year.

5) Disagree. Agile is very good, if someone knows it well (takes a few days to learn). Its not needed for very small teams (But I think there are problems:

- People getting hyped about the latest trendy stuff. Use bleeding edge/new tech for hobby projects not for money making.

- Do not switch technologies unless really needed, dont fall for the hyped library of the week.

- Do not use a dynamic language for any project that will have more than 5K LOC in its lifetime.

- Do not overengineer. For example if the code is clean, works, but has that ugly singleton pattern its OK. Dont introduce the latest fancy IOC framework, just because you read it in the clean code book that its better.

- Unit test are overhyped. Use them for critical components on the server, and thats it. IMO the hype about them is because dynamic languages scale so badly that you need test otherwise you're fucked. Rather choose a well proven statically typed language, a good IDE, and take code reviews seriously.

Re: Ask HN: Are we overcomplicating software development?

#272

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…

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

The thing is, there is so much other stuff to learn/fix. Where I'm working now most of my day is trying to understand the layers and layers of code they built. If they'd stuck to simpler code I could be learning more about the business and the users workflows. I could be improving the UI with that knowledge, I could be optimizing the business. Instead all my efforts go into understanding the code base.

Re: Ask HN: Are we overcomplicating software development?

#273
I think in many cases complexity just comes from lack of experience and poorly understood requirements.

I've had my fair share of cases where I ended up implementing something needlessly complicated, only to later realize my approach was terribly misguided. I'd like to think I'm slowly improving on this as time goes on.

The software world has a big discoverability problem. Even though I know there's probably prior art of what I'm working on, I don't always know where to look for it.

Re: Ask HN: Are we overcomplicating software development?

#274
post #255

Earlier quoted context omitted.

> Relational databases are the right choice 95% of the time, non-relational stores require a really specific use case. Relational databases are great, but I spent large parts of my life as a developer writing layers converting to/from SQL and later ORMs. There's a huge gain in just not translating data. I know Postgres (and others) deal with JSON, but I can't escape the feeling it's a bit shoe horned in there – basic…

Exactly. I start with text files and for most purposes I do not bother with anything else. Next is a key/value store. Simple. Relational databases carry large overhead in translating data (as above) and also in design and maintenance of the structure and getting data into and out of them. I spent many years with them, like them a lot, but they are too much complication for most purposes. Even with relational data RDB…

I'm stunned that you're stunned that people generally don't use text files as data stores.

Re: Ask HN: Are we overcomplicating software development?

#275
post #221

Earlier quoted context omitted.

> 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? You can and I do. However, I am thinking of using polymer or vue.js as I think they are a much lighter candidate than react.js & angular. The power of marketing is underrated in the developer circles.

If you still use Rails and jQuery, why both with Polymer or Vue? What is the benefit they give you? Promise I'm not giving you a hard time. I'm honestly curious if there's something I'm overlooking.

My experience is with c# and knockout, which is pretty similar to rails and vue. I've found the sweet spot to avoid SPA's (which I'm pretty sure you can do with vue). Generate the html server side and only use javascript for the dynamic parts where it makes sense.

Re: Ask HN: Are we overcomplicating software development?

#276
post #191

Earlier quoted context omitted.

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.

Another option is to start with an umbrella app (Erlang/Elixir/OTP). It can run like a monolithic or ... nano-services (I suppose) within the same monolith. When it is time to split them out, it is easier.

It does assume that you either start with devs familiar with OTP or you have generalist devs that can pick things up quickly.

Re: Ask HN: Are we overcomplicating software development?

#277
post #233

Earlier quoted context omitted.

That is absurd. You can't write an OS in 100KLOC.

Check out stats on the kOS/kparc project: https://news.ycombinator.com/item?id=9316091 There is also a more recent example of Arthur Whitney writing a C compiler in <250 lines of C. Remarkable how productive a programmer can be when he chooses not to overcomplicate.

Everything I saw in the link looks like K, not C. Do you have a link to the C compiler done in C language?

Re: Ask HN: Are we overcomplicating software development?

#278
post #83
post #30

I've seen the addition of unit testing is a big cause of complexity. Previously simple classes now have to be more abstracted in order to unit test. Add mocks, testing classes & test frameworks. Some unit tests are handy, but I dont think it justifies the additional complexity. For the apps I write I'd like to see more emphasis on automated integration testing and fewer unit tests - so we can write simple classes aga…

In my experience, it's usually not the existence of unit tests themselves that's causing an issue, but that most of them are badly written. One telltale sign is when writing the unit test becomes overly painful (like too much code setting up mocks), it usually means that your class is not simple enough or has too many dependencies. Proper unit testing also complements integration testing in that corner cases can be h…

I've seen this too. Unit testing was mandated from on high and it's something developers never learned to do properly. My telltale sign is more than one logical* assert. A test should usually be only a few lines of code, a dozen lines should be all that's needed for 99% of tests.

*Logical meaning only test for one thing, not a single assert statement. So testing for null and testing if a value is set is fine, but testing if 10 values are set correctly is not.

Re: Ask HN: Are we overcomplicating software development?

#279
A certain amount of complexity or complication is required to solve problems. Sometimes, you will undershoot the mark, and not fully solve the problem. Other times, you will overshoot the mark, and create problems in the form of overcomplicated answers.

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

It's a tradeoff - rampup time vs efficacy once ramped up. It's probably okay to let your devs rock it old school with vanilla Javascript for your website frontend - it's probably not okay for them to try and write your website frontend in COBOL, even if CobolScript is apparently a thing, just because they don't know Javascript.

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

CI is great plaster for all kinds of problems, not all of which you'll be able to solve in a reasonable fashion. Of course, you may have problems which would be better to solve that you're using CI as a crutch to avoid solving - or to simply deal with the fact that you haven't gotten around to solving those problems yet.

In game development, I use CI to help 'solve' the problem of my coworkers not thoroughly testing all combinations of build configurations and platforms for each change. 5 configs and 6 platforms? That's already 30 combinations to test, so it's no wonder...

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

On the other hand, other companies rock "flat" management well past the point it's effective, and may lack any kind of methodology to keep progress on track - which is also problematic.

Re: Ask HN: Are we overcomplicating software development?

#280

It's all about long-term vs short-term. Everyone architects software for the short term, I'd say the industry at large has collectively lost/never had the vision and wisdom to do anything else. Now maybe if you are a tiny-ass start-up, sure, but for a big established company, this is just bad economics. Why do we talk about "disrupting" the "behemoths"? Why is everything done in tiny-ass largely-parallel teams? Very…

> Everyone architects software for the short term, I'd say the industry at large has collectively lost/never had the vision and wisdom to do anything else.

I think everyone architects for the long term, they just do so poorly. The problem is that architecture has become synonymous with "more layers".

Post reply on HN