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

251–260 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#251

Post by walrus1066 »

BjoernKW wrote: post #28

No, it's not just you and yes, we often do overcomplicate software development. It's been that way long before agile methodology or microservices though. Complexity-for-the-sake-of-complexity EverthingHasToBeAnAbstractClass frameworks have been plaguing the software development business since at least the 1990s and I'm sure there are similar stories from the 80s and 70s. It's hard to find a one-size-fits-all easy met…

100% this, applying occam's razor to software engineering, the simplest solution is most often the best one.

It always amazes me, the instinct by engineers to overcomplicate things. They shoot themselves in the foot and curse when the inevitable subtle bugs start rolling in.

Re: Ask HN: Are we overcomplicating software development?

#253

Post by Ericson2314 »

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 few companies have had serious thoughts about programming at scale.

I don't dispute that doing things the right way is often a huge up-front initial investment, but you do eventually get over the hump.

Re: Ask HN: Are we overcomplicating software development?

#255

Post by worik »

algesten wrote: post #182
SatvikBeri wrote: post #63

Many of these practices are popularized by Google/Facebook/Amazon but don't make sense for a company with 100 or even 1,000 people. I try to focus on whether a practice will solve a concrete problem we're facing. Switching from Hadoop to Spark was clearly a good idea for our team, even though it required learning a new stack, but there isn't a strong reason to switch to Flink or start using Haskell. Agile makes sense…

> 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 RDBMS are only good if you are not certain of how you will be accessing the data. In most cases you are sure.

I am constantly stunned how people reach straight for MySQL or Postgres when flat text files with grep would work just as well and be much quicker to implement

Re: Ask HN: Are we overcomplicating software development?

#256

Post by sjakobi »

krptos wrote: post #134
SatvikBeri wrote: post #63

Many of these practices are popularized by Google/Facebook/Amazon but don't make sense for a company with 100 or even 1,000 people. I try to focus on whether a practice will solve a concrete problem we're facing. Switching from Hadoop to Spark was clearly a good idea for our team, even though it required learning a new stack, but there isn't a strong reason to switch to Flink or start using Haskell. Agile makes sense…

"putting your logic into types is better" Can you elaborate on that one? Sounds interesting to me.

In functional, statically typed programmings languages, there is a pattern where business logic, including "actions", is encoded in types. This article [1] gives an example of filesystem manipulations that are encoded in a "FreeF" type.

When business rules are encoded in datatypes, it's easy to check that the encoding and the transformations are complete, and the logic can easily be mock-tested.

[1] http://degoes.net/articles/modern-fp

Re: Ask HN: Are we overcomplicating software development?

#257

Post by jkchu »

Ericson2314 wrote: post #253

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…

Can you elaborate on what you mean by "programming at scale"?

Re: Ask HN: Are we overcomplicating software development?

#258

Post by egportal2002 »

worik wrote: post #255
algesten wrote: post #182

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…

seriously curious -- what do you do when someone or some other "function" wants to query your data, wants to update it, etc.?

Re: Ask HN: Are we overcomplicating software development?

#259

Post by codingdave »

brilliantcode wrote: post #239
brwr wrote: post #221

Earlier quoted context omitted.

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.

I asked the same question last year and to be honest, building a SPA is tough with just jQuery. It's more of my needs changing, I don't think SPA can be ignored in 2017, the progressive web app and AMP will put a huge dent in the native apps space. I just like to think that I'm developing a mobile app with front-end javascript framework....it's just the tooling and prerequisite knowledge is quite chaotic. Finding the…

I'm not sure why an SPA with jQuery is tough. $.ajax. Send data. Do stuff in a back-end. Return data. Update divs. If it is tough, you might be trying too hard. I'm not trying to be glib... it just sounds like you might be buying into the over-complexity that the original question was talking about.

Re: Ask HN: Are we overcomplicating software development?

#260

Post by icebraining »

TeMPOraL wrote: post #214
pg314 wrote: post #142

Earlier quoted context omitted.

The implementation of PostgreSQL is complex, no doubt about that. But if you need strong data consistency and durability guarantees, it provides a rock-solid foundation. SQL might take some getting used, but it is also not rocket science. It shouldn't take more than a week's study to master the basics. There is of course a lot of awful SQL code out there, exactly because most programmers don't even know the basics. Y…

> In my opinion dumping an ORM on top is also not the best way to leverage the strengths of an RDBM. I agree. Unfortunately, the way I see people usually using them is pretty bad - you should not let ORM-generated stuff dictate your business model. Database is a database. A storage layer. Business objects will not map 1:1 to ORM objects. Approaches like "let's inherit from ORM class and add business-related methods",…

I'm aware of the different approaches (mostly from reading Fowler's PoEAA), but currently we use an Active Record-style ORM with a few extra features (like Class Table Inheritance) and we haven't found any major issues with this approach. What was the worst case scenario you experienced with the 1:1 approach?
Post reply on HN