6 ms·

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

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.

mwcampbell 13y ago
> 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-face-off-over-nosql/ http://www.xaprb.com/blog/2010/05/10/the-manager-programmer-...
- corresation 13y ago
  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.
niuzeta 13y ago
> 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.
- steinnes 13y ago
  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.
  - _pmf_ 13y ago
    > In fact, to me the rings of the "worse is better" philosophy Which is typically pushed by worse developers. How coincidental!
  - jaegerpicker 13y ago
    >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.
seclorum 13y ago
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 13y ago
  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.
  - seclorum 13y ago
    .. 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 ..
lazyjones 13y ago
> 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.
- mtrimpe 13y ago
  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.
- Pxtl 13y ago
  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)?
  - skyebook 13y ago
    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.
    - fusiongyro 13y ago
      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.
snowwrestler 13y ago
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.
- mathattack 13y ago
  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.
asabjorn 13y ago
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).

mwcampbell 13y ago

> 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-face-off-over-nosql/ http://www.xaprb.com/blog/2010/05/10/the-manager-programmer-...

corresation 13y ago
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.

niuzeta 13y ago

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

steinnes 13y ago
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.
- _pmf_ 13y ago
  > In fact, to me the rings of the "worse is better" philosophy Which is typically pushed by worse developers. How coincidental!
- jaegerpicker 13y ago
  >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.

seclorum 13y ago

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 13y ago
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.
- seclorum 13y ago
  .. 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 ..

lazyjones 13y ago

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

mtrimpe 13y ago
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.
Pxtl 13y ago
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)?
- skyebook 13y ago
  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.
  - fusiongyro 13y ago
    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.

snowwrestler 13y ago

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.

mathattack 13y ago
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.

asabjorn 13y ago

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