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

On software popularity

soveran.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: On software popularity

#21

Post by beat »

j03m1 wrote: post #16
beat wrote: post #13

It's turtles all the way down. Using a lightweight, comprehensible framework is good, until you hit the limits of that framework and start pulling in lots more libraries to fill the gaps (the Sinatra/Cuba world). Using a heavyweight, complete library is good, until you start suffering from bugs caused by incomprehensible magic buried deep inside (the Rails world). I see the same problem in microservices versus monoli…

Which knee do you want to get shot in is the best way I've heard this explained. Ever.

"I don't believe in the no-win scenario." -Captain Kirk

A lot of the problems we face in software engineering are Kobiyashi Maru tests. They're no-win scenarios, tests of character rather than ingenuity. There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another.

Re: On software popularity

#22

Post by serve_yay »

meistro wrote: post #18

I don't remember his name, but one of the creators of Angular said (paraphrasing) "When choosing between libraries and in doubt, choose the one that has more testing in place". This is something I've personally found true the majority of the time.

Which kind of testing? Is it better for a library to be in wide distribution and therefore battle-tested but without unit tests, or to be unpopular but full of unit tests?

Re: On software popularity

#23

Post by beat »

mcguire wrote: post #14

" That didn't prevent further criticism, and many comments followed recommending Rails and Sinatra as alternatives based on familiarity and popularity. " Ah, the "industry standard" argument, where industry standard seems to be defined as "whatever I've read the most blog posts about", or "whatever was used at my last job", or possibly "what I learned in school (last year)". One of my major dissatisfactions is newly…

The problem with stepping into legacy systems from the outside is the "Wow, this all sucks, let's do it over!" thing. Experienced engineers who have dealt repeatedly with the ball of mud (hopefully) learn that completely restructuring legacy code is, at least, a dangerous endeavor, with no guarantee of success. The really good ones know that the unknown unknowns are lurking in that muddy swamp and can swallow development teams whole. Sometimes, that tangle of spaghetti code is actually a cage for a dangerous monster.

Part of the reason the ball of mud is as ugly and messy as it is is because of repeated attempts to fix it, just getting absorbed into the structure. An application that was shaped by many different engineers and leads over many years can have a lot of different flavors of weird.

Re: On software popularity

#24

Post by gofishdigital »

j03m1 wrote: post #16
beat wrote: post #13

It's turtles all the way down. Using a lightweight, comprehensible framework is good, until you hit the limits of that framework and start pulling in lots more libraries to fill the gaps (the Sinatra/Cuba world). Using a heavyweight, complete library is good, until you start suffering from bugs caused by incomprehensible magic buried deep inside (the Rails world). I see the same problem in microservices versus monoli…

Which knee do you want to get shot in is the best way I've heard this explained. Ever.

Maybe there's a lot of meta commentary in "Arrow to the knee" afterall?

Re: On software popularity

#25

Post by meistro »

serve_yay wrote: post #22
meistro wrote: post #18

I don't remember his name, but one of the creators of Angular said (paraphrasing) "When choosing between libraries and in doubt, choose the one that has more testing in place". This is something I've personally found true the majority of the time.

Which kind of testing? Is it better for a library to be in wide distribution and therefore battle-tested but without unit tests, or to be unpopular but full of unit tests?

It depends on the size the library. I'm sure people will point to some outliers but I'd hard-pressed to find a large library that is both widely distributed and severely lacking in tests.

Re: On software popularity

#26

Post by t4nkd »

I find it pretty interesting that the only real concern was "can this team solve my technical problem using the best tools in the shortest amount of time" but did not seem to consider things like, "What happens when this team moves on". One of the biggest assumptions that I've made is that when choosing tools, choosing the most popular ones gives you the highest chance of bringing someone on board who already groks them, finding learning material, etc.

I seem to be noticing more often now that "the best tool for the job, for the person, at the time" is completely acceptable. I feel as though this didn't used to be the case, and I know a lot of more "established" engineers who believe it's naive to choose tools based on an inclination or personal/team preference. While in this case, we're getting less code in the dependency, I'm highly suspicious of how their working knowledge, method of code organization, etc... can be transferred over time.

