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

341–350 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#341

Post by TeMPOraL »

icebraining wrote: post #260
TeMPOraL wrote: post #214

Earlier quoted context omitted.

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

Over the past 5 years I've been in two projects using 1:1 ORM Active Record == business model base approach. One completely failed in part because of this, second is barely manageable, but I managed to save it by moving business code mostly to the outside of Active Record classes.

The problem I encountered in those projects is the mismatch between storage mental model and business mental model, which lead to explosion of crappy code (AKA technical debt). In particular:

1. the classes I need for business model may have initially mapped well to database tables, but over time they stop; business logic and model changes much faster than you'd like your DB schema to

2. since many things in AR can fire SQL queries, you have to keep in mind the workings of your database when doing almost every operation on your model; it's an abstraction leak

3. code shooting off SQL queries is randomly called from all over your codebase; it's harder to keep track of it and, if needed, optimize those queries

I like AR as a convenient API to get data from/to database, but given the point 1., I eventually learned to isolate AR layer as something below business model layer, so that the pattern is that business model is explicitly serialized and deserialized from database, instead of the database being coupled with the logic of your program.

Now I vaguely recall complaining about this before on HN and getting my ass handed back to me by someone who pointed out that these are all ORM n00b mistakes. I wish I could find that comment (pretty sure I noted the link down somewhere). Yeah, I admit - in those two projects I mentioned, we were all ORM noobs. So we've learned those lessons the hard way.

Re: Ask HN: Are we overcomplicating software development?

#342

Post by crdoconnor »

UK-AL wrote: post #337
crdoconnor wrote: post #145

Earlier quoted context omitted.

I find that the boundary creates operational headaches. A function call won't time out, deliver a 502 error, have authentication/authorization issues, require load balancing, etc. etc. A REST API will. Plus, once you've debugged a problem that involves crossing 5 microservice boundaries you'll start to wonder if it was all worth it. Monolith is also a wrong (and somewhat derogatory) word to describe a non-microservic…

Except most applications are monolith. Monolith code can still be loosely coupled. However it is harder.

No, not at all.

The only difference I noticed with respect to rube goldberg (what you call "microservices") systems and coupling is that tight coupling between components of rube goldberg systems was much more painful: particularly debugging across multiple service boundaries.

Re: Ask HN: Are we overcomplicating software development?

#343

Post by Nomentatus »

julsonl wrote: post #248
jononor wrote: post #223

Earlier quoted context omitted.

