Ask HN: Are we overcomplicating software development?

Post by flukus » Thu, Jan 19, 2017, 2:51 AM UTC

EdHominem wrote: post #262

simonpantzare wrote: post #235

Earlier quoted context omitted.

Things such as joins, transactions, and means of enforcing data integrity are useful when solving a whole slew of problems. Not to mention the tooling and community you benefit from when you use a common RDBMS. I never found data translation/serialization to be a big pain (just rely on a framework/lib that does it for you). It's a bigger pain to hand-roll joins that would be a one-liner in SQL or deal with issues tha…

I hear this data-integrity thing a lot but I don't run into these problems myself. I think it might be a functional-programming thing. It's much easier and safer to declare your constraints rather than trying to enforce them. If you aren't in a functional language I can see why you'd want to reach out to one but SQL in a separate process is just one of the options. > Things such as joins, transactions, and means of e…

Post by zachrose » Thu, Jan 19, 2017, 3:23 AM UTC

brwr wrote: post #199

juancampa wrote: post #165

Earlier quoted context omitted.

> Favour disposable code over reusable code: Avoid the trap of premature optimisation, both in terms of performance and in terms of software architecture. Some people call it "premature generalization". Relevant C2 page: http://wiki.c2.com/?PrematureGeneralization

The day I learned about premature generalization is that day my speed as a developer jumped by a factor of three. When you're generalizing, it's easy to overlook how much time that takes. My rule these days is that, in most cases, I shouldn't generalize before the same code exists in three places. Why not two? In my experience, things that are done twice aren't necessarily done three times. But things that are done t…

Post by eklavya » Thu, Jan 19, 2017, 4:18 AM UTC

EdHominem wrote: post #262

simonpantzare wrote: post #235

Earlier quoted context omitted.

Things such as joins, transactions, and means of enforcing data integrity are useful when solving a whole slew of problems. Not to mention the tooling and community you benefit from when you use a common RDBMS. I never found data translation/serialization to be a big pain (just rely on a framework/lib that does it for you). It's a bigger pain to hand-roll joins that would be a one-liner in SQL or deal with issues tha…

I hear this data-integrity thing a lot but I don't run into these problems myself. I think it might be a functional-programming thing. It's much easier and safer to declare your constraints rather than trying to enforce them. If you aren't in a functional language I can see why you'd want to reach out to one but SQL in a separate process is just one of the options. > Things such as joins, transactions, and means of e…

Post by scottmmjackson » Thu, Jan 19, 2017, 4:52 AM UTC

brwr wrote: post #191

OJFord wrote: post #114

Earlier quoted context omitted.

> Microservices probably reduces the asymptotic cost of scaling but add a huge constant factor. If this were Medium , I'd highlight the hell out of that. That's so true, and so nicely, succinctly put - it ought to be the reply to end every argument about whether microservices are good or bad.

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…

Post by SatvikBeri » Thu, Jan 19, 2017, 5:12 AM UTC

zeptomu wrote: post #284

SatvikBeri wrote: post #194

Earlier quoted context omitted.

Recently our team built a data pipeline: a few large inputs, a few large outputs, a lot of processing in between, a lot of parallelization & working w/large datasets needed. Essentially you could view the entire process as writing one very complex function. We approached this first outlining the procedure and specifying the types involved, then outlining functions from each type to the next. You could essentially thi…

This is interesting, do you mind being more specific - what was the data, how big was it, how long did the functions run? Assuming you are talking about real types and having something like f1 :: t1 -> t2 and f2 :: t2 -> t3 you suggest you were able to do g :: t1 -> t3 g = f2 . f1 which works perfectly well, but is sometimes nontrivial to do for more complex functions, in particular if they are not pure (e.g. they do…