The One in Which I Call Out Hacker News (2009)(bitquabit.com)
bitquabit.com
The One in Which I Call Out Hacker News (2009)
http://bitquabit.com/post/one-which-i-call-out-hacker-news/
13 comments
This sort of thing is a good indication of the technical maturity level of a programmer. Over simplifying the design of software and "feature list" thinking are perfect examples of technical immaturity and naivete. Even a very simple system with a small number of moving parts requires a lot of skilled and subtle work in order to ensure it works reliably, at the appropriate level of performance, and in a way that is usable. In a way good programmers make it more difficult for younger programmers to notice these things, since an elegant design might reflect innumerable man-hours of careful decision making and improvement but it works so well and so smoothly and with so few parts that it can seem almost trivial.
When someone sees a line of code such as the classic "fast inverse square root" it's obvious that it's necessary to take a step back, to realize that you're not going to understand the depths of what's going on intuitively, that there is likely a lot of deep optimization and balancing going on with that code. But when we see code that doesn't have a big clanking WTF in the middle of it, when we see code that seems to make intuitive sense, we don't tend to ponder the optimization and tradeoffs that went into it. But in truth those can be just as deep and just as profound for ordinary looking code as for obviously clever stuff. That goes double when you only use the software.
Consider a thought experiment: replicating google. The naive answer is that it's easy, all you need is a big DB, a web crawler to load up the DB, and a search frontend. And that might work, but it would be terrible. It would be horrendously expensive and produce profoundly disappointing results with even more profoundly disappointing performance. From an end-user perspective google is simple, but the complexities and the elegances underneath are the important bits, and those are much more challenging to replicate.
When someone sees a line of code such as the classic "fast inverse square root" it's obvious that it's necessary to take a step back, to realize that you're not going to understand the depths of what's going on intuitively, that there is likely a lot of deep optimization and balancing going on with that code. But when we see code that doesn't have a big clanking WTF in the middle of it, when we see code that seems to make intuitive sense, we don't tend to ponder the optimization and tradeoffs that went into it. But in truth those can be just as deep and just as profound for ordinary looking code as for obviously clever stuff. That goes double when you only use the software.
Consider a thought experiment: replicating google. The naive answer is that it's easy, all you need is a big DB, a web crawler to load up the DB, and a search frontend. And that might work, but it would be terrible. It would be horrendously expensive and produce profoundly disappointing results with even more profoundly disappointing performance. From an end-user perspective google is simple, but the complexities and the elegances underneath are the important bits, and those are much more challenging to replicate.
"In a way good programmers make it more difficult for younger programmers to notice these things, since an elegant design might reflect innumerable man-hours of careful decision making and improvement but it works so well and so smoothly and with so few parts that it can seem almost trivial."
"[W]hen we see code that doesn't have a big clanking WTF in the middle of it, when we see code that seems to make intuitive sense, we don't tend to ponder the optimization and tradeoffs that went into it. But in truth those can be just as deep and just as profound for ordinary looking code as for obviously clever stuff. That goes double when you only use the software."
Yes, yes, a thousand times yes.
I want to write more, but in those two quotes you've managed to articulate something that I've been thinking about quite a bit recently.
Good software doesn't seem good. It is invisible.
"[W]hen we see code that doesn't have a big clanking WTF in the middle of it, when we see code that seems to make intuitive sense, we don't tend to ponder the optimization and tradeoffs that went into it. But in truth those can be just as deep and just as profound for ordinary looking code as for obviously clever stuff. That goes double when you only use the software."
Yes, yes, a thousand times yes.
I want to write more, but in those two quotes you've managed to articulate something that I've been thinking about quite a bit recently.
Good software doesn't seem good. It is invisible.
I feel like the OP here is making two arguments, one of which I agree with whole-heartedly, and one that I disagree with vehemently.
The first argument seems to reduce to the same basic idea entailed in expressions like "The first 90% is easy, it's the second 90% that gets you". Or "the devil is in the details". That I totally agree with. The seemingly trivial, small details absolutely add up and constitute a TON of working in getting a system into a truly "finished" and polished state.
But the second argument seems to amount to what I find to be a tired and inaccurate meme - "Open source software sucks because developers don't think like end users". OK, to be fair, some Open Source software does, indeed, suck at UI and usability, and maybe it is because most developers aren't good at UX. But by no stretch of the imagination does this apply to all (or maybe even "most") OSS, and also, it's hardly the case that proprietary software is necessarily better in this regard. Have you used, for example, Oracle's back-end / financials software? F%#@ that... Hideous (or at least it was last time I used it).
All of that said, this issue is near and dear to my heart, because this is something we think a lot about at Fogbeam. Luckily one of our founders is a designer and UI/UX specialist, so we have a leg up on some other open source projects. And while we don't have the clean UI and the awesome UX we want just yet, we aren't finished either. Our commitment is to absolutely nail User Experience, and be better than anybody else in our space, Open Source OR proprietary. Yes, we still have a lot of work to do, but that's the goal.
The first argument seems to reduce to the same basic idea entailed in expressions like "The first 90% is easy, it's the second 90% that gets you". Or "the devil is in the details". That I totally agree with. The seemingly trivial, small details absolutely add up and constitute a TON of working in getting a system into a truly "finished" and polished state.
But the second argument seems to amount to what I find to be a tired and inaccurate meme - "Open source software sucks because developers don't think like end users". OK, to be fair, some Open Source software does, indeed, suck at UI and usability, and maybe it is because most developers aren't good at UX. But by no stretch of the imagination does this apply to all (or maybe even "most") OSS, and also, it's hardly the case that proprietary software is necessarily better in this regard. Have you used, for example, Oracle's back-end / financials software? F%#@ that... Hideous (or at least it was last time I used it).
All of that said, this issue is near and dear to my heart, because this is something we think a lot about at Fogbeam. Luckily one of our founders is a designer and UI/UX specialist, so we have a leg up on some other open source projects. And while we don't have the clean UI and the awesome UX we want just yet, we aren't finished either. Our commitment is to absolutely nail User Experience, and be better than anybody else in our space, Open Source OR proprietary. Yes, we still have a lot of work to do, but that's the goal.
Yeah I totally agree. There is tons of very high quality open source software. Some of the designs I have encountered while looking at the source code is breathtaking. I think more code monsters lurk in propriety code, its just in the commercial world they are good at paint jobs.
Not to mention I have to question anyone that is saying a Microsoft product is more usable than literally anything. I look at IIS vs Apache || Nginx daily and IIS severely irritates me.
It's entertaining to me that the google code repo created for the purpose of cloning Stack Exchange "in a weekend"[1] contains nothing.
The 3 issues are kind of funny as well.
http://code.google.com/p/hackerexchange/source/browse/#svn
The 3 issues are kind of funny as well.
http://code.google.com/p/hackerexchange/source/browse/#svn
I know there is probably an actual definition of the 80/20 rule somewhere, but here's my interpretation, which I think gels with the article. 80% of the work is done quickly , which is the absolute core stuff, with 0 polish and full of edge-case data and interface bugs. Then the last 20% of the work takes roughly equal to the first 80%. The percentages have nothing to do with actual work completed or time spent, rather how complete it looks to the client/your boss/someone with no details of the technical implementation.
And that's only to get to 1.0. Some of these features would be unnecessary for launch but should be added post-launch, e.g., the editor imo.
EDIT: Looking it up there is an 80-20 rule that I think is in a similar vein but if applied properly to this situation would say that 80% of the work exists in 20% of the features.
Which may even be true sometimes.
And that's only to get to 1.0. Some of these features would be unnecessary for launch but should be added post-launch, e.g., the editor imo.
EDIT: Looking it up there is an 80-20 rule that I think is in a similar vein but if applied properly to this situation would say that 80% of the work exists in 20% of the features.
Which may even be true sometimes.
> The One in Which I Call Out Hacker News (bitquabit.com)
> 5 points by sebkomianos 25 minutes ago | flag | discuss
You probably want to put (2009) in the title somewhere...
> 5 points by sebkomianos 25 minutes ago | flag | discuss
You probably want to put (2009) in the title somewhere...
I was wondering why I couldn't find the post the author was referring to...
If you want some more context, I think that https://news.ycombinator.com/item?id=678501 was the inspiration for the blog post, in part because I have a rant attached to that comment.
As I recall there weren't a lot of 'clones' made.
My bad, I am not very familiar with the guidelines about submitting old pieces.
When a developer says "That looks/sounds easy; I could knock that up in a weekend!" about a project, they have to be especially more careful about who is within earshot.
Heaven forfend a manager type gets a whiff of an over-optimistic estimate -- that's a great recipe for a completely avoidable death-march.
Heaven forfend a manager type gets a whiff of an over-optimistic estimate -- that's a great recipe for a completely avoidable death-march.
I use such off-the-cuff estimates as red flags indicating developers who have likely never built anything scratch; the number of 10x devs who could do such projects "in a weekend" are small, and even then, they would still probably not make such claims with certainty.
I agree, it's easy to bust a sloppy pile of garbage that won't hold up load. It's hard to build a robust well engineered solution for millions. Good post, no matter when it was written.
Relevant xkcd:
http://xkcd.com/386/
http://xkcd.com/386/
He compares PostgreSQL (Open Source) to MS-SQL (Proprietary) for one feature (initial setup), but I don't see him comparing things like sqlplus (Oracle/Proprietary) to psql (PostgreSQL/Open Source).
What conclusion did you expect I'd draw, had I compared those two? I have zero experience with Oracle, and copious amounts with both PostgreSQL and MS SQL, so I was focusing on things I actually knew about.
I see nothing wrong with releasing an utterly bare-bones version, like the schema one he mentions, i.e. a MVP. Then, you polish over time. Even SO wasn't a SO clone at launch. (Of course, if someone promised a complete clone, that's foolish).
The big problem is that you can't get started on this upward curve, because no one will use it, since SO already exists and is far better. There's no oxygen.
[a different story if SO suddenly stopped meeting needs e.g. turned expertsexchange in cash-pursuit]
The big problem is that you can't get started on this upward curve, because no one will use it, since SO already exists and is far better. There's no oxygen.
[a different story if SO suddenly stopped meeting needs e.g. turned expertsexchange in cash-pursuit]
You wouldn't really describe this guy as a "can do" sort of person, would you?
I'd describe him as someone who has actually been around the block, as the saying goes. Compare that with this:
https://news.ycombinator.com/item?id=6486142
Kinda speaks for itself.
https://news.ycombinator.com/item?id=6486142
Kinda speaks for itself.
It's my turn to call out Hacker News now. How did a submission from 2009 that isn't really relevant now as it was in reference to comments made on Hacker News back in 2009 make it to the homepage? I'll sit back and watch people bite though. And for the record, I know there were numerous clones of SO made. Probably not in a weekend, but come on, the hardest part about Stack Overflow isn't how it is coded, it's scaling the site up for the millions of views it probably gets on a daily basis. You can build a clone of Stack Overflow using Wordpress with Buddypress, a Markdown plugin, JSON API plugin and the Cubepoints plugin.
Articles like this always make me laugh, especially when talked 4 years after they were written.
Articles like this always make me laugh, especially when talked 4 years after they were written.
Lets disregard the age of the article for one moment. I think that the author is making a good point, developers oversimplify applications and when they begin to work it turns out that it's a hundred times more complicated then initially thought. Very valid.
The hardest bit by far is getting traction.
I find it amusingly ironic that a post which is calling people out on casual ignorance and dismissal of the effort that goes into other people's software makes its point by... casual ignorance and dismissal of the effort that goes into other people's software.