[seclorum]

Yeah, I agree with you: 'just because' .. the author of the article doesn't know anything about protocol buffers, node.js and Cassandra. Probably because those things are 'too new' and 'not proven' technologies - to him.

But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes!

I recently had to make a bid on a project that would give the users the ability to share their works, produced in an embedded environment, with their communities - a "Cloud" for the users. I designed the system architecture of the embedded system to be as self-maintainable as possible, and as simple as possible. Since its an embedded OS environment that the users would be using, instead of writing code I integrated such tools as git, and designed a system topology that would allow the user to be shielded from all the git hassle, while still getting a push-button experience.

I lost the gig to someone who decided that it would be better to re-invent "topography ordering" (his words) in a custom MySQL+PHP application, and when I was given an opportunity to challenge his design, I said "great, you're going to re-invent Git, poorly".

He spent the rest of the day "pissed that you compared his project to .. GitHub", which is what he thought I meant when I said "git". Nope, I said "git", I mean "git" - not 'github'. He actually didn't know how to use git.

Either way, off they go .. re-inventing the DAG with MySQL+PHP in an embedded environment, when they could've just wrapped the feature in a git script ... yikes++!

So this article just demonstrates to me that there are a lot of blow-hards out there who just don't get why its so important to apply the NIH principle to themselves, not just others ..

[Amadou]

But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes!

Except that isn't really an option in most cases.

The two most realistic choices are: Take over a high-quality implementation using somewhat stale tools or an average to shoddy implementation with newer tools that the developer was learning on the fly.

[dustingetz]

Coming from a functional programming perspective on code quality, I think new code written with a modern understanding of software engineering generally is better quality than old code backed by tech written with last decade's understanding.

[seclorum]

.. or, take over a project that was done by a competent developer who knew what they were doing and were able to communicate that knowledge through their codebase to anyone else who might pick up the project later on - which is the real #1 Trait of a great developer, whatever technologies they're using ..

[jaegerpicker]

The quality of an implementation is rarely tied to the tools except in extreme cases. A good Developer in general builds good solutions no matter the toolset. A good python developer is likely to become a good Objective-C developer if they invest the time to learn and because they understand the need for clean modular code the iOS code is likely to turn out pretty well.

[corresation]

Take over a high-quality implementation using somewhat stale tools or an average to shoddy implementation with newer tools that the developer was learning on the fly

My experience has been that developers who are most interested in innovations in this industry are dramatically more likely to build better solutions -- the passion and interest cuts both ways. Versus the career developer who does the absolute minimum necessary.

But of course with any given situation and set of developers your mileage will vary (I've known on-the-edge developers who build ridiculously nice code, and hanging-two-generation-back coders who make disgusting code. And vice versa). This particular scenario bothered me because the nodejs / cassandra canards were propped up under the illusion that the only advantage they offer was nefarious "Web Scale". Only in reality for many projects they make it ridiculously efficient to build solutions. The same goes for Go right now -- there are practitioners who can build in moments what would have taken months on a, for instance, ASP.NET team.

[oinksoft]

My experience is that for every developer who adopts a new technology for its true merits, there are at least two others who use it only because it is at the top of Hacker News/Ruby Weekly/other trendy publication, and those developers take advantage of very few of the technology's benefits.

[epynonymous]

and what might i ask is wrong with sinatra?