Hacker News Reader

Comment by corresation | Hacker News Reader

This is one of those "why I am a great developer" sorts of posts that allows people to pat themselves on the back and congratulate each other on how great they are, passive-aggressively sending it out to the team in hopes of denigrating some team member who likes newer things. In this case "judgement" means "uses the things that I know", and there seems to be little evaluation beyond that high-level use case.

Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because.

View on HN

From a management perspective, it is easier to hire competent new employees for established, popular technologies.

Employees don't stay around for long anymore, especially dynamic, innovative employees who stay up to date on the newest technologies. People like that get recruited away all the time. Then who's going to maintain your bleeding-edge system? How long will it take to hire another employee of the same caliber?

If you're a top company who can afford to recruit and keep the best employees, then by all means, build on the latest and greatest. There is certainly nothing inherently wrong or unmaintainable about technologies just because they are new.

But if you're a medium or middling company with significant turnover in the tech ranks (i.e. most companies), then it's probably safer to build with the most popular, "standard" tech you can get away with.

I hated this perspective as a 22 year old when my (prior) company practiced it, but I can see the wisdom of it now. Not everyone should be on the bleeding edge, or even leading edge. It's important for both employers and employees to be on top of how close to the edge the firm chooses to be.

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

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.

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.

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

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.

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.

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.

and what might i ask is wrong with sinatra?

> Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because.

> The result was a combination of Google Protocol Buffers, node.js, and Cassandra. Elegant, scalable, and totally unmaintainable.

If I can venture a guess, Jack went ahead (without asking further questions, as opposed to Dianne) and took what was very hot at that time.

2 years ago, Node.js was extremely hot, in a sense that it was the new thing that somehow combined the hot javascript and made something easier. I remember my collegate excitedly talking about the amazing serverside javascript.

I don't know about Google Protocol Buffers and Cassandra but I assume they were what the author had in mind as 'very-hot-but-not-widely-used-yet', and most technology that fits such description generally falls into 'not-reliably-stable' and 'not-many-resources-yet' category.

Think how you would do Java EE without help of Javadoc.

I got the same feeling as you niuzeta, and I feel the article may be getting judged a little too harshly (although I find the assertion of this being the best quality in a developer a little too absolute for my tastes).

I think the author stated in the article that the fictional character Jack ".. makes a point of starting each project with at least three new technologies."

I personally understand this as three new technologies Jack has not previously worked with, which should be a definite indication of some risk/unknown factors. Plus given the context of this fictional scenario, it seems unlikely that other developers associated with the project/company know them.

Now if everyone were so conservative that they'd never try anything new, there would never be any progress, but I think the point of the article is that something isn't better, just because it is new. In fact, to me the rings of the "worse is better" philosophy which I didn't think was taboo in any way here on HN :-)

Finally I'd like to add that the author didn't say this was a "maintenance nightmare", he did however say the solution was elegant, scalable and totally unmaintainable.

>Finally I'd like to add that the author didn't say this was a "maintenance nightmare", he did however say the solution was elegant, scalable and totally unmaintainable.

Which is impossible, right? If it's elegant, it's maintainable. That's part of the definition of elegant software. A on liner that does amazing things, that very few people understand is not elegant. The same thought scales up to a whole solution IMO.

> In fact, to me the rings of the "worse is better" philosophy

Which is typically pushed by worse developers. How coincidental!

> Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because.

Because apparently the author didn't have the necessary skills to maintain it. Cassandra isn't easy to master, especially if you only have cheapo developers who are reluctant to switch to PostgreSQL from MySQL.

But yes, it's a highly opinionated, narrow-minded piece.

Whenever somebody lists the traits of great developers the number one trait is invariably: "They're like me."

I'll cut the author some slack here though since the article is over two years old by now.

Having only used Oracle, MSSQL, and MySQL, I can't imagine a small 500-user app would be that hard to implement in in Postgre even if I'd never touched the platform before - does Postgre have some terrifying gotchas, or does it work as a reasonably well-behaved SQL server? That is, if I naively installed a PostgreSQL server on my box and started creating tables and indexes and users, would I be destroyed by some horrible gotcha as I failed to account for some critical config (like selecting the right storage engine in MySQL)?

It's my understanding that there are no config gotchas in PostgreSQL (unlike MySQL). I've definitely found it more of a pain to set up at first. This is because the default role is very restricted and defaults to safe.

As someone who moved from MySQL to Postgres, the only thing that took some getting used to was users being actual Unix users that you create and then grant access to. At the time it seemed odd considering what MySQL did but it ended up being a feature I like quite a bit.

PG roles are stored in the DB, not Unix. You can set up pg_hba to use ident authentication so that users are automatically granted access by their Unix login, but it isn't the default (and usually not recommended), and you still have to have PG roles in the database for them to correspond to. So I think there's been a misunderstanding.

They're similar, but there are some pitfalls you need to be aware of: count(*) optimisation in mysql for example. Different behaviour in the query optimiser. Most cases are easy to handle, but if you're used to mysql, there's still a learning curve.

Agreed. If anything the number one trait of a developer is that they solve problems. However, that is not unique to developers and is required of non-technical people as well. What it means to be good at solving problems seems largely context-dependent to me, but if you are really good at solving important problems in a valuable domain you are great at that thing (developer or not).

> Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because.

Maybe this article will shed some light:

http://www.xaprb.com/blog/2010/05/10/the-manager-programmer-...

Such an argument would be rich coming from someone building a solution on Ruby. Indeed, such arguments essentially limit your technology choices to Oracle, SQL Server, or DB2, with an app layer built on .NET or J2EE.

Reply on news.ycombinator.com