Many unit tests are just written to test code, which is at best irrelevant. At worst your codebase is 2-3x bigger and more abstract than it needs to, where useless tests keep code alive and useless code keeps tests alive. Test functionality, as close to the promises given to outside consumers as is feasible. Be it API or UI for other people/projects/services. This is the stuff that needs to work (and thus often need…

I'm not arguing against writing integration tests, they are as important if not more important, as you've said. Maybe I've only seen badly written ones, but my issue was against integration tests that check for example if this ever so important, but hidden, flag is being set properly after an API call when that can be checked at the service level. Someone eventually decides that flag is unneeded, and a whole host of…

I don't think you can avoid meta-debugging. That is, debugging your asserts or tests that you hoped would detect bugs instead of being the bug. Sometimes because more realistic tests unveil a bug, sometimes (as in your example) because underlying code functionality has changed. This is unavoidable but also often enlightening. To my mind, it's even okay if most of your bugs are meta - because these are usually very fast fixes, and it probably means you have a lot of checks. But by the same token, I would agree with you that all such tests have to be well-written, not mailed in, for just the reasons you give. It's too easy to assume that writing tests is somehow a fairly trivial task. Until you end up debugging the test.

Re: Ask HN: Are we overcomplicating software development?

#344

Post by akamaozu »

ChuckMcM wrote: post #96

Yes we are over complicating it, but that it primarily about trying to take what is essentially an artistic process and turning it into a regimented process (a known hard problem). Rob Gingell at Sun stated it as a form of uncertainty principal. He said, "You can know what features are in a release or when the release will ship, but not both." It captured the challenge of aspirational feature development where someon…

Link to the post about the graphics library please?

Re: Ask HN: Are we overcomplicating software development?

#345

Post by sethammons »

serge2k wrote: post #170
hectormalot wrote: post #146

Earlier quoted context omitted.

I've seen Jira tickets about creating Jira tickets :) In large lines I agree with this comment. Micromanagement of Agile teams is detrimental. Implicitly, the message is that managers should leave their teams to work in peace? The question I have: assume you are that manager. You have 5 agile teams working on 5 client projects. One team seems to get work done much slower than the other teams. What do you do? (And how…

> I've seen Jira tickets about creating Jira tickets :) So long as it's one:many.

Or one to one where the first is a spike that will take time to determine what should go into the second (discovery, learning, experiment, further estimations). You would not want to commit to a unit of work without some idea of what it entails in Agile. The alternative is Programming Mother Fucker where you just dive in and see where it takes you. The business side usually prefers more predictability. The developers usually prefer to Just Getting It Done (tm).

Re: Ask HN: Are we overcomplicating software development?

#346

Post by Ericson2314 »

jkchu wrote: post #257
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"?

Scale in terms of the number of employees.

I think most people at the org should be Alan Kay called "second order work"—libraries foremost, but also programming tools, etc. Just about any end business goal should be a trivial composition of existing abstractions—if it isn't that's a problem to be addressed.

Work reuse always reflects the dependency graph of libraries and tools etc. In this type organization, I'd expect much bigger (depth and width) dependency graphs than the current independent teams model.

The end result is organizations should become more "agile" as they grow because they have more high-quality abstractions to lean on.

But current practices always put end-goal over process, and thus have no chance of cultivating this efficiency.

Re: Ask HN: Are we overcomplicating software development?

#347

Post by JustSomeNobody »

cookiecaper wrote: post #111
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…

I think the tendency to over-engineer is a symptom of retrofitting an assembly-line 9-5 shift onto the creative process of writing code. You sit a guy there 5 days a week for many years. He has to look busy, he has to do something with all of that time. He's not going to get paid if he writes the code in the most simple, concise, and straightforward way possible and then goes home until they're ready to make a new fe…

Very accurate and poignant.

Re: Ask HN: Are we overcomplicating software development?

#348

Post by kingsawlamoo34 »

Why not all peoples are searching actual software?Its so difficult how many years in making system anyone cannot knowing of all of app or platform or app or plug in or device or codechar all things are supporting each other if one app is not update directdownload from google play store,windos for microsoft store how to give the part way of moving simple all App or Apk have in their basic code ID company .how about they making of you will be use one app or apk and then you sign out App and delete software but your using activity remain in more sure you can next time you reuse same app you will be seen or not your history this is one things but alittle difference in fre game app how about you play inside but you will be exit and then you replay this you can see or not your recent play section if you make log in account connect sure you can making or not resume game section game.all of game have in prevent and resume section already contain but you are not own create you cannot open this background codechar or security for example...

Re: Ask HN: Are we overcomplicating software development?

#349

Post by beat »

misha67 wrote: post #330
beat wrote: post #106

1. What problem are you optimizing for? "The job" encompasses code, but it also encompasses staffing. It's a lot easier to hire Java developers than Scala developers. In a leadership role, your responsibility isn't just the day-to-day code - it's the whole project. 2. Microservices vs monoliths is a see-saw. You build a monolith, find it's a brittle, incomprehensible hairball, and you break out microservices. You bui…

> Which kneecap do you want the bullet in? Funniest thing I've heard all day!

That's the fun of working with me. I say funny shit!

I occasionally refer to the final steps of a project as "bayoneting the wounded" too.

Re: Ask HN: Are we overcomplicating software development?

#350

Post by nojvek »

As everyone is saying: do what is reasonable and useful.

E.g let's make an online shop.

It has browsing, purchasing and admin sections.

Browsing is simple. Query dB and show html. It's probably the most used as well and needs to be reliable. Having as different service means admin section could break while users are still able to browse. Same for payments. Sometimes it's crazy complicated. I think of microservices as big product feature boundaries that can work independently. A failure in one doesn't affect the other.

Continuous integration: once you have your tests, and some auto deploy scripts, you have an engine. You push code, tests auto run, a live staging is created for latest code, you play with it. Looks good? Merge with Master. It's deployed to production. The idea is deployment is effortless and you can do it multiple times a day just like git push. Tests just don't only have to be unit. We run integration testing features on dummy accounts periodically from different regions in the world on production. This means you are alerted as soon as something breaks. Fast deployment and great telemetry mean you can always revert to last known good state easily.

Investing in tests is a pain but it pays off in the long run. Especially if you have other developers working on same code base.

Just don't over do it. I believe these ideas came from pain developers actually faced and they used then to solve it. If you're not feeling the pain or won't feel it then you don't need the remedy.

Post reply on HN