On software popularity • Hacker News Board

Re: On software popularity

#51

Post by dkersten » Thu, Apr 09, 2015, 5:50 PM UTC

chongli wrote: post #37

beat wrote: post #30

Earlier quoted context omitted.

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…

I'm not merely talking about junk redundant code but entire classes of problems such as memory errors (null pointers etc.) and race conditions (in many, though not all, cases). If you compare software engineering to another field like aerospace or structural engineering it's laughable how little rigour and formality takes place in most software. It's shocking how much disdain programmers show for mathematics which gi…

It's shocking how much disdain programmers show for mathematics which gives us the tools to prove that our applications are correct.

I personally think these things are great but too expensive. My customers care about solving their problems not perfection. There's a balance to be struck and I'm not excusing bad software, but if the customer isn't willing to pay for better and is happy with the current quality, there is little incentive to put in this extra effort (and therefore cost) when the resources could instead be put to work on providing value in ways the customer does care about.

I guess after you exceed the customers quality requirements/expectations, there are diminishing returns.

I'd love to produce perfect software, but nobody will pay me to do it.

Re: On software popularity

#52

Post by serve_yay » Thu, Apr 09, 2015, 5:52 PM UTC

meistro wrote: post #25

serve_yay wrote: post #22

Earlier quoted context omitted.

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.

> It depends on the size the library.

Haha, indeed it does.

Re: On software popularity

#53

Post by marcosdumay » Thu, Apr 09, 2015, 5:55 PM UTC

kelseydh wrote: post #43

JustSomeNobody wrote: post #39

Earlier quoted context omitted.

Yes. However, software companies that hire for a specific popular tool/framework need to be punished with mediocrity.

Why? If I'm running a business and I intersect closely between the business side and software side of the company, but need help on the side. I'm hiring for the stack that I use and already understand. It's not mediocrity, it's called playing to your advantages.

Your problem is, you are hiring for a "stack", not for competence.

For the developers that go out of their way to learn a tool only because people like you will hire him, their problem is that they'll be hired by people that hire by a "stack", and not by competence. Jobs that select this way normaly place a negative value on competence, and the developer will face the choice of adapting and become mediocre, or going away and losing some short term benefit.

Re: On software popularity

#54

Post by beat » Thu, Apr 09, 2015, 6:10 PM UTC

chongli wrote: post #37

beat wrote: post #30

Earlier quoted context omitted.

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…

I'm not merely talking about junk redundant code but entire classes of problems such as memory errors (null pointers etc.) and race conditions (in many, though not all, cases). If you compare software engineering to another field like aerospace or structural engineering it's laughable how little rigour and formality takes place in most software. It's shocking how much disdain programmers show for mathematics which gi…

Ah, you're thinking down at the lines-of-code level. I'm thinking at a much higher, big-project requirements level. It's hard to say which one is worse.

I do, however, think there's a "which kneecap" problem to rigor as well. Rigor isn't free - it comes with costs, in learning curve, in the quality of developer required, etc.

I've been bouncing back and forth between not-rigorous Ruby, kinda-rigorous Go, and pseudo-rigorous Java. I don't think rigor is a killer solution, nor do I think it's a gruesome waste of time. But I find the really ugly problems to be at the requirements and architecture level, not the code level. Not surprising, considering coding isn't my primary work.

Re: On software popularity

#55

Post by chongli » Thu, Apr 09, 2015, 6:13 PM UTC

dkersten wrote: post #51

chongli wrote: post #37

Earlier quoted context omitted.

I'm not merely talking about junk redundant code but entire classes of problems such as memory errors (null pointers etc.) and race conditions (in many, though not all, cases). If you compare software engineering to another field like aerospace or structural engineering it's laughable how little rigour and formality takes place in most software. It's shocking how much disdain programmers show for mathematics which gi…

It's shocking how much disdain programmers show for mathematics which gives us the tools to prove that our applications are correct. I personally think these things are great but too expensive. My customers care about solving their problems not perfection. There's a balance to be struck and I'm not excusing bad software, but if the customer isn't willing to pay for better and is happy with the current quality, there…

I personally think these things are great but too expensive. My customers care about solving their problems not perfection. There's a balance to be struck and I'm not excusing bad software, but if the customer isn't willing to pay for better and is happy with the current quality, there is little incentive to put in this extra effort (and therefore cost) when the resources could instead be put to work on providing value in ways the customer does care about.

I didn't say you had to do all of this yourself. I don't believe every programmer has to have a degree in mathematics. Where I take issue is with the refusal to take advantage of the hard work of others. There exist languages, tools and libraries which have a strong mathematical basis that are ignored in favour of the latest fad. Places like stackoverflow are full to the brim with people asking for help solving problems that they wouldn't have to deal with if they'd chosen better tools.

Re: On software popularity

#56

Post by mgkimsal » Thu, Apr 09, 2015, 6:16 PM UTC

beat wrote: post #23

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

Another problem (not you doing it) is quoting a Joel Spolsky article from 15 years ago saying "don't ever rewrite from scratch". NEVER ever accepting a rewrite, based on someone's experience in a different field... that's also a bad situation.

About 20% of the projects I've dealt with would have been measurable (by pretty much every measurement you can come up with) by a complete rewrite. One of the commonalities I noticed is no one from the original technical team was still around. The notion of losing "institutional knowledge" about the code goes out the window at that point - it's already lost. You now have new people now just adding on more crap (or fixing crap) without ever even knowing why it was crap in the first place.

If someone only wants to keep their systems running - that's 100% fine - no need to rewrite. If the org expects new functionality on a regular basis, and there's no one who truly understands any of the current code, a rewrite may make sense.

Re: On software popularity

#57

Post by soveran » Thu, Apr 09, 2015, 6:20 PM UTC

matthewmacleod wrote: post #41

It's an interesting thought. I'm primarily a Ruby developer. Literally every single time I've started a web-oriented project using something like Sinatra or Padrino etc., I've ended up regretting it. I end up building a shitty, half-featured, buggy version of Rails. My experience is that most other projects end up the same. I suppose mileage may vary; perhaps it's easier to write bloated apps in Rails. I'm not convin…

My experience is the opposite, I agree it may vary from person to person. Care to elaborate what went wrong in those projects?

Re: On software popularity

#58

Post by 0xdeadbeefbabe » Thu, Apr 09, 2015, 6:44 PM UTC

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…

This is an insult to horses, cars, and even tribes.

Re: On software popularity

#59

Post by Terr_ » Thu, Apr 09, 2015, 6:52 PM UTC

hasenj wrote: post #48

abvdasker wrote: post #34

Earlier quoted context omitted.

One of the problems with popularity is you will get a lot of mediocre developers who don't know what they are doing. You know, the people who pick up tools only because they think it will land them a job more easily. The same people who picked up VB. I understand that you're saying it's a bad practice to adopt a tool for reasons other than its utility in addressing a specific problem. But is it really so terrible for…

What I'm actually saying is a bit more subtle. There are types of developers who are very limited in what they can do. They learn some basic "tricks" in the form of "If write this magic spell, I get this magic result". These are the mediocre developers. They tend to pick some popular tool and try to market themselves as "an X developer" where X is something that's popular right now. Then there are developers who can…

"Watch out for script-kiddies."

Re: On software popularity

#60

Post by 0xdeadbeefbabe » Thu, Apr 09, 2015, 6:59 PM UTC

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…

After reading that I feel about as lost as I did after that XKCD about correlation and causation https://xkcd.com/552/ Also, just because your comment is popular does not mean your comment is good.

The popularity heuristic may be a little better than the OP suggests though, maybe.