Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fighting Complexity in Software Development

github.com

Post reply on HN
Print view View original

11–20 of 117 posts

Re: Fighting Complexity in Software Development

#11

Post by twodave »

On the C# API I develop for we overcome these issues in a few ways.

1. Our way of implementing DDD helps us organize code into infrastructure and domain. Domain objects typically aren’t allowed to have external dependencies. Infrastructure code is primarily for data access and mapping. Our API code (controllers and event handlers) ties the two together.

2. Given the above we are able to write a) very clear and concise unit tests around domain objects and API endpoints and b) integration tests that don’t have to bother with anything but data and other external dependencies.

The result is that when we go to ask, “How does the system respond given X?” we can either point to a test we have already written or else add a new test or test case to cover that scenario.

We can even snapshot live data in some critical areas that we can then drive through our high level domain processes (we process payroll so it’s a lot of data to consider). If someone wants to know how a particular pay run would play out, they can just craft the data snapshot and write some assertions about the results.

We also use FluentValidation (on API objects only) and test those as well (but only if the rules are non-trivial).

Re: Fighting Complexity in Software Development

#12

Post by Aeolun »

avinium wrote: post #10
lacampbell wrote: post #6

I love F#, but using F# instead of (type|java)script would add a lot of complexity to my 'full stack'. Let's see I replaced my node.js backend with an F# one, the following issues would arise: 1. I now have two different languages for client and server, and can't share e.g. validation code. 2. Dealing with 2nd class linux support (no REPL) 3. No library that combines the maturity and simplicity of express.js. Yes I a…

I really don't think it adds complexity. Sure, it's going to be different , so there's a mental hurdle to clear in learning how a new stack works. That doesn't mean it's going to be more complex . > 1. I now have two different languages for client and server, and can't share e.g. validation code. You could use Fable to transpile F# to Javascript, keeping a single language > 2. Dealing with 2nd class linux support (no…

> You could use Fable to transpile F# to Javascript, keeping a single language

That would only solve your runtime issues. You would still need to write the same code twice.

Re: Fighting Complexity in Software Development

#13

Post by Aeolun »

I feel like I’ve responded this before, but I feel like people often attribute their increased knowledge of how to develop systems without bugs to the new fancy language they switched to.

Fact is they could build better software in the old language as well, assuming they started from scratch.

Re: Fighting Complexity in Software Development

#14

Post by kazinator »

The main source of complexity is requirements. Gatekeeping against the influx of requirements will keep complexity down.

Then there is unnecessary complexity from doing incomplete refactorings and rewrites. If some code cannot handle the addition of a new requirement, it should be replaced. Otherwise you add complexity that roughly takes the logical (if not actual) form if (these cases) { new code } else { old code }. And there is overlap! new code has taken over requirements for which old code still exists, but because of some lingering requirements that only the old code handled, all of it is still there (due to laziness, dependencies or whatever). It's not obvious that some of that code is never used; someone diving into it faces the complexity of figuring out what is the real payload in production now and what is the historic decoy.

Re: Fighting Complexity in Software Development

#15

Post by arwhatever »

Aeolun wrote: post #12
avinium wrote: post #10

Earlier quoted context omitted.

I really don't think it adds complexity. Sure, it's going to be different , so there's a mental hurdle to clear in learning how a new stack works. That doesn't mean it's going to be more complex . > 1. I now have two different languages for client and server, and can't share e.g. validation code. You could use Fable to transpile F# to Javascript, keeping a single language > 2. Dealing with 2nd class linux support (no…

> You could use Fable to transpile F# to Javascript, keeping a single language That would only solve your runtime issues. You would still need to write the same code twice.

How do you figure?

Re: Fighting Complexity in Software Development

#16

Post by lacampbell »

avinium wrote: post #10
lacampbell wrote: post #6

I love F#, but using F# instead of (type|java)script would add a lot of complexity to my 'full stack'. Let's see I replaced my node.js backend with an F# one, the following issues would arise: 1. I now have two different languages for client and server, and can't share e.g. validation code. 2. Dealing with 2nd class linux support (no REPL) 3. No library that combines the maturity and simplicity of express.js. Yes I a…

I really don't think it adds complexity. Sure, it's going to be different , so there's a mental hurdle to clear in learning how a new stack works. That doesn't mean it's going to be more complex . > 1. I now have two different languages for client and server, and can't share e.g. validation code. You could use Fable to transpile F# to Javascript, keeping a single language > 2. Dealing with 2nd class linux support (no…

Hi, thanks for the open minded response. It's an issue I enjoy discussing.

You could use Fable to transpile F# to Javascript, keeping a single language

That seems like another explosion of complexity. Source maps, mapping F# to a JS constructs when debugging, niche tooling, wrapping other JS libraries in a nicely typed F# package... IME it's best to avoid transpiling anything more exotic than typescript.

FSI is available under Linux, but I admit it's got some hairs on it. (FWIW, FSI on Windows needs a lot more TLC too).

I appear to be mistaken - I remember I was excited when the dotnet tool came out, but then they took away the REPL. FSI is mono only, right?

This is purely a matter of taste. While express.js is very accessible, I don't think it's any more so than Giraffe (a wrapper around ASP.NET Core).

Yes it's very subjective, we can agree to disagree here.

I'm all-in on F# now - once you're over the (mild) initial learning curve, you see huge dividends from the smaller codebase, static typing, fewer null-checks and drastically less testing required.

I love F#, I used it professionally and it was a great experience. And you are right, the conciseness is hard to beat. But the static typing/fewer null checks thing is easily solved in JS land with the typescript compiler.

Re: Fighting Complexity in Software Development

#17

Post by jes5199 »

Chyzwar wrote: post #8

In mature OOP you have ways to write nice models and have good validations. https://guides.rubyonrails.org/active_record_validations.htm... I will argue that the complexity of software development is not because of OOP vs Functional. Tooling, documentation, quality of libraries and people are what matter most. Ruby was a massive success is largely attributed to above. We are humans, we can understand and deal with a…

but have you ever had to maintain a ruby project after the first year? The cost just goes up and up, and I think it’s because the language is so hostile to static analysis.

Re: Fighting Complexity in Software Development

#18

Post by arwhatever »

lacampbell wrote: post #6

I love F#, but using F# instead of (type|java)script would add a lot of complexity to my 'full stack'. Let's see I replaced my node.js backend with an F# one, the following issues would arise: 1. I now have two different languages for client and server, and can't share e.g. validation code. 2. Dealing with 2nd class linux support (no REPL) 3. No library that combines the maturity and simplicity of express.js. Yes I a…

What would the concrete implementation of the at class that represents the deactivated credit card look like?

Re: Fighting Complexity in Software Development

#19

Post by jes5199 »

tw1010 wrote: post #5
realshowbiz wrote: post #4

I’m quite happy to be seeing conversations about the benefits of simplicity, boring tech, etc lately. It’s a breath if fresh air from the sadly too common (IMO) flavor of the month new tech promotion.

Sometimes it's hard to disentangle if a conversation is having an upward trending trajectory, or if you just happen to pay attention more to the links that mention some subject you happened to have caught an interest in.

Yeah, I’ve been hearing a lot about the Baader-Meinhof effect recently

Re: Fighting Complexity in Software Development

#20

Post by kazinator »

Aeolun wrote: post #13

I feel like I’ve responded this before, but I feel like people often attribute their increased knowledge of how to develop systems without bugs to the new fancy language they switched to. Fact is they could build better software in the old language as well, assuming they started from scratch.

This can be validated or refuted by going back to that language and building something. If the same old roadblocks reappear, it was the darned language, after all.
Post reply on HN