Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:fees (Score 1) 382

by jythie (#49150921) Attached to: Verizon Posts Message In Morse Code To Mock FCC's Net Neutrality Ruling
I take it you did not live in one of the regions that had DSL covered under Title II? The number of options and price ranges were far wider than today since Verizon was required to lease its lines, allowing 3rd parties to actually exist. When the FCC pulled them off the regulation, competition and options vanished almost overnight.

Comment: Re:Not-Good-Enough Syndrome (Score 1) 151

by jythie (#49148563) Attached to: Invented-Here Syndrome
The problem with elegant code is more often than not 'elegance' is rooted in how similar it is to what the reader has read before as opposed to objective measures. One only has to go to a meeting where people argue about what coding standard a project should use to see 'but this is so much more readable!' is all its arbitrary glory.

Comment: Re:Quality of the solution. (Score 1) 151

by jythie (#49148541) Attached to: Invented-Here Syndrome
While I would not describe it as a religious issue, I would describe it as a cultural issue just as much as an experienced/engineering one. Experience is rooted in what has been done, so often it can be pretty reactionary regarding what mistakes have gone out of style and which ones have been forgotten long enough to be acceptable again.

This is why I tend to point to Java's dependency injection as an example of the pendulum swinging too far the other way. Much of it was developed as a reaction to what was being done at the time, but also in the faded memories of what was done before that...

Comment: Re:About time... (Score 1) 151

by jythie (#49148459) Attached to: Invented-Here Syndrome
I think the key piece is 'it depends on what you are writing'. Use of 3rd party solutions or internally developed ones is something that needs to be evaluated on a case by case basis, with various cultures and companies within tech, all too often, defaulting to one path or the other. I tend to feel that the pendulum has swung a bit too much, with 'not invented here' becoming such a boogie man that an increasing number of projects and defaulting to using external dependencies unless you can justify breaking away from that.

Comment: Re:Quality of the solution. (Score 1) 151

by jythie (#49147847) Attached to: Invented-Here Syndrome
Yep, you are that old ^_~

In modern development one can go through an entire project without using any of the language's standard libraries or even, in extreme cases, the language itself. If you ever want to see a frightening example of this gone too far, take a look at over uses of Apache Camel or even Spring, where you can write entire systems using code embedded in XML files and that weird 'conditional logic as constructor arguments' camel allows for.

Comment: Re: About time... (Score 2) 151

by jythie (#49147801) Attached to: Invented-Here Syndrome
Sadly, it did not take a day. I really felt that the solution was not only more complicated but took longer to implement and test than the internal coding option would have. Granted the two approaches were not tried in parallel, but the amount of time and effort that was eaten up by taking the dependency injection route seemed quite excessive given the complexity of the problem being solved.

Comment: Re:About time... (Score 5, Interesting) 151

by jythie (#49147677) Attached to: Invented-Here Syndrome
One example that really drove me crazy was a developer who was tasked with putting in a 'retry' mechanic. Rather than simply working with the socket he pulled in some spring library that altered the socket behavior according to an external XML file and was praised by the lead for doing it this way. The code (java + XML) was several times longer than it would have been otherwise, plus a new library had to be included in the build/distribution, but it was still 'proper'. I think that was the breaking point for me working on that project.

Comment: About time... (Score 5, Insightful) 151

by jythie (#49147625) Attached to: Invented-Here Syndrome
I do not see this topic brought up nearly as much, which worries me. I have worked on quite a few projects where the unwillingness to write functionality internally lead to excessive testing of external options and overuse of generic frameworks which not only increased the dependency/complexity of the project but often required just as many lines of code to use as just writing our own damn module would have.

It feels like this is worst in the Java (enterprise) community, but that could be my imagination. Sometimes I think those programmers need their 3rd party instantiation taken away from them....

And crap, looks like I have been moved over to slashdot-beta so I will probably never see if I get responses....

Comment: Re:Ha (Score 1) 45

by jythie (#49139377) Attached to: The Believers: Behind the Rise of Neural Nets
What does being in the computer industry for 20 years have to do with knowing the history of CS? Very few CS programs have any coursework on history, and it is not a topic that is highly covered in industry. Working in tech might give one a default knowledge of products and technologies developed during their time in industry, but even that is going to be limited to a person's specific subdomain unless they are actually independently interested in learning deeper history.

Simplicity does not precede complexity, but follows it.