Ultimately though, knowing what actually happened over time with this project would be the most interesting. Does he eventually find new team members who convince him to switch back to a framework that is more widely understood and practiced?

Re: On software popularity

#27

Post by chongli »

beat wrote: post #21
j03m1 wrote: post #16

Earlier quoted context omitted.

Which knee do you want to get shot in is the best way I've heard this explained. Ever.

"I don't believe in the no-win scenario." -Captain Kirk A lot of the problems we face in software engineering are Kobiyashi Maru tests. They're no-win scenarios, tests of character rather than ingenuity. There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another.

There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another.

Right, but I'm not about to believe we're even close to that limit. Every day we have people writing bugs which, from a state of the art perspective, are already solved problems. It's like people are out there riding horses while others are driving past in their cars.

I think it's a little better to say that a lot of the problems we face in software engineering are cultural, not technical. So many people adopt these tribalistic mindsets when discussing their preferred technologies rather than allowing themselves to be open to better ideas.

Re: On software popularity

#28

Post by Roboprog »

stonemetal wrote: post #12
jingo wrote: post #5

That Knuth quote by itself is interesting. Perhaps he is not suggesting that popular ideas likely to be are wrong. Instead maybe he is saying that to think and develop ideas like Knuth's one needs a certain amount of irreverance for what is popular. (Undue?) reverance is rampant in the software industry, in my opinion. Would Knuth agree?

I think you are correct, I don't think he means popular ideas are likely to be wrong. Just more likely to be misused or misapplied. As in the linked article, they received a lot of advice to use rails not because it was the right tool for the job but because it was the popular tool for a vaguely similar job. Also no one had the knowledge to comment on their selected tool because it wasn't the popular tool.

As a developer in the "out-back" (California Central Valley / Sacramento area), I find it a bit funny watching somebody who gets to use Ruby (at all) angsting over which framework to use. At least they have escaped the XML-Hell trap that is JEE.

I'm happy for the guy that he gets to do anything at all beyond that which is promoted by Oracle or Microsoft. I suppose Google might belong on the list of "Promoters not to be Ignored", as well, but they haven't flogged the use of inappropriate hammers enough, yet.

Re: On software popularity

#29

Post by RyanMcGreal »

t4nkd wrote: post #26

I find it pretty interesting that the only real concern was "can this team solve my technical problem using the best tools in the shortest amount of time" but did not seem to consider things like, "What happens when this team moves on". One of the biggest assumptions that I've made is that when choosing tools, choosing the most popular ones gives you the highest chance of bringing someone on board who already groks t…

> but did not seem to consider things like, "What happens when this team moves on".

FTA:

> 3. Cuba itself is extremely easy to work with because it barely does anything. You can read the entire source in 5 minutes and understand it completely. I'm confident future teams could pick it up.

Re: On software popularity

#30

Post by beat »

chongli wrote: post #27
beat wrote: post #21

Earlier quoted context omitted.

"I don't believe in the no-win scenario." -Captain Kirk A lot of the problems we face in software engineering are Kobiyashi Maru tests. They're no-win scenarios, tests of character rather than ingenuity. There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another.

There's a certain irreduceable complexity to all interesting problems, so at some point, you're not solving complexity, but merely pushing it from one place to another. Right, but I'm not about to believe we're even close to that limit. Every day we have people writing bugs which, from a state of the art perspective, are already solved problems. It's like people are out there riding horses while others are driving pa…

Sure, there are lots of projects that are cranking out junk redundant code on legacy systems. But even if you do use the best tools, the best processes, the best analysis, the irreduceable complexity remains.

For example, I have to read data from one source, and write it to another. I can have a single app provide api for both the writing source and the reading source, or I can have two separate apps and two separate apis. But I can't get away from the problem of reading and writing. That's irreduceable. If I have separate apps for the two apis, I have a configuration management issue. If I have a monolithic app that does both, I have a coupling issue.

Imagining that Bleeding Edge Technology of the Month will make this go away is wishful thinking. But facing the truth is awful, so we choose the wishful thinking.

Post reply on HN