bitquabit: bitquabit - The One in Which I Call Out Hacker News
litwol
· 5 months ago
Some of my thoughts:
I've extracted my own conclusions from the article, but for the sakes of continuing a conversation [for my own benefit to understand things better] i would like to argue that developer arrogance is a product of poor skill of managing client expectation; perhaps often not developer's fault. Arguably client expectations should be managed by a more senior developer, but the same mistakes can be made regardless of the title held. I would argue that client should recognize that how questions are asked with regards to development effort estimations ultimately lead to how developer answers those questions.
I will attempt to provide example of what i am trying to say:
If a client simply asks "how much effort would it take to clone StackOverflow?", the developer's response will be very much shaped by his very limited (or not so limited) experience with StackOverflow. Here point being the amount of variability due to developer's user experience with StackOverflow.
On the other hand if client asks "How much effort would it take to clone StackOverflow without compromising any existing user experience, infrastructure, upgrade paths and _______ (insert what ever other component that is truly relevant)", will produce much different behavior from the developer. Such question leads developer to put some context around the task as well as evaluate his own knowledge of those components and potentially force them to research any grey areas in their knowledge of the mentioned components as well as relating components before answer is given. Client should realize that the way questions are asked will lead to a different answer from the developer. it is also very important to note that people are not mind readers and different cultural and life experiences lead people to understand meanings of sentences differently unless formatted very explicitly to eliminate as many variable factors as possible.
Unfortunately there are no single point of failure that we can all avoid to overcome the problem. Fortunately people that have lived through this or simply understand this psychology will tend to recognize when communication is failing due to those *variable* factors and attempt to correct themselves to communicate differently.
High level of productivity is achieved when both parties are on the same wavelength. Some productivity is possible when one person attempts to compensate by leading questions. no guaranteed productivity is possible when both parties do not understand this notion (only chance possible). It is a two way road. Both sides must ask themselves two questions 1) Am i being understood according to what i am trying to say? and 2) do i understand the other person according to what he/she trying to tell me?
In an attempt to avoid leading the question i am concluding the above thoughts without a conclusion ;)
philnelson
· 5 months ago
Seems like this would make more sense if you just replaced "developers" with "assholes" throughout the article.
Doug Alcorn
· 5 months ago
best comment on the article
Mase
· 5 months ago
I really appreciate this article. Not only should overly arrogant and/or misinformed/idealistic developers read this, but project managers, too.
Too frequently, a client or PM drop the phrase "small feature" or "little fix" or "minor request". That's because they only see the feature/fix/request where it sits on the page, not how it interops with the system on the whole. Yes, it's just an X, but it also has to invalidate caches, replicate quickly, and take Y into account, which we don't have control of! *sigh*
The point is, people tend to see software as parts. They often fail to see the interaction between those parts, or parts which remain hidden to the user (considerations made to easy deployment, to easy upgrading, to handle bad nodes, etc). I could whip up the crappiest version of StackOverflow together in 3 days, but it wouldn't be a StackOverflow clone, because SO is more than the sum of its visible parts.
Jennie Lees
· 5 months ago
Excellent post and hits the nail on the head. But what makes me wonder is why OSS doesn't have the polish. Is simply making something work enough for OSS developers? Is the beauty really just in the code for them? Several OSS projects (Drupal springs to mind) have dedicated UX teams, yet the products still look and feel like arse. What's with that?
trashbat
· 5 months ago
One thing that did spring to mind was the comparison I once did of Tapestry, Django and Ruby on Rails - not of the frameworks themselves, but of the project websites - I think that in itself says a lot about what is important to the various project cultures.
To be fair, the vast huge majority of commercial software (which is business internal) also looks like arse, and the vast majority of our digital electronics (from phones to DVD recorders, etc) also have poor interaction design.
Which isn't to say that good UX design isn't a skill that can be learned - it's a 'language' with it's own patterns, etc, but like mastering (rather than being able to use) a programming language - it takes years of actually doing it - and presumably doing it again and again.
Perhaps equally importantly, developers get less feedback on this - performance issues and bugs make their way back to developers quickly, but design issues less so. (Our helpdesk, for instance, wouldn't even log a design complaint - the customer bought the software as is, and it's not a technical fault).
dasil003
· 6 months ago
I am reminded of a post a few years ago entitled "Being 37signals for free" (http://www.wisdump.com/business/being-37signals...) that asked why someone didn't clone their apps and release them for free *over a weekend*.
I thought this kind of massive ignorance was mostly limited to Internet pundits, certainly not professional engineers. I understand the optimism of developers, hell it's the only way to get up in the morning, but when you start underestimating things by 3 orders of magnitude you really have no business writing software for money.
Jeff LaMarche
· 5 months ago
This was a great post, and I agree with your main point if, perhaps, not all of your details. You lost me in the the second to last paragraph, though. You had this great argument going, and then you sought to strengthen it (unnecessarily) with an ad hominem attack on PostgreSQL.
And the crux of your argument was that PostgreSQL was nowhere near as easy to administer as SQLServer... because a few years ago, you used to have to create a one line cron job to vacuum the database and because on two platforms (of the many that it supports) you have to type one command to create your first database cluster? Wow. The horror! And SQLServer is better because you don't have to do that? Well, then... how exactly do you set up your SQLServer on Ubuntu or FreeBSD? Oh, wait... you can't, can you.
In most scenarios for most purposes, getting PostgreSQL up and running takes no more time than running the SQL Server installer and typing in your license key, and it often takes less.
I'm not bashing SQL Server - it's a very competent database and its integration with the Microsoft dev stack makes it very attractive when using .NET. But don't label PostgreSQL as "inferior" or "harder to use" because of the way things used to be or because you have to do one specific task in one particular scenario that can't even be done on the thing you're comparing it to. Considering the number of platforms PostgreSQL supports, having to set up your first cluster (sometimes) hardly seems like a compelling argument that PostgreSQL is "not for the faint of heart". Not to mention that there are plenty of tutorials and walkthroughs that explain the process if you're not sure what to do or why. You've hardly picked the best open-source project to make your point that OSS is never as good as commercial software (an unsupportable generalization which actually detracts from your main point)
Benjamin
· 5 months ago
This seems to have come up in a few places, including the discussion on reddit and Hacker News.
I'm not saying PostgreSQL isn't a great database. I love it. But saying that it's harder to use than SQL Server is definitely not an ad hominem attack, and pointing out that SQL Server doesn't run on Unixes neither supports PostgreSQL's ease-of-use nor damages SQL Server's. There are actually a wide range of things that PostgreSQL does better than SQL Server, but that are harder to set up on PostgreSQL than on SQL Server, including creating and configuring databases, managing permissions, setting up routine maintenance, employing full-text search, and adding customized data-types, just to name a few. As such, I think it actually supports this article beautifully: it's technically superior and more difficult to use. Whether that's an indictment or raving support really depends on how much you value usability over power. Developers tend to value the latter, end-users the former.
darkhelmetlive
· 5 months ago
Excellent write up, but why all the hate on OpenID? I was so happy to see a sight where I didn't have to have yet another unique login for...
Benjamin
· 5 months ago
Sorry; I wasn't trying to hate on OpenID, and I, too, was thrilled to see StackOverflow support it since the beginning of the beta, and my biggest beef with Disqus right now is that it doesn't support logging in via OpenID on consumers' sites. My complaint with StackOverflow was that the only way to log in was via OpenID. At least in its current form, OpenID is still too complicated for many users. StackOverflow should allow users who do not have, or do not know how to use, an OpenID, to register and use the site regardless.
One way to achieve that, which I have yet to see, but hope eventually becomes standard, is for OpenID-consuming sites to also be OpenID providers themselves. If you get to the site and don't have an OpenID, you register normally, and poof, you have one. The site can allow login only via OpenID internally, but users who don't quite get the concept aren't left in the cold. I'm hopeful that the commercial StackOverflow product will do exactly that, but we'll have to see.
darkhelmetlive
· 5 months ago
On the other hand, sites forcing OpenID on the user can help push forward the technology and make it more mainstream: "you need OpenID, no questions!"
StackOverflow at least allows you to basically use the site with all bells and whistles without actually logging in, so and if I remember correctly from the podcasts, the "OpenID Only" was counteracted a bit by that fact.
Personally, I think if spending the 5 minutes to get an OpenID and understand that you just need to give a site a URL (and then if you aren't logged in to your OpenID provider, give it your username/password) is too hard of a concept to grasp, it's kind of a miracle they've gotten anywhere on the web. They might not get why at first, they might think it's dumb ("what? I need to log here, then put this url over here? That's stupid..."), but those are things that can be rectified later ("oh one username/password for all these sites? restricting who can see what? Cool!"). The minimal usage concept, I think, is pretty simple.
But that's just me.
(I use Disqus on my blogs too and wish it had OpenID :( )
foxyshadis
· 5 months ago
Did you read what you just wrote? "spending 5 minutes to get an OpenID" ... "give a site a URL" ... "give it your username/password"
I generally spend 15-30 seconds to sign up at a site, and even then only if it's really compelling; spending 5 minutes to grok and sign up is a waste of my time, then typing in a whole url just so I can type my username & password again (since most sites time out your session anyway after 5 mintues).... what a waste of effort.
The #1 glaring failing of OpenID is that it conflates the username and the provider. The implementors thought that was the greatest reason to use it, and I think it's the main reason I'll never use it: I'm not going to type a 100 character url every time I want to log in with my 10 character username. Google and Yahoo saw this and implemented it sanely: You type your name and select your provider, the site fills in the rest of the URL, as it should be, and more sites are adopting this. OpenID should have specified a standard registrar and registration method, so that every site could show the various largest OpenID providers, instead of waiting for non-standard implementations by third-parties to hash this out.
Once this form of "OpenID 2" is standardized, it'll be adopted much more quickly.
darkhelmetlive
· 5 months ago
I don't know about you, but whenever I go to a new site with OpenID, my browser remembers the URL, so I rarely actually have to type it in. A lot of the sites also have the nice login box, StackOverflow being one, where you can click your provider and then type the relevant info, such as the username.
The whole getting an OpenID is a one time thing, and being able to use a site simply by typing two letters in a text box and having the browser auto complete it, then hitting enter, is infinitely better IMO than having to fill out another signup form (even if it just a couple fields), then probably going to check your email, maybe use a random password to login, or just activate your account, and then go back to the site and actually login. I'd rather just type the damn URL and click 'Login' than deal with yet another login for some site. While the system isn't perfect, I still prefer it over having a separate username/password everywhere I go.
If you would rather spend 30 seconds signing up every time, versus 3 seconds to type a URL (or have the browser do it for you), be my guest. I'll be the guy with a single sign on...
Alexander Kellett
· 5 months ago
non-programmers much prefer to spread out complexity rather than abstracting it and thusly making it a visible entity annoys them no end generally. programmers otoh, we always despair, we already knew about the complexity, we knew it was hidden.
John Yeates
· 5 months ago
I'm still trying to see how OpenID lets me have one separate email address for each site I sign up to — I've found various sites over the years that have passed my email address on (including the email address given only to an airline with a "no spam" policy that, nonetheless, ended up getting solicitations from charities a couple of weeks after booking a flight…)
If every site gets the same email address, how do I tell who's the bad guy? (Ideally sneakemail.com would become an OpenID provider, then let me configure an email address each time I authorised a new site :)
Have I missed something, or is this already possible with OpenID?
darkhelmetlive
· 4 months ago
I guess that is one of the problems. I know as a site owner you can say "I require an email" and then when you authorize the site you can decided whether or not you want to allow the site, because it will tell you it wants your email. With some providers you can choose personas, so you can have bogus information (with some crap email for stupid sites) and use that for certain things, and then your normal information for other more trusted sites.
So on some providers, yes this is possible, to a degree. I think myopenid has personas.
grovberg
· 5 months ago
Reading this, I was practically standing up at my desk yelling "Testify!"
I have this argument with my co-workers near daily. We're talking about a feature and their response is "Oh that's easy." and start talking about how the data will travel in the database. It then takes me another solid 10 minutes of talking to clarify that the user doesn't care how the database works, they care how the the user interface should work and that's what I'm trying to discuss. Their response, every time, and I'm not even joking, is "Oh that's just trivial user interface details."
...
*blink*
AAAAAAAAAHHHHH!!!!
I have literally pulled at my hair in frustration.
intellectualhonesty
· 5 months ago
Your posting here is totally dishonest about opensource. Requirements are requirements if you only do half of the job you're obviously not done. But instead you have slandered opensource in terms of quality.
You're not arguing honestly, you have this awful bias and you refuse to understand that commercial software is crappy too. In fact studies have shown there is very little difference in software quality between OSS and Commercial software. It turns out that software is software, and you don't seem to understand the scope of this.
This is evident because you didn't scope your argument at all. You should retract everything you've said here about OSS because you simply have no evidence or stats to backup with you said.
I refer to papers by Adris Mauckus et al. and Calluppi et al. Also work by Thomas Zimmerman. They don't show what you show, but instead they show evidence. Go check flossmole or other OSS metrics projects and you'll see the wide range of software that you are obviously totally ignorant of.
Eli James
· 5 months ago
WOW, what a wonderful argument! He should retract everything he has said because he has been dishonest about the 'requirements' of open source (which was, if you haven't noticed, only tangentially connected to the main point he was trying to make here, and that was that UI matters) and therefore everything else he has said is wrong (like the UI stuff) and you are correct, because you have READ. MANY. ACADEMIC. PAPERS.
I need to retake logic in college, I think, I didn't even think of that!
Aupajo
· 5 months ago
I'm a little confused following your argument here. What are you seeing as "dishonest"? Just trying to read your post...
tomtomtomtomtom
· 5 months ago
Claiming it is impossible because the code base is huge and complicated, sound an awefull lot like "A Tale of Two Programmers"
I'm not saying it's impossible; just that it cannot be done in a weekend, and that, even if it could, if it's purely a labor of love, the author likely will forget the creature comforts.
dtr
· 5 months ago
Actually, you clearly state "That is why an open-source clone of StackOverflow will fail."
None shall reach the loftiness of your loftinesses!
I do agree with the point, aside from the grandeurposture.
alfy
· 6 months ago
"Tell me: which of those features do you feel you can cut and still have a compelling offering?"
Easy: the decision to use ASP.NET MVC -- I'd write it in a higher-level language, thus saving me a lot of typing and work, and sacrificing something no user will ever care about. I've worked on large programs in ASP.NET MVC and other languages, and it's not even close to being the best in terms of programmer efficiency.
Apache wouldn't be my first choice of open-source web server, either, for exactly the reasons you mention. And I wouldn't run an old version of Postgres, either.
Why do you defend a big complex app you wrote by trying to argue that any other implementation would have to make the same architectural decisions you did, thus resulting in an equally big and complex app? My first boss told stories about writing apps in FORTRAN on mainframes, and they sound impressive in a "when *I* was your age" kind of way, but they don't reflect the amount of work that's actually necessary today, if you care about minimizing work and not simply using 'industry standard' technologies.
Benjamin
· 5 months ago
Which languages and environments?
CraigJB
· 5 months ago
I agree totally. He made some pretty hard assumptions that led down particular paths. Those are not the only directions one can take. Reading this, I'm thankful I don't have to play in his sandbox.
didibus
· 2 weeks ago
Honestly, simply changing the programming language or the environment won't be saving you a whole lot more time. On top of that, you will be losing some of the smoothness, because higher-level languages are always slower. So the part where he mentions SO has to scale, because you will eventually end up being a super high traffic website might somewhat be related to the environment you choose.
Also, a proficient programmer in a given language X can code just as fast as a similarly proficient programmer in language Y. If he choose an environment, it's probably because he knows it very well, in that case, you might work faster in another environment, but all his claims still apply to that language non the less.
And if you're still not convince, try and clone it in a weekend.
Sean Kerwin
· 6 months ago
I agree completely with your conclusion about open source usability, but the preamble about retyping time is a little tougher to take without question. Of that 96.5 kB of source, how much is strictly necessary? One of the big HN memes -- and one of Paul Graham's favorite recurring essay topics -- is that more powerful languages let you express the same functionality with fewer lines of code. Imagine someone writing a site in assembly with a front-end built by XSL transforms telling you it's mathematically impossible to retype his site in less than a month; it wouldn't be a false statement, it would just be a wrong one.
Which isn't to say I think anyone can really recreate SO in a weekend. Like I said, I'm in complete agreement with your conclusions, just not with the whole of the road you took to get there.
Benjamin
· 5 months ago
Thanks for the thoughtful response.
To answer your question about the source: first, I got the initial number wrong; it should've been 2.3 MB.
As for how much is crap that could be filtered out in a better language: if you want an answer to that question, you're going have to take me slightly on faith. For credentials, I'll point out that I'm fluent in Smalltalk, am comfortable in Self, and have worked in the Factor, MLs, Common Lisp, Clojure, and several other high-level languages. That's the background I'll use for evaluating whether StackOverflow could be helped by a higher-level language. Provided that meets your criteria, my verdict:
It's actually very well-factored. If you're going to use an MVC framework (Rails, Django, Hunchentoot, or the like), I don't think you're going to improve much. The templates themselves are well-factored, and, although I'm positive the models are hardly perfect, because StackOverflow is already using LINQ to SQL, and that framework's actually quite solid, I don't think you're going to improve by an order of magnitude over what StackOverflow is currently doing if you plan to talk to an RDBMS. That just leaves the controllers. As much as I've been ambivalent about C# in general, the fact remains that C# 3 isn't honestly that far away from a "real" high-level language. You've got closures, lambdas, type inference, literal dictionaries, and so on. There are unquestionably some easy improvements you could make with a Lisp/Smalltalk/Ruby implementation, but, short of a major refactoring, not enough to make a real dent in the controllers. (And in jumping to at least some of those frameworks, you're going to take a hit, since ASP.NET MVC does some smart things, such as populating objects based on their static type, that other frameworks don't do. Whether the balance is positive or negative is something I'd be curious to see.)
Now, a more interesting question for me, at least, would be, "Can you do better using a vastly higher-level framework, such as Seaside, Uncommon Web, or Iliad, backed by an OODBMS instead of an RDBMS?" The answer there is probably, "Unquestionably--but it won't scale as well." These frameworks all make building websites far quicker, but end up caching client state in the memory of the server. That means that your sessions are now bound to a single server, and that your scaling has therefore ceased to be horizontal. This may be an acceptable trade-off for you, but won't be to many others.
Sean Kerwin
· 5 months ago
Fair enough, and I'm perfectly happy to take your word for it -- like I said, I'm not really criticizing your conclusion, just pointing out what could be seen as a hole in the argument. Following a link from HN, it's easy to envision a reflexive 'omg Lisp has less typing!' reaction.
I've been working in C# for a few years now myself, and I've got to admit that despite myself I've grown to kind of like it. Even if it's not the 'best' language in absolute terms right now, I think it may well have the best 'velocity towards goodness' of any language in active development right now.
didibus
· 2 weeks ago
Something to consider is that it's not because a language results in fewer lines of code, that coding something takes less time. The slowest part of writing code, is not the typing, it's the thinking.
qeorge
· 6 months ago
I like the Stack Overflow example, and you're probably still being generous about how long it would take to implement. Testing hasn't been mentioned at all.
As someone who suffers from "I can code anything in a week" disease this rang true.
gutzofter
· 6 months ago
The details come from usage. It applies the evolutionary pressure to polish it up.
m3mnoch
· 6 months ago
good lord -- amen, ben.
m3mnoch.
JohnnyYen
· 5 months ago
I think these claims are made by people who are used to coding to a spec. They don't understand the attention to detail that goes into making a polished product and thats it. They haven't had to think hard about the implications of voting or some other "social" aspect of the application.
Bruce Collier
· 5 months ago
well said!!
I'm not sure how well many coders respect the 'spit & polish' of a good web app.. but it's not easy to get right and shouldn't be under-estimated
Rob Loach
· 5 months ago
Development of a website is way more then just the coding and I'm glad you mentioned this in your article. It is very important for everyone involved to allot the extra "polish-time", that you mentioned above. The precise scope of the website should be known and documented by everyone, from the designer to the developer, management to the production staff, the client to the QA team, everyone.
The thing that people who claim to be able to dish out a StackOverflow clone in a weekend are missing is experience. If they want to try it, then please let them try and fail so that they can learn about scope. Because scope is the key thing here.
Jachin Sheehy
· 5 months ago
I think this whole argument is moot ... who cares how long it might take to write or clone the app. Once you had done it, who would use it?
The success of StackOverflow is clearly in it's community of users. The app is a necessary piece of infrastructure, but the real action is the community posing and answering questions. You remove the community and the app ceases to very interesting.
xanadont
· 5 months ago
Why are you wasting your time feeding the trolls? Any half-brained, non-zealot understands the ignorance of "implementing SO in a weekend". We all know s/he won't succeed. Who cares? StackOverflow is incredible, it's winning, and is extremely successful. Let the naysaying, outlier discussions spark, burn, and fizzle on their own. Really, this trash has no impact on SO and shouldn't get any official attention.
kokorozashi
· 5 months ago
My response to the weekend speculators is: Fine. Go do it. Put me out of business. I dare you.
oomu
· 5 months ago
hu.. what is your point with opensource ?
firefox or vlc are opensource and easy to use
the same with ubuntu to open a webpage, save a document and read it.
about Work, you are totally right.
ao5357
· 5 months ago
I agree that a polished clone of SO in a weekend is unrealistic.
On the other hand, your argument is not realistic to an OSS clone project's likely workflow, and is more importantly contingent on a few definitions. Foremost, what you mean by writing software. The operating assumption of the article appears to be writing code from scratch. You make this position difficult to defend by granting the use of a framework like Django.
Why could it not logically follow to start with more than a basic framework? Such a clone could be a Drupal install profile, for instance, with the currently-unsupported bits as contrib modules to the project as a whole.
If you'd like, I can go more point-by-point as to why this post is disingenuous to reality, even though the main thesis is more/less correct.
Watts
· 5 months ago
With all respect: if you think starting "with more than a basic framework" addresses the crux of Benjamin's argument in a substantive way, you don't understand the argument. To use your example, Drupal isn't a framework, it's a content management system -- and while that may bring more functionality off the starting line, it's ultimately still infrastructure. I doubt there's an install profile for "make Drupal vaguely resemble Stack Overflow," and the whole meat of the issue is getting from the closest point Drupal can get you before you start customization to the point where what you have is "almost exactly like" rather than "something like" SO. A whole lot of that work is in UI work and many, many small details, and it's precisely the small details -- the fit and finish -- that neither a framework nor a CMS are going to provide. One might argue, in fact, that the entire point of systems like Rails or Django or indeed Drupal is to handle the *big* details for you so you can devote more attention to all the small ones.
N.B.: In my admittedly limited experience, starting from a CMS like Drupal is only a good idea if what you want to do is more or less what Drupal is designed for. The more features you have that you're going to implement yourself, the better off you may be starting with something like Django instead; eventually you're spending more time learning how to rearrange the CMS's internal wiring than you would be spending starting with a less full-featured stack.
Eli James
· 5 months ago
@Ben: regardless of what 'intellectualhonesty' thinks, I find your arguments about implementing UI in a major website to be a revelatory one. I dunno - most programmers don't really care about what the user sees, or how the users sees it, I guess it's in our training to think about efficiency, and not HCI. But this is a brilliant article, thank you.
Tinus
· 5 months ago
I am inspired to write an article (in Dutch) about customers who expect it's easy to copy functionality.
Ölbaum
· 5 months ago
Nice writing, I'll definitely have a look at your blog.
P.S.: It would have been nice if signing in hadn't erase the comment I was writing.
Andy Brice
· 5 months ago
In my experience, of free open source software I have found it reliable and well-engineered, but poor usability is often a real issue.
If a piece of software is intended to have a GUI, it shouldn't be an afterthought; and should be created by people with a good understanding of interaction design.
If open source software is to become mainstream I think designers need to contribute more to the movement.
shiva
· 5 months ago
You assume the average developer is someone, who does not understand basic estimation, someone, who cannot think beyond the obvious, the most basic set of requirements.
That to me is quite sad. (It is quite true most often)
didibus
· 2 weeks ago
Amazing post! Everything you said is true. They are the exact same reason why I have never embraced open source software as the tools I regularly use, even though I always prayed the gods they would be better, they would feel smoother and gentle to my skin and work well and look pretty and smell like roses, they never do. In the end, it makes sense also. If you make something that feels so damn right, you'll probably decide to sell it instead.
All Comments
I've extracted my own conclusions from the article, but for the sakes of continuing a conversation [for my own benefit to understand things better] i would like to argue that developer arrogance is a product of poor skill of managing client expectation; perhaps often not developer's fault. Arguably client expectations should be managed by a more senior developer, but the same mistakes can be made regardless of the title held. I would argue that client should recognize that how questions are asked with regards to development effort estimations ultimately lead to how developer answers those questions.
I will attempt to provide example of what i am trying to say:
If a client simply asks "how much effort would it take to clone StackOverflow?", the developer's response will be very much shaped by his very limited (or not so limited) experience with StackOverflow. Here point being the amount of variability due to developer's user experience with StackOverflow.
On the other hand if client asks "How much effort would it take to clone StackOverflow without compromising any existing user experience, infrastructure, upgrade paths and _______ (insert what ever other component that is truly relevant)", will produce much different behavior from the developer. Such question leads developer to put some context around the task as well as evaluate his own knowledge of those components and potentially force them to research any grey areas in their knowledge of the mentioned components as well as relating components before answer is given. Client should realize that the way questions are asked will lead to a different answer from the developer. it is also very important to note that people are not mind readers and different cultural and life experiences lead people to understand meanings of sentences differently unless formatted very explicitly to eliminate as many variable factors as possible.
Unfortunately there are no single point of failure that we can all avoid to overcome the problem. Fortunately people that have lived through this or simply understand this psychology will tend to recognize when communication is failing due to those *variable* factors and attempt to correct themselves to communicate differently.
High level of productivity is achieved when both parties are on the same wavelength. Some productivity is possible when one person attempts to compensate by leading questions. no guaranteed productivity is possible when both parties do not understand this notion (only chance possible). It is a two way road. Both sides must ask themselves two questions 1) Am i being understood according to what i am trying to say? and 2) do i understand the other person according to what he/she trying to tell me?
In an attempt to avoid leading the question i am concluding the above thoughts without a conclusion ;)
Too frequently, a client or PM drop the phrase "small feature" or "little fix" or "minor request". That's because they only see the feature/fix/request where it sits on the page, not how it interops with the system on the whole. Yes, it's just an X, but it also has to invalidate caches, replicate quickly, and take Y into account, which we don't have control of! *sigh*
The point is, people tend to see software as parts. They often fail to see the interaction between those parts, or parts which remain hidden to the user (considerations made to easy deployment, to easy upgrading, to handle bad nodes, etc). I could whip up the crappiest version of StackOverflow together in 3 days, but it wouldn't be a StackOverflow clone, because SO is more than the sum of its visible parts.
To be fair, the vast huge majority of commercial software (which is business internal) also looks like arse, and the vast majority of our digital electronics (from phones to DVD recorders, etc) also have poor interaction design.
Which isn't to say that good UX design isn't a skill that can be learned - it's a 'language' with it's own patterns, etc, but like mastering (rather than being able to use) a programming language - it takes years of actually doing it - and presumably doing it again and again.
Perhaps equally importantly, developers get less feedback on this - performance issues and bugs make their way back to developers quickly, but design issues less so. (Our helpdesk, for instance, wouldn't even log a design complaint - the customer bought the software as is, and it's not a technical fault).
I thought this kind of massive ignorance was mostly limited to Internet pundits, certainly not professional engineers. I understand the optimism of developers, hell it's the only way to get up in the morning, but when you start underestimating things by 3 orders of magnitude you really have no business writing software for money.
And the crux of your argument was that PostgreSQL was nowhere near as easy to administer as SQLServer... because a few years ago, you used to have to create a one line cron job to vacuum the database and because on two platforms (of the many that it supports) you have to type one command to create your first database cluster? Wow. The horror! And SQLServer is better because you don't have to do that? Well, then... how exactly do you set up your SQLServer on Ubuntu or FreeBSD? Oh, wait... you can't, can you.
In most scenarios for most purposes, getting PostgreSQL up and running takes no more time than running the SQL Server installer and typing in your license key, and it often takes less.
I'm not bashing SQL Server - it's a very competent database and its integration with the Microsoft dev stack makes it very attractive when using .NET. But don't label PostgreSQL as "inferior" or "harder to use" because of the way things used to be or because you have to do one specific task in one particular scenario that can't even be done on the thing you're comparing it to. Considering the number of platforms PostgreSQL supports, having to set up your first cluster (sometimes) hardly seems like a compelling argument that PostgreSQL is "not for the faint of heart". Not to mention that there are plenty of tutorials and walkthroughs that explain the process if you're not sure what to do or why. You've hardly picked the best open-source project to make your point that OSS is never as good as commercial software (an unsupportable generalization which actually detracts from your main point)
I'm not saying PostgreSQL isn't a great database. I love it. But saying that it's harder to use than SQL Server is definitely not an ad hominem attack, and pointing out that SQL Server doesn't run on Unixes neither supports PostgreSQL's ease-of-use nor damages SQL Server's. There are actually a wide range of things that PostgreSQL does better than SQL Server, but that are harder to set up on PostgreSQL than on SQL Server, including creating and configuring databases, managing permissions, setting up routine maintenance, employing full-text search, and adding customized data-types, just to name a few. As such, I think it actually supports this article beautifully: it's technically superior and more difficult to use. Whether that's an indictment or raving support really depends on how much you value usability over power. Developers tend to value the latter, end-users the former.
One way to achieve that, which I have yet to see, but hope eventually becomes standard, is for OpenID-consuming sites to also be OpenID providers themselves. If you get to the site and don't have an OpenID, you register normally, and poof, you have one. The site can allow login only via OpenID internally, but users who don't quite get the concept aren't left in the cold. I'm hopeful that the commercial StackOverflow product will do exactly that, but we'll have to see.
StackOverflow at least allows you to basically use the site with all bells and whistles without actually logging in, so and if I remember correctly from the podcasts, the "OpenID Only" was counteracted a bit by that fact.
Personally, I think if spending the 5 minutes to get an OpenID and understand that you just need to give a site a URL (and then if you aren't logged in to your OpenID provider, give it your username/password) is too hard of a concept to grasp, it's kind of a miracle they've gotten anywhere on the web. They might not get why at first, they might think it's dumb ("what? I need to log here, then put this url over here? That's stupid..."), but those are things that can be rectified later ("oh one username/password for all these sites? restricting who can see what? Cool!"). The minimal usage concept, I think, is pretty simple.
But that's just me.
(I use Disqus on my blogs too and wish it had OpenID :( )
I generally spend 15-30 seconds to sign up at a site, and even then only if it's really compelling; spending 5 minutes to grok and sign up is a waste of my time, then typing in a whole url just so I can type my username & password again (since most sites time out your session anyway after 5 mintues).... what a waste of effort.
The #1 glaring failing of OpenID is that it conflates the username and the provider. The implementors thought that was the greatest reason to use it, and I think it's the main reason I'll never use it: I'm not going to type a 100 character url every time I want to log in with my 10 character username. Google and Yahoo saw this and implemented it sanely: You type your name and select your provider, the site fills in the rest of the URL, as it should be, and more sites are adopting this. OpenID should have specified a standard registrar and registration method, so that every site could show the various largest OpenID providers, instead of waiting for non-standard implementations by third-parties to hash this out.
Once this form of "OpenID 2" is standardized, it'll be adopted much more quickly.
The whole getting an OpenID is a one time thing, and being able to use a site simply by typing two letters in a text box and having the browser auto complete it, then hitting enter, is infinitely better IMO than having to fill out another signup form (even if it just a couple fields), then probably going to check your email, maybe use a random password to login, or just activate your account, and then go back to the site and actually login. I'd rather just type the damn URL and click 'Login' than deal with yet another login for some site. While the system isn't perfect, I still prefer it over having a separate username/password everywhere I go.
If you would rather spend 30 seconds signing up every time, versus 3 seconds to type a URL (or have the browser do it for you), be my guest. I'll be the guy with a single sign on...
If every site gets the same email address, how do I tell who's the bad guy? (Ideally sneakemail.com would become an OpenID provider, then let me configure an email address each time I authorised a new site :)
Have I missed something, or is this already possible with OpenID?
So on some providers, yes this is possible, to a degree. I think myopenid has personas.
I have this argument with my co-workers near daily. We're talking about a feature and their response is "Oh that's easy." and start talking about how the data will travel in the database. It then takes me another solid 10 minutes of talking to clarify that the user doesn't care how the database works, they care how the the user interface should work and that's what I'm trying to discuss. Their response, every time, and I'm not even joking, is "Oh that's just trivial user interface details."
...
*blink*
AAAAAAAAAHHHHH!!!!
I have literally pulled at my hair in frustration.
You're not arguing honestly, you have this awful bias and you refuse to understand that commercial software is crappy too. In fact studies have shown there is very little difference in software quality between OSS and Commercial software. It turns out that software is software, and you don't seem to understand the scope of this.
This is evident because you didn't scope your argument at all. You should retract everything you've said here about OSS because you simply have no evidence or stats to backup with you said.
I refer to papers by Adris Mauckus et al. and Calluppi et al. Also work by Thomas Zimmerman. They don't show what you show, but instead they show evidence. Go check flossmole or other OSS metrics projects and you'll see the wide range of software that you are obviously totally ignorant of.
I need to retake logic in college, I think, I didn't even think of that!
http://mail.linux.ie/pipermail/social/1999-Octo...
None shall reach the loftiness of your loftinesses!
I do agree with the point, aside from the grandeurposture.
Easy: the decision to use ASP.NET MVC -- I'd write it in a higher-level language, thus saving me a lot of typing and work, and sacrificing something no user will ever care about. I've worked on large programs in ASP.NET MVC and other languages, and it's not even close to being the best in terms of programmer efficiency.
Apache wouldn't be my first choice of open-source web server, either, for exactly the reasons you mention. And I wouldn't run an old version of Postgres, either.
Why do you defend a big complex app you wrote by trying to argue that any other implementation would have to make the same architectural decisions you did, thus resulting in an equally big and complex app? My first boss told stories about writing apps in FORTRAN on mainframes, and they sound impressive in a "when *I* was your age" kind of way, but they don't reflect the amount of work that's actually necessary today, if you care about minimizing work and not simply using 'industry standard' technologies.
Also, a proficient programmer in a given language X can code just as fast as a similarly proficient programmer in language Y. If he choose an environment, it's probably because he knows it very well, in that case, you might work faster in another environment, but all his claims still apply to that language non the less.
And if you're still not convince, try and clone it in a weekend.
Which isn't to say I think anyone can really recreate SO in a weekend. Like I said, I'm in complete agreement with your conclusions, just not with the whole of the road you took to get there.
To answer your question about the source: first, I got the initial number wrong; it should've been 2.3 MB.
As for how much is crap that could be filtered out in a better language: if you want an answer to that question, you're going have to take me slightly on faith. For credentials, I'll point out that I'm fluent in Smalltalk, am comfortable in Self, and have worked in the Factor, MLs, Common Lisp, Clojure, and several other high-level languages. That's the background I'll use for evaluating whether StackOverflow could be helped by a higher-level language. Provided that meets your criteria, my verdict:
It's actually very well-factored. If you're going to use an MVC framework (Rails, Django, Hunchentoot, or the like), I don't think you're going to improve much. The templates themselves are well-factored, and, although I'm positive the models are hardly perfect, because StackOverflow is already using LINQ to SQL, and that framework's actually quite solid, I don't think you're going to improve by an order of magnitude over what StackOverflow is currently doing if you plan to talk to an RDBMS. That just leaves the controllers. As much as I've been ambivalent about C# in general, the fact remains that C# 3 isn't honestly that far away from a "real" high-level language. You've got closures, lambdas, type inference, literal dictionaries, and so on. There are unquestionably some easy improvements you could make with a Lisp/Smalltalk/Ruby implementation, but, short of a major refactoring, not enough to make a real dent in the controllers. (And in jumping to at least some of those frameworks, you're going to take a hit, since ASP.NET MVC does some smart things, such as populating objects based on their static type, that other frameworks don't do. Whether the balance is positive or negative is something I'd be curious to see.)
Now, a more interesting question for me, at least, would be, "Can you do better using a vastly higher-level framework, such as Seaside, Uncommon Web, or Iliad, backed by an OODBMS instead of an RDBMS?" The answer there is probably, "Unquestionably--but it won't scale as well." These frameworks all make building websites far quicker, but end up caching client state in the memory of the server. That means that your sessions are now bound to a single server, and that your scaling has therefore ceased to be horizontal. This may be an acceptable trade-off for you, but won't be to many others.
I've been working in C# for a few years now myself, and I've got to admit that despite myself I've grown to kind of like it. Even if it's not the 'best' language in absolute terms right now, I think it may well have the best 'velocity towards goodness' of any language in active development right now.
As someone who suffers from "I can code anything in a week" disease this rang true.
m3mnoch.
I'm not sure how well many coders respect the 'spit & polish' of a good web app.. but it's not easy to get right and shouldn't be under-estimated
The thing that people who claim to be able to dish out a StackOverflow clone in a weekend are missing is experience. If they want to try it, then please let them try and fail so that they can learn about scope. Because scope is the key thing here.
The success of StackOverflow is clearly in it's community of users. The app is a necessary piece of infrastructure, but the real action is the community posing and answering questions. You remove the community and the app ceases to very interesting.
firefox or vlc are opensource and easy to use
the same with ubuntu to open a webpage, save a document and read it.
about Work, you are totally right.
On the other hand, your argument is not realistic to an OSS clone project's likely workflow, and is more importantly contingent on a few definitions. Foremost, what you mean by writing software. The operating assumption of the article appears to be writing code from scratch. You make this position difficult to defend by granting the use of a framework like Django.
Why could it not logically follow to start with more than a basic framework? Such a clone could be a Drupal install profile, for instance, with the currently-unsupported bits as contrib modules to the project as a whole.
If you'd like, I can go more point-by-point as to why this post is disingenuous to reality, even though the main thesis is more/less correct.
N.B.: In my admittedly limited experience, starting from a CMS like Drupal is only a good idea if what you want to do is more or less what Drupal is designed for. The more features you have that you're going to implement yourself, the better off you may be starting with something like Django instead; eventually you're spending more time learning how to rearrange the CMS's internal wiring than you would be spending starting with a less full-featured stack.
P.S.: It would have been nice if signing in hadn't erase the comment I was writing.
If a piece of software is intended to have a GUI, it shouldn't be an afterthought; and should be created by people with a good understanding of interaction design.
If open source software is to become mainstream I think designers need to contribute more to the movement.
That to me is quite sad. (It is quite true most often)
Everything you said is true. They are the exact same reason why I have never embraced open source software as the tools I regularly use, even though I always prayed the gods they would be better, they would feel smoother and gentle to my skin and work well and look pretty and smell like roses, they never do. In the end, it makes sense also. If you make something that feels so damn right, you'll probably decide to sell it instead.