This post is going to be a bit of a rant, so bear with me and feel free to bitch me out in the comments, but I’ve been getting really annoyed with people’s attitudes towards startups. In general, people seem to have short tempers with performance issues with startups – whenever an app goes down or behaves slowly, the ‘webosphere’ fills up with a bunch of whiners’ complaints.
Well, I’m here now to urge you all to have a little bit more patience and flexibility. In other words, quit your bitchin’.
Having been involved in the web community for over half my life, I would like to think I’m “on the level” with startups, how they work and the people behind them. The web startup culture is full of passionate nerds – myself included. We decided to get into this field because we want to help innovate the Internet, connect people, share information, and overall better ourselves and others through this extremely powerful global communication tool.
We work on our startups with a passion. When our app goes down, or works slowly, we’re hurt by that, probably moreso than most of the end-users. Most startup developers I know use their apps on a daily level, and we care very much when it doesn’t behave as it should.
When an app’s performance suffers, it’s not because the developers are lazy sloths who don’t give a crap about their product. It couldn’t be more the opposite. Most of the time an app will end up suffering from it’s own popularity, especially the more home-brew apps that were started because some nerd was bored one day and had an idea. This can really catch people by surprise, as there is no way to tell how popular an app will be in the future. Even the most experienced developers can’t always keep scaling up on par with popularity growth.
So, the next time Twitter takes a dive, or Facebook’s friend feed drops a story, instead of acting like a spoiled child and writing all over the Internet how much you hate it and how much that app sucks, how about you take a moment and realize that there are real people behind the app, who are working their asses off to deliver you your content the best they can.
This blog belongs to Jade Rauenzahn, a 24 year-old web developer living in Hell's Kitchen, NYC.
So am I allowed to laugh, gloat a little even, by pointing out that on the same day you wrote this, you also wrote this little nugget:
http://rauenzahner.tumblr.com/post/69169588
One could argue that the relationship between a startup and their users is much the same as that between a person who writes a piece of [opensource] code and the developers who benefit from it.
*ahem*
That stomping noise you hear is, I believe, the sound of the Hypocracy Cops, in their metal-toed boots, beating a path to your door.
So, I was a bit harsh in my tumblr post, and for that I do apologize (I’m a pottymouth), but there’s a fundamental difference in the two scenarios, and in my mind, a very important one.
I defend startups because the problems that tend to happen with them aren’t really predictable or controllable by the people who create them. Mark Zuckerberg started Facebook for his college friends – now it has over 150 million *active* users. Even the best teams can only scale their app so fast, and the expectation of people to have a service at their disposal whenever and however they want is a bit too high. Without wanting to oversimplify, web services are a privilege, not a right (unless you’re a paying member).
The reason I get openly frustrated with bad programming habits is because they’re completely under the control of the developer. I would never release a piece of open source code without making every possible attempt to make sure the people who adopt it can understand how it works. Code is art, how you craft it is very important, and when someone doesn’t take the care and effort to do so it comes off as lazy. I can’t stand lazy, it’s a huge pet peeve of mine.
Hopefully that’ll satisfy the hypocrisy police.
You make a good point about startup adoption rate being unpredictable, and I think you are right to defend startups for this. But I wouldn’t call this a “fundamental difference”. In the same way startups don’t know how many people will use their service, developers don’t know how many people will use their code. Both parties have to make trade-offs when deciding how much energy to expend preparing their “product” for an unknown audience. Is polishing documentation for code that nobody uses good practice… or just a waste of time?
The copyright notices in the code in question show exactly how it’s audience changed unexpectedly. It’s a jQuery port done by one person, of code that was written by someone else years before jQuery was created. How big an audience was there _really_ for a JavaScript fillEllipse function back in 2000-2004? This is the beauty of opensource: it allows something that was probably a small weekend experiment by someone years ago to become an important part of a high-profile project today.
I would be remiss to not point out that these two cases are fundamentally different in a different respect. Startups often go to great lengths to attract and entice users, which invites a certain justifiable expectation of support and performance on the users’ part. Startups also benefit tremendously from said users adopting their service and coming to rely on it. (This is, after all, often what determines whether a startup succeeds or fails). In contrast, vast majority of opensource developers act out of simple altruism, a desire to help other developers avoid wasting time reproducing their efforts, with little in the way of compensation or reward.
“Here’s what I’ve done so far. ‘Hope you find it useful.”
Here are a few questions to ponder:
- How long would it have taken you to write that graphics library from scratch? Given the demands on your time, could you have done any better?
- Who should fix the problems you’re criticizing? You have access to the code repository after a; by not fixing it yourself, are you implicitly saying your time is worth more than the code author’s?
There’s just a few things:
1) My tumblr blog should not be taken seriously.
2) I wasn’t bashing the idea of open source code or even directly criticizing that jQuery plugin in particular (kind of surprised you figured out the plugin from the short code screenshot I posted). I was criticizing bad programming style, and I think I have every right to.
I never program anything without doing everything I can to help maintainability. There is a style to code and it should be open to critique – nobody should program with one letter variables because it’s bad practice. (just ask wikipedia) It’s the same as saying nobody should design a professional site with Comic Sans, or drive on the wrong side of the highway. Standards help everyone think on the same page, and having meaningful variables is one of the strongest programming conventions in existence. Things like whitespace can be overlooked – variable names really can’t be.
To answer your first point, the Canvas class I’ve been writing has been started from scratch, and it’s been a solid 2 months of crazy changing evolution as I scale up the functionality. I’m sure I could have wrote things better, I’m far from being the best programmer in the universe. However, I do maintain proper style in my code, and I do take pride in that.
I’m not implying that the jQuery plugin code is ‘broken’ and that it should be fixed. Sure, I can go in there and decypher the variable names to give them meaning and return the code to them, but – why? I just took a look at the code to see how other people were using Canvas. The only reason I ranted was because of the programming practice, not that I hated the actual plugin.
…actually short var names in JS libs are a good thing (less kb)…just my 2 cents
Ha! Touché.
When in development, variable names totally need to have meaning. There’s no way around this – you develop code with short vars, 6 months later you don’t know if ‘rw’ means ‘right wing’ or ‘right window’. Code needs to be easily human readable.
Now, compressing code on a production server is a best practice, and a very important one, but that’s what things like Dean Edwards’ Packer is for, or the Asset Packages I blogged about before.
That’s why you’ll notice many of the popular open source libraries (like jQuery) have different compressions of the code you can download, depending on your purposes. That’s open-source that rocks it.
Jade, I’m not trying to hold your feet to the fire on the tumbler post (well, not too much anyway). I just found the contrast in tone between your two posts, made within hours of each other, to be too tempting to not point out.
I’ve been holding off on getting into a semi-religious debate about code style, but I might as well give my $.02 at this point.
You say, “Code needs to be easily human readable”, which I absolutely agree with. However, this does not always mean “variable names totally need to have meaning”.
When I grade code on it’s readability, variable naming is actually at the very bottom of my list of things to care about, which looks like this:
An overview comment that provides describes what the file/class/module does at a high level, what requirements it has, and that gives an example of how the API is used.
Public Method and Var docs that describe method behavior, and inputs/outputs, and what generally what state is accessible through the API
Inline comments that provide a pseudo-code level description of what the code is doing.
Descriptive variable names
I put far more weight on #1 and #2 than I do on #3 and #4. As long as there are good doc-comments that accurately describe the public API, I’m not going to get too bent out of shape about the rest. The only time #3 and #4 are important are when you have to dive into the code implementation to figure out what exactly is happening. If the developer has done a good job with the first two, that shouldn’t be necessary (too often… for stable code… that doesn’t have bugs… that you don’t need to port or adapt. Hmm, okay, maybe it’s sorta important.
)
Where variable names are concerned specifically, the problem is that sometimes there simply isn’t a good descriptive name. This is particularly true in abstract problem spaces like cryptography and, surprise, geometry and math. You often have variables that hold interim state for which there simply is no good description. Check out the pseudo-code for the MD5 algorithm for an example. I’m pretty sure this is what we’re seeing in the JS graphics file.
Obviously this is less often the case with variables that appear as part of a public API. Those variables are more likely to have a concise semantic meaning and their name should reflect that, of course. But when it comes to what’s inside the “{…}”s of a method, insisting on descriptive names can actually be counter-productive. You’ll end up with real head-scratchers like, “rotatingHashAccumulator3″, which aren’t actually any more readable, and just blow out what should be a single line of code across a half-dozen lines (making things less readable, not more so!)
This is why I personally emphasize inline comments over variable names. They are much more effective at making code readable, and they give you more latitude to use names that suit your coding style, whatever that may be. They can also be a useful productivity tool – I’ll often write these comments first to “plan” what my implementation is going to be, and then fill in the source code.
So there you have it. In the case of the JS graphics file, it has good introductory comments, but it lacks the method-level documentation that I think pretty much all public libraries should have. It would also benefit from inline comments that explain the various algorithmic behavior, something longer variable names probably wouldn’t do much for.
(P.S. Short var names don’t have a significant impact on code size when JS files are gzip’ed. And if yo’re not gzip’ing, you’ve got bigger problems than var names.)