Live data from Hacker News

Fighting Complexity in Software Development

github.com

41–50 of 117 posts

Re: Fighting Complexity in Software Development

#41
post #30

Earlier quoted context omitted.

Are you arguing that all tools are equal? Or that some tools are better than others but the difference is negligible compared to experience? I don’t agree that experience is everything (if by everything you mean that all other factors have zero influence).

Without experience, tools don't matter. A skilled developer will most likely write better code regardless of language/framework. It's a repeating pattern in this society, fools with advanced gear doing what fools do best.

I'd argue that no matter how "good" you are, you are capped at what tools you're using.

Consider using a hammer against a pneumatic tool. A newbie will hose you with better tools, they're wielding that condensed knowledge at their hands, their sum overshadow yours with only a hammer.

Re: Fighting Complexity in Software Development

#42
post #39
post #17

Earlier quoted context omitted.

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.

Have you maintained anything after the first year where that wasn't the case? Especially if you had a high degree of churn on the developers. I'll grant that it is easier in more stable API environments. But we are our own worst enemies in that race.

if I pick up an old Java project, it might be a mess, but I'll be able to rename methods, refactor classes, and upgrade libraries until it gets into shape - and I'll have a fair amount of confidence that it'll keep working while I do that, because metaprogramming is rare, APIs are fairly stable, and the IDE will mostly be able to understand what the code is doing. In a ruby project - especially in a Rails project - you can never know for sure what code is calling what. There's no "Find usages" tool that can be relied on. And then, all your dependencies will have completely changed their APIs and behaviors, and they'll have a complex matrix of incompatibilities that means that you might have to upgrade several libraries at a time and rewrite a lot of code just to keep things working.

Re: Fighting Complexity in Software Development

#43
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.

"Started from Scratch". I have never seen any project where something has been started from scratch actually turn out well.

Now read that again. Every single piece software that exists, successful or otherwise, was at some point started from scratch.

Re: Fighting Complexity in Software Development

#44
post #42
post #39

Earlier quoted context omitted.

Have you maintained anything after the first year where that wasn't the case? Especially if you had a high degree of churn on the developers. I'll grant that it is easier in more stable API environments. But we are our own worst enemies in that race.

if I pick up an old Java project, it might be a mess, but I'll be able to rename methods, refactor classes, and upgrade libraries until it gets into shape - and I'll have a fair amount of confidence that it'll keep working while I do that, because metaprogramming is rare, APIs are fairly stable, and the IDE will mostly be able to understand what the code is doing. In a ruby project - especially in a Rails project - y…

> metaprogramming is rare

In Java? Not really. Spring has been around since 2003 or so.

Re: Fighting Complexity in Software Development

#45
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.

"Started from Scratch". I have never seen any project where something has been started from scratch actually turn out well.

People are going to jump on the imprecise wording here but this is generally correct. People need to be very wary of "let's just throw this out and start over". There are cases where it makes sense, but 95% of the time it amounts to "the old code is complicated and it's a lot more fun to start over than it is to figure out the old stuff some other guy wrote". The old code is complex because it actually works and has taken the punches of production deployment.

Most often, people start down this path bright-eyed and bushy-tailed, and end up realizing after about 4 months that actually all that complication was doing something pretty useful. People need to be careful before they dismiss real working-in-the-wild code.

Re: Fighting Complexity in Software Development

#46
post #17

Earlier quoted context omitted.

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.

Couldn’t agree more. I was part of a $30 million Rails project that got unmanageable and burned after 2-3 years. Golang is so much more forgiving to human error.

30M. Well there’s your problem. I can just imagine the premature optimizations and the bloated abstraction that went in the planning phases.

Re: Fighting Complexity in Software Development

#47
post #42

Earlier quoted context omitted.

if I pick up an old Java project, it might be a mess, but I'll be able to rename methods, refactor classes, and upgrade libraries until it gets into shape - and I'll have a fair amount of confidence that it'll keep working while I do that, because metaprogramming is rare, APIs are fairly stable, and the IDE will mostly be able to understand what the code is doing. In a ruby project - especially in a Rails project - y…

> metaprogramming is rare In Java? Not really. Spring has been around since 2003 or so.

I guess he was referring not to metaprogramming in the common sense, but to the change of behaviour of built-in methods and classes.

Re: Fighting Complexity in Software Development

#48
post #30

Earlier quoted context omitted.

Without experience, tools don't matter. A skilled developer will most likely write better code regardless of language/framework. It's a repeating pattern in this society, fools with advanced gear doing what fools do best.

I'd argue that no matter how "good" you are, you are capped at what tools you're using. Consider using a hammer against a pneumatic tool. A newbie will hose you with better tools, they're wielding that condensed knowledge at their hands, their sum overshadow yours with only a hammer.

To a degree. Python has plenty of advanced features that I have rarely used. 20% of the language gets used 80% of the time.

Re: Fighting Complexity in Software Development

#49
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…

When you mention "no tooling (Haskell)" what do you mean? I am using Haskell (mostly for hobby projects) and am wondering what I am missing out on, since I feel the tools available is sufficient.

Re: Fighting Complexity in Software Development

#50
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…

> competing half finished implementations (lisp)

As well as one of the most complete specifications in ANSI Common Lisp.

Post reply on HN