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

331–340 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#331

Post by AstralStorm »

sjakobi wrote: post #256
krptos wrote: post #134

Earlier quoted context omitted.

"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…

Some rules are extremely hard to encode as types or the result is extremely awkward. Or worse, performance suffers due to encoding.

If it feels like translating into a foreign language, then it likely is that exotic or you are using a wrong language.

Re: Ask HN: Are we overcomplicating software development?

#332

Post by EdHominem »

zeptomu wrote: post #300
EdHominem wrote: post #262

Earlier quoted context omitted.

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…

> If the domain needs transactions [...] Considering we speak about daemon software (services exposing some API to readers and writers) that provides CRUD behavior to the user (end-user or other developer), isn't that nearly always the case to guarantee write access to concurrent writers without the risk of crippling your data? Furthermore I am not sure how this relates to FP. > It's much easier and safer to declare…

> > It's much easier and safer to declare your constraints rather than trying to enforce them.

> Furthermore I am not sure how this relates to FP.

I'm saying that FP is great for ensuring correctness.

> But that is a strong point of RDBMs implementing SQL.

Right. And if I didn't have other functional languages available that might be a bigger issue.

Re: Ask HN: Are we overcomplicating software development?

#333

Post by misha67 »

rb808 wrote: 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…

Done well, unit tests are invaluable. I'm a relative late-comer to unit testing, but can attest to its value.

The discipline of unit testing forces me to think about what risks I'm introducing with my new code.

Unit tests drive better design - smaller classes, looser coupling, better separation of concerns, functions that don't have side effects.

Best of all, unit tests reduce regressions. I can't count the times my test suite has prevented me from introducing a bug in my app.

I can refactor code with much more confidence than if I did not have 400 unit tests checking my work.

Most recently, these tests proved their worth when upgrading my app to Swift 3.0.

Re: Ask HN: Are we overcomplicating software development?

#334

Post by misha67 »

rbalicki wrote: post #161
rb808 wrote: 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…

The "threat" of having to add unit tests should force developers to write their classes and components in a way that is easy to reason about. In particular: * put as much functionality into pure functions * depend less on statically-linked globals * import all significant collaborators across seams that can be mocked. * keep state in a small atom, rather than strewn about If you write code like that, you get many of…

The threat of having to write unit tests will not have nearly the effect of actually writing them.

It's too easy to fool yourself into thinking you've written testable code.

Re: Ask HN: Are we overcomplicating software development?

#335

Post by spronkey »

disordinary wrote: post #317
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…

Having loosely coupled microservices has benefits for maintenance as well as scaleability. If you are quickly iterating on a product and have it up in a rough state then you can easily work on seperate parts without having to worry about effecting the whole.

It can go both ways. If you mess up modification of the microservice such that it breaks other services that relied upon it, you quickly get into ceremony that a small team might struggle with. A monolith might have had the problem solved faster.

Re: Ask HN: Are we overcomplicating software development?

#336

Post by disordinary »

spronkey wrote: post #335
disordinary wrote: post #317

Earlier quoted context omitted.

Having loosely coupled microservices has benefits for maintenance as well as scaleability. If you are quickly iterating on a product and have it up in a rough state then you can easily work on seperate parts without having to worry about effecting the whole.

It can go both ways. If you mess up modification of the microservice such that it breaks other services that relied upon it, you quickly get into ceremony that a small team might struggle with. A monolith might have had the problem solved faster.

You're right of course, but it can also go the other way. If you break something then it seldom brings the service down, and often the breakage is very visible and can be seen by queues backing up. You can restore the broken service without having to redeploy the system as a whole.

Like most things in life there is no right answer, with tools like Terraform you can build a very complicated microservices system with not much effort, but only if someone on your team is experienced enough. If you're in a small team it's probably not worth the effort of learning the techniques and putting them in practice. We hate premature optimisation after all.

Re: Ask HN: Are we overcomplicating software development?

#337

Post by UK-AL »

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

Earlier quoted context omitted.

I find microservices can help in just keep everything small and focused. I know you can do this with a monolith. But having a process boundary really enforces it.

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.

Re: Ask HN: Are we overcomplicating software development?

#338

Post by sobani »

user5994461 wrote: post #238
brwr wrote: 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…

At the last place I was at. We had a micro serviced monolith. I can't even begin to describe that thing in common engineering terms. (note: it's better than it seems).

In case you're wondering about the downvotes, a micro services monolith sounds like an oxymoron.

Could you expand on how the architecture actually looked? What made it a monolith and what made it micro serviced?

Re: Ask HN: Are we overcomplicating software development?

#340

Post by buzzybee »

adamnemecek wrote: post #234
GregBuchholz wrote: post #228

Earlier quoted context omitted.

Have you looked in the STEPS program by Alan Kay? Trying to recreate modern computing setup from the OS up in 20k lines of code... http://www.vpri.org/pdf/tr2012001_steps.pdf "If computing is important -- for daily life, learning, business, national defense, jobs, and more -- then qualitatively advancing computing is extremely important. Fro example, many software systems today are made from millions to hundreds of m…

I'm aware of this but Alan Kay's work and this seem to be orthogonal. Alan Kay talks about reducing real systems that have compilers, inputs etc whereas Elements talks about like the day to day ways of writing code. Alan Kay might come up with a new keyword whose semantics magically lets you cut out 30% but Elements shows you that if you make your types behave certain way, generics will let you cut out a lot of code.

I would counter that this appears to be a repeatedly emerging consensus, including Stepanov, Kay, Simonyi, and a number of other "greats", that an approach that involves some degree of metaprogramming, guided by domain problem, is the way forward. They differ on terms - cooperating systems, model-driven, intentional, generic - and focus - whether to create new syntax, or to guide the creation of specific algorithms or data structures - but they aren't debating the power of the approach.
Post reply on HN