It was the French writer and philosopher Voltaire who observed, “The perfect is the enemy of the good.”

(Actually, since Voltaire was French, what he really observed was, “Le mieux est l'ennemi du bien.” It's a line from a 1772 poem called “La Bégueule.” He apparently meant “the better” or “the best,” not “the perfect,” but the aphorism survives in English as “the perfect is the enemy of the good.” People quote the line all the time without thinking too hard, I imagine, about its literal meaning.)

In the software development world, we quote Voltaire when we warn of the dangers of analysis paralysis: the pernicious state of spending so much time and energy on preparations that we never actually begin coding. It arises, I think, from the fear of making a wrong move, which is a fine fear to have, in moderation.

The aphorism also applies to the malady of elegance creep or gold-plating. Blogger Rick Kotermanski says that's what you get when you blow deadlines by addressing implied or unwritten nonfunctional requirements. “I have frequently found cases where programmers have built exotic and academically intriguing solutions to problems that don't really exist,” Kotermanski writes, “usually under the guise of addressing an anticipated but never realized performance or extensibility problem.” To which I can say only, “Um...guilty as charged.”

A thoughtful fellow named Vesa Palmu has observed, as many have, that an unbridled quest for perfection can lead to endless costs and delays. He's summarized the problem with a little chart that shows the relationship between value and development cost, and identifies an optimal zone in which costs are incurred most efficiently:

Obviously, the solution to perfectionism is to stop working when the code is good enough. But that's devilishly hard to do – coding isn't a “good enough” profession, in my experience. Parmu says, “I'm not trying to say it's good to lower your standards, not care about the visuals, or to cut back on quality. I'm just saying that you should know what is really important and pay attention to what your definition of done is.”

(A good many discussions of the perils of perfection wind up citing the Pareto Principle, the so-called 80-20 rule. The rule suggests that achieving the last 20 percent of perfection consumes 80 percent of your overall effort and budget. This insight sounds as if it ought to be true, and is constantly cited as if it were established fact, but to my knowledge it has never been tested in software development.)

The Buddhist notion of dukkha is helpful in any analysis of perfection. Buddhists accept as a core belief the idea that because the world is constantly changing, it cannot be in a state of perfection. As I understand it, dukkha is both the essential imperfection of life and the soul's inevitable dissatisfaction with the state of the universe.

I think the Japanese Zen concept of wabi-sabi, which is built upon a Buddhist foundation that includes dukkha, is likewise worth exploring. Wabi-sabi is an aesthetic principle. Wikipedia (which I am not above quoting when I am on deadline) says wabi-sabi ideals include “asymmetry, asperity, simplicity, economy, modesty, intimacy, and appreciation of the ingenuous integrity of natural objects and processes.” The site quotes Richard R. Powell, author of a 2004 book on wabi-sabi, who says the aesthetic acknowledges three simple realities: “nothing lasts, nothing is finished, and nothing is perfect.” It seems the Zen masters anticipated the Agile movement by several centuries.

The tendency toward perfectionism is natural in human beings and, I think, pretty much universal in programmers. Compilers reinforce our natural tendency to pay attention to the tiniest of details.

Ward Cunningham coined the term “technical debt” to refer to imperfections in source code. Speaking at OOPSLA in 1992, Cunningham said: “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite...Every minute spent on not-quite-right code counts as interest on that debt.”

Others have expanded on Cunningham's acute observation. Many note that just as businesses justifiably and deliberately take on debt to meet major goals, so a development team might reasonably incur technical debt in the service of a sufficiently high priority. This trade-off is implicit in Agile development.

At this point, I should be offering an assessment to help you identify whether you have succumbed to perfectionism on the job, plus a few tips on overcoming the malady. That's what the architecture of the magazine article requires. (Despite making hundreds of blog posts over the years, I don't understand the structure of the blog post, and I keep writing magazine articles. TL;DR, as they say in the online communities.)

But after hours of online research, I have no advice to offer. Articles that promise to help readers overcome perfectionism are packed with touchy-feely nonsense. Tech sites advise developers to weigh the costs of shipping a few bugs versus the cost of fixing them – advice that is simultaneously impossible to follow in the real world, wrong-headed, and almost certain to transform the developer's satisfying career into an unrewarding hell on earth.

Even the fabulously smart Joel Spolsky, whose Joel on Software I crib from when the rest of the Internet lets me down, backed down when he addressed this topic. After building a rigorous demonstration of why it makes economic sense to let certain imperfections remain in a code base, he closed with these weasel words: “With all that said, I'm optimistic at heart, and I believe that there is a lot of hidden value to producing very high quality products...So I tend to err on the side of quality (indeed, we fixed every known bug in FogBUGZ, not just the big bang ones) and take pride in that...”

Given an overwhelming absence of useful advice on this subject, I'll hazard one original thought. I think perfectionism is natural, inevitable, and desirable in software developers. Coders should always include perfectionism as part of their motivation for learning, exploring alternatives, tinkering, debugging, and rethinking. The tendency to pursue perfection makes developers more valuable.

Projects go astray, however, when that tendency is given free rein. For that reason, managers – not developers – must cultivate a big-picture perspective so they can call a halt to endless development cycles that no longer justify their cost.

I realize I am merely shifting the burden of combating perfectionism to someone else, not solving it. But the bottom line is that this is precisely the soft of task management was invented to perform. We count on managers to monitor the big picture and ship the code when it's time. Evaluating the trade-off between costs and benefits is what managers are good for.

Web recommendation: Larry O'Brien and I continue to poke holes in the persistent notion that our industry has, and needs, superprogrammers. My experience is that many excellent coders suffer from personality traits – elitism, dismissal of others' talents, endless self-congratulatory back-patting – that would make me avoid working with them even if they were as good as they thought they were. Development-industry traditions make the situation worse, perpetuating the myths and lionizing the arrogant. One harmful bit of intellectual scaffolding that supports this harmful notion is the Dreyfus Model of Skill Acquisition. The Dreyfus Model doesn't explain skill acquisition at all. Its purpose is to classify learners into five slots, from Novice to Expert. According to the model, once you've attained the Expert level, rules no longer apply to you. You're a master of improvisation and your hunches are more valuable than weeks of earnest coding by those who follow the rules. Blah blah blah. This stuff is both offensive and wrong-headed. As it turns out, the text in which the Dreyfus brothers summarize their research is mostly supportable. It seems the model has been misused since then to excuse self-aggrandizement. The original Dreyfus paper is worth reading. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He spent much longer writing this post than he expected to.

We all know that women are a minority in software development. This bothers us because it's not consistent with how we view the development world. In the ideal profession that exists in our minds:

• All coders have an equal opportunity to be hired – all that matters is the quality of their work.

• Once on the job, developers are treated fairly regardless of gender, race, and other factors – all that matters is the quality of their work.

• Compensation and advancement are awarded fairly in proportion to developers' contributions – all that matters is the quality of their work.

In other words, we view the world of software development as an open meritocracy.

The truth is more complicated. White men are hired disproportionately over other candidates with equal qualifications. Women programmers are widely subjected to discrimination and hostile work environments. And women are under-compensated and under-promoted compared to equally qualified men. We don't want to believe these things, but study after study confirms them. These are the facts.

According to the Labor Department's Bureau of Labor Statistics, women make up 58 percent of the workforce, but only 25 percent of the computing workforce. Between 2000 and 2009, the the percentage of women in the computing workforce dropped 13 percent, while the percentage of men in computing increased 11 percent.

A study by the London Business School revealed that software development teams are most innovative and efficient when they are composed of 50 percent men and 50 percent women. Any other ratio yields lower innovation and lower efficiency. Yet women remain under-represented.

Most of us are uncomfortable with these truths. We'd like to alter the reality to make it conform with our ideals.

Initiatives to open our field to full participation by women have largely been of two kinds.

Some address the “pipeline problem.” The idea is that women are under-represented in high-tech careers because our colleges and universities prepare too few qualified female candidates. Proposed solutions to the pipeline problem can be very inventive. Some activists start with research showing that boys and girls accept gender roles as toddlers, and advocate a wholesale revolution in the way society regards femininity. More commonly, activists attack the pipeline problem by creating incentives for young women to choose technical majors in college.

The second major focus has been networking. Women in tech have formed myriad organizations to provide information and support to other women. These peer-support organizations have attracted high-profile advocates, women who have beaten the odds and ascended to executive positions in high-tech firms.

Neither of these approaches can eliminate the systematic exclusion of women from an equal role in software development. To welcome women into our field – and make our teams more innovative and efficient as a happy result – we must start by accepting the truth about the barriers that currently exist. Then we must change the world. By changing ourselves.

Web recommendation: Unlikely, creative, outstanding nerdy projects! I love this site. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He woke up unaccountably happy this morning. Don't you love it when that happens?

Apple is regaining a place of central importance in the technology world that it hasn't held since the 1970s.

For decades, it was easy to dismiss Apple as a niche vendor of overpriced boutique systems – nice systems, but not mainstream, and certainly not viable targets for most development projects. But that view is obsolete. Apple's dominance of mobile platforms, and its ability to leverage that dominance across the laptop and desktop markets, make the company a formidable force in our field. And, increasingly, a magnet for development efforts.

Here's what's new at Apple:

2011 iOS sales surpass 28 years of cumulative Mac sales. A Finnish market analyst named Horace Dediu, who blogs at asymco.com, plucked some statistics from a presentation made by Apple CEO Tim Cook at a Goldman Sachs conference in San Francisco last week. The really interesting conclusion is that Apple sold more iOS-based devices in 2011 than it sold Macintosh computers, ever. It's an astonishing accomplishment, and I think it's something developers should be thinking carefully about. You can read the transcript of Cook's presentation here and Dediu's short analysis – which includes a killer chart – here.

iOS apps are quietly acquiring and storing user data. Apple is the latest company to get stung by this sort of problem. It turns out that a bunch of the most popular apps in Apples App Store upload user data – including the user's entire contact list – to the software vendors' servers. The vendors hang on to this information indefinitely. The public outcry has been intense, and members of Congress are questioning Apple about the apps. This kind of bad behavior is already prohibited by Apple policy. iOS apps are supposed to notify users that their data will be uploaded and ask for permission. But vendors have not always observed the policy. Apple says it will address this issue, but no one really knows what that means. It could issue a statement to the development community, it could police the App Store more strictly, or it could modify APIs to require that permissions are acquired (and that data is encrypted before transmission). There's a pretty good article about this at Ars Technica.

OS X Mountain Lion will include iOS features. Apple is readying the next version of its OS X operating system for the Mac. Like all recent releases, it is based on the NextStep OS Apple acquired when it bought Steve Jobs's Next Computing and restored Jobs to Apple's top job. But the new version of the OS will apparently include a bundle of programs ported from iOS, including Messages, Notes, Reminders, Game Center, Notification Center, Spare Sheets, OS-wide Twitter integration, and AirPlay Mirroring. Many of the apps will allow synching between OS X and iOS devices. Registered Mac developers can download Mountain Lion now.

Mountain Lion's Gatekeeper feature generates controversy. Apple has built a controversial feature into the new version of OS X. Gatekeeper is a “security feature” that, in its default configuration, prevents users from installing apps unless the apps come from Apple's App Store or a certified OS X developer. Users who wish to install other applications – those written by members of the IT department, say – must override Gatekeeper's default settings. It's one more way Apple is trying to isolate and maintain control over its users.

New iPad(s) to be introduced in early March. Rumor-mongers – including the Wall Street Journal – are predicting that Apple will introduce at least one new iPad in the coming weeks. The consensus is that the iPad 3 will have LTE support for 4G connectivity. Apple may also introduce a lower-priced version of the iPad with an eight-inch screen, perhaps to steal sales away from Amazon's Kindle Fire.

A labor rights activist group will audit Apple's manufacturing facilities in China. As you know from my previous posts, Apple is receiving lots of criticism for low pay, bad working conditions, and terrible living standards at the Chinese companies that manufacture, assemble, and package its hardware. (The same companies also work for other high-tech firms, but Apple has taken the brunt of the criticism because its connections with the Chinese firms have been widely publicized.) The most widely known of the Chinese companies is called Foxconn. Apple responded to the criticism by asking the Fair Labor Association to conduct an audit of its Chinese partners. Meanwhile, Foxconn has raised its workers' hourly wages, which were already high by Chinese standards. The Fair Labor Association's CEO has conducted a preliminary visit to Foxconn, and told reporters, “We're finding tons of issues.”

New CEO changes Apple culture in at least one tangible way. Under Steve Jobs, Apple was notoriously stingy when it came to charitable giving. Tim Cook appears to be changing that. One of the new CEO's first actions was to establish a matching program for employees' charitable donations, under which Apple will match employees' donations dollar-for-dollar up to $10,000 per year. In a recent companywide address, Cook detailed corporate level giving, including $50 to Stanford's hospitals and another $50 million to Project RED.

There's plenty more news. Apple has posted a new getting started guide for iOS on its Web site for developers, the iOS Developer Library. And every day brings more news regarding patent lawsuits, both those directed toward Apple and those initiated by Apple and directed toward others. The iPad is legally banned in some Asian locales because judges have ruled that the name infringes on a Hong Kong company's trademark, but it appears that Apple jumped through all the right hoops when it acquired the trademark a few years ago. And much much more.

Keep hacking.

Web recommendation: Long before the Agile Manifesto was written, Mark Twain was advocating Agile principles – or so say the troublemakers at Agile Scout, a site that mixes occasional humor with serious news about Agile development. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He has been studying the field of business intelligence and has come to think this technology has real promise.

Want a free book? I mean, who doesn't like free things? If you do (and we're thinking you do) and you want to learn more about jQuery, this giveaway is for you. 

Like us on Facebook and share this with your friends on Google+ and Twitter. 

We will pick a winner once we've gotten to 200 likes on Facebook. The book is available on Feb.28 and you can read more information about it here. We've got the first chapter as well. We've also got one more surprise form our Friends at Apress, but you'll have to help us get to 200 likes before we share that. 

So run and like us, and tell your friends to, too. 

I've been thinking about literate programming lately.

LP is the brainchild of legendary algorithm-master Donald Knuth, one of our field's undisputed deep thinkers. For the past 50 years Knuth has been toiling on his masterwork, The Art of Computer Programming, an encyclopedic exploration of algorithms, languages, and compilers. Knuth has finished just three of the planned seven volumes in his first 50 years of work, but it's not entirely his fault. He gets distracted. Disappointed with the state-of-the-art in typesetting when he published the first volume, for instance, he took some time off to create TeX and METAFONT.

Knuth introduced LP in an article called “Literate Programming” that appeared in the British Computer Society's Computer Journal in 1984.

The idea behind LP is that developers should write text that describes each aspect of their programs along with the code, in the same file, using a markup language to signal logical structure (headings, subsections, and so on). Special tools make the text visible and invisible, and strip out the text before compilation.

Knuth argued that describing code in prose would lead programmers to think more carefully about what their code did and how it operated. A mental feedback cycle would be established as the programmer wrote the text and the source code, and the result would be better software.

“The practitioner of literate programming,” Knuth wrote, “can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.”

LP aficionados flame anyone who suggests that LP is just a mechanism for writing better-documented code. They emphasize that the programmer is really writing an essay about the intentions behind the code, and explicitly explaining how those intentions are mapped into source code. It's not just documentation. It's not just a discipline. It is a (dare I say it?) paradigm.

A central assumption behind LP is the notion that programmers can write well-structured essays that explain the why and how of their code. I'm skeptical about that. Going back to college showed me that the ability to write a well-structured essay is surprisingly rare (even at Columbia). Anyone with the ability to organize his thoughts sufficiently to write an essay about their code probably doesn't need help getting the code organized properly.

In other words, literate programming can help only those who least need its assistance.

The tools page at literateprogramming.com seems a bit out-of-date, but it provides a list of LP tools for use with different languages. A quick search of the Web turned up dozens more, most of them free. If you want to get started with LP, there's no reason to hesitate.

But modern operating environments have brought substantial formatting capabilities to source code editors, and I think those capabilities have rendered LP obsolete.

Yes, we should embed more and better documentation in our code. But once we've made that commitment, LP and LP tools don't bring much to the table.

Web recommendation: Computerworld's Preston Gralla is a super-smart guy and I've learned a lot from reading his columns over the years. But I think he's missed the mark with his latest effort. Gralla argues that those who are urging Apple to insist upon better working conditions for the offshore workers who manufacture its products must be prepared to pay more for Apple products. I think Gralla missed an obvious point. Apple could invest more in worker safety and working conditions without raising prices if it were willing to reduce its legendary profit margins somewhat. Apple is a profit machine. In the final quarter of 2011 the company had revenues of $46.33 billion and quarterly net profit of $13.06 billion. The company has $97.6 billion in the bank. Sharing some love with abused workers in overseas sweatshops shouldn't force Apple to raise prices. Gralla's article is here. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He feels virtuous today because he spent the morning mopping floors.

Job burnout is very common and more serious than you probably think. Psychologists say most people suffer from at least a mild form of burnout at some point in their lives. It can have severe consequences...you shouldn't take it lightly.

How do you know you're burnt out? The Mayo Clinic says you should ask yourself these questions:

• Have you become cynical or critical at work?

• Do you drag yourself to work and have trouble getting started once you arrive?

• Have you become irritable or impatient with co-workers, customers or clients?

• Do you lack the energy to be consistently productive?

• Do you lack satisfaction from your achievements?

• Do you feel disillusioned about your job?

• Are you using food, drugs or alcohol to feel better or to simply not feel?

• Have your sleep habits or appetite changed?

• Are you troubled by unexplained headaches, backaches or other physical complaints?

You don't have to answer affirmatively to all of these questions, or even to most. Answering yes to even one symptom could be a sign of on-the-job burnout. (It could also point to depression, or even a thyroid disorder. So you should probably see a doctor.)

The factors that cause burnout are familiar to most programmers:

Excessive workload: You are overwhelmed by the excessive amounts of work you must manage on a daily basis without sufficient downtime.

Lack of personal control: If you don't have the authority to decide what needs to be done and how to do it, you're at risk. Everyone needs some flexibility to do their work the way they want to.

Lack of recognition: If your work isn't adequately valued or acknowledged, you're at risk of burnout. There are far too many managers who give only negative feedback.

Role ambiguity: Managers in our field don't have the best reputation regarding clear expectations. Many just wave their hands and expect you to figure out what needs doing and how to do it. If it's not clear what is expected of you, you may be at risk of burnout.

Limited opportunities for advancement: No one wants to feel that he'll spend his whole life on the same treadmill.

Lack of teamwork: If your team doesn't work together well, that may contribute to burnout. Is the load shared unevenly or unfairly? Do you always get the boring part of the job? Are you undermined by your colleagues, or criticized unfairly?

Uninteresting work: Are you interested in the work you do? Many of us get into the field because we love the challenge of solving algorithmic puzzles. No doubt you have noticed by now that this is a very small part of the job. Are the tools you use and the applications you write a good fit for you? If not, you may be at risk of burnout.

Extreme pace: Does your team always work at a breakneck pace? Or is it a sleepy environment with too few real challenges? Either one can contribute to burnout.

Poor corporate values: Do you believe your company is essentially unethical? If your job is to contribute to the success of a company that isn't aligned with your values, you may be vulnerable to burnout.

If you're burned out, you may suffer from insomnia, stress, deteriorating personal relationships, anxiety, fatigue, depression, and alcohol or substance abuse.

What's to be done? Well, you've got two options. You can endure the burnout and hope it goes away, or you can address the issues. If you decide to take action, you've got to change the environment or change yourself – probably a little of both. The Mayo Clinic offers this advice:

First, evaluate your situation and identify the factors that are contributing to burnout. You can't solve the problem until you define it – every programmer knows this. (And every programmer I've ever known forgets it regularly, but that's a story for another day.)

Next, figure out if your job can be restructured to make it more engaging and rewarding. Your manager may be a resource. You might choose to work at home part-time, to switch to more flexible hours, to shift your responsibilities, to take night classes, or to act as a mentor to a newcomer. Be creative – you may come up with a solution that benefits the company while making your work life more tolerable.

Don't forget to do some work on your attitude. Remind yourself why you got into programming in the first place. Reward yourself with short breaks. Spend time talking with colleagues. Combat cynicism.

Reach out for support. Family members, colleagues, and friends are likely to be supportive if you tell them what's going on. Your doctor may be able to hook you up with a support group for burnout victims. Your company may offer confidential counseling services. Don't hesitate to tap these resources.

Finally, do a serious self-inventory. Are you in the right job? Are you even in the right field? Maybe you want to work part-time while working toward a law degree. Or turn down overtime so you can finally finish that novel.

If you need to make a change, make it. You only get one life, so you've got to make the best of it while you can.

Good luck.

Web recommendation: This video made me laugh out loud! J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He is no stranger to burnout, but just now he's doing fine.

Statistics tell me that I get lots of extra readers when I write about Agile development. And why not? The Agile movement is the most interesting trend in software development right now.

I would argue that coding for multicore processors is at least as important as making a move to Agile. So are testing methods and security, security,security. But these are technical problems, not philosophical paradigm shifts.

The problem with Agile is that it isn't really a development method, or even a philosophy. It's an aesthetic. It's a system of values. Heck, the document that started it all, the Agile Manifesto, is written as a statement of values. The Agile movement is little more than a statement of values. The values are intended to serve as a touchstone for developers as they make decisions about how to build teams and applications.

So the modern approach to software development is based on a the value system outlined in the Agile Manifesto. So if we're to evaluate the state-of-the-art in software development, we should start by evaluating those values.

There's just one problem. As many others have pointed out, the values are both vague and obvious. There's nothing revolutionary about any of the four values espoused in the manifesto. They're simple common sense.

Of course our development projects should be agile. The opposite of agile is slow and clumsy. Who would choose slowness and clumsiness over agility?

Translating an aesthetic statement into a guideline for real-world team structures, workflows, and development models is a nontrivial task. The values turn out to be the easy part. Developing software is still hard. Pair programming and unit testing and daily builds are consistent with the values espoused in the Agile Manifesto, but they are separate innovations in their own right. They would be good ideas with our without the manifesto.

When you describe your team or your values or your project-management philosophy as agile, all you're really saying is that it's good. Based on straight thinking about priorities. You're not saying anything technical and you sure aren't cutting software development's many challenges down to size. You're just expressing agreement with a handful of uncontroversial tautologies. Sure, we like Agile processes. We also prefer code that works. And projects that are finished on time. And teams that come in under budget.

Commitment to Agile isn't enough anymore. What are you really doing to improve your process?

Web recommendation: Today marks the 200th anniversary of the birth of Charles Dickens. The writer's contributions to literature are too easily overlooked these days. Certainly, many of his novels and stories now appear quaint, needlessly complicated, wordy, and baroque. But Dickens made lasting contributions to characterization, plot, and fiction's role as social commentary. Check out his life and accomplishments at Dickens 2012, a Web site created by the Charles Dickens Museum and Film London in association with The Dickens Fellowship.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He is currently rereading Salman Rushdie's masterful Midnight's Children, which offers no small debt to Dickens's innovations.

You gotta hand it to the guys at RIM. After a terrible 2011, culminating in the removal of its chief executives, the company is still kicking. Like the Duracell bunny, the company keeps going and going and going.

Service outages, eroding market share, layoffs, plunging stock prices...the news has been nothing but bad for RIM. But the Canadian company, under the leadership of new president and CEO Thorsten Heins, isn't giving up.

RIM's latest strategy is to encourage the development of new apps for the BlackBerry platform. And just how will RIM woo developers? By bribing them.

Until February 13, every Android developer who ports an app to the BlackBerry's virtual Android environment, the Android App Player, will receive a 16GB BlackBerry PlayBook tablet.

The arrangement was announced in a tweet by RIM vice-president of developer relations Alec Saunders. To qualify, developers must submit their Android apps to RIM's App World before Valentine's Day.

Introduced in April 2011, the PlayBook has been one of RIM's disappointments, selling a few hundred thousand units compared to Apple's tens of millions. One barrier to the tablet's adoption has been the relative scarcity of applications – hence RIM's announcement.

The 16GB PlayBook is widely available online for $299 or less.

Web recommendation: Well. This is horrifying, cool, and I suppose promising. What a crazy future we appear to be headed toward. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. It snowed so hard in Serbia yesterday that someone has posted a YouTube video of himself snowboarding the streets of Belgrade, towed by a car. Darwinism in action or just another day in the Balkans? You be the judge.

Hiring managers often search job boards, read emails and scour resumes to find the perfect candidates. Now, your job may be a little easier with a company called GitHire. 

GitHire offers a Web service -- for $1000 they'll find five engineeres interested in interviewing with your company. According to their website, they scour Git repositories for you in order to find the best and brightest. 

Software engineers are offered an interview with a company they may be a match for and if they say no, they say no -- no strings, no questions. 

The NY Times wrote an extensive piece on the service and we thought it might be interesting to share with you. Would you (or have you) used a headhunter service?

The terms “hacker” and “social network” don't really go together. Social networks are gathering places for n00bs and kids. Real hackers don't use services like Facebook – they build them. Heck, real hackers are probably too cool even to build them. They'd rather implement obscure networking protocols or write compilers for multicore processors or build robotic systems.

That's what I've always thought, anyway. But according to Facebook founder and CEO Mark Zuckerberg, hacking is a core value at Facebook, not just among the coders, but as a way of seeing the world.

Zuckerberg's statement appears on page 69 of Facebook's Securities and Exchange Commission S-1 form, which the company filed yesterday as a matter of law as the first step in its initial public offering, the process whereby a privately held company issues stock for sale to the public. The S-1 statement is full of boilerplate legalese, but it offers interesting glimpses into Facebook's history, finances, business model, and future plans. The document includes a letter to shareholders from Zuckerberg. Such letters are often included in S-1 filings, but they are not required.

It is in the shareholders' letter that Zuckerberg claims that Facebook operates according to a set of principles he calls “the Hacker Way.” The idealistic statement includes a few elements of the Agile Manifesto mixed with a description of Facebook's internal tech process:

As part of building a strong company, we work hard at making Facebook the best place for great people to have a big impact on the world and learn from other great people. We have cultivated a unique culture and management approach that we call the Hacker Way.

The word “hacker” has an unfairly negative connotation from being portrayed in the media as people who break into computers. In reality, hacking just means building something quickly or testing the boundaries of what can be done. Like most things, it can be used for good or bad, but the vast majority of hackers I’ve met tend to be idealistic people who want to have a positive impact on the world.

The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it — often in the face of people who say it’s impossible or are content with the status quo.

Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once. To support this, we have built a testing framework that at any given time can try out thousands of versions of Facebook. We have the words “Done is better than perfect” painted on our walls to remind ourselves to always keep shipping.

Hacking is also an inherently hands-on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: “Code wins arguments.”

Hacker culture is also extremely open and meritocratic. Hackers believe that the best idea and implementation should always win — not the person who is best at lobbying for an idea or the person who manages the most people.

To encourage this approach, every few months we have a hackathon, where everyone builds prototypes for new ideas they have. At the end, the whole team gets together and looks at everything that has been built. Many of our most successful products came out of hackathons, including Timeline, chat, video, our mobile development framework and some of our most important infrastructure like the HipHop compiler.

To make sure all our engineers share this approach, we require all new engineers — even managers whose primary job will not be to write code — to go through a program called Bootcamp where they learn our codebase, our tools and our approach. There are a lot of folks in the industry who manage engineers and don’t want to code themselves, but the type of hands-on people we’re looking for are willing and able to go through Bootcamp.

Not bad, huh? Zuckerberg's letter hasn't convinced me that Facebook is as cool a social network as – oh, reddit, for example. Nor that it would be a great place for programmers to work (though I have read that it is). Still, I give Zuckerberg credit for his letter. He didn't have to say all of that.

You can read the whole S-1 statement here. Take a look. I found it pretty interesting.

Web recommendation: David Letterman just celebrated his 30th anniversary as a late-night talk-show host. I don't watch him anymore, but I remember when he burst onto the scene, replacing old-style comedians with an engaging, self-deprecating, thoroughly distinct voice. Letterman's ironic comedy and laid-back style have become the template for a new generation of hosts. The Huffington Post has collected a series of memorable moments from Letterman's 30 years on late-night TV. I watched them this morning and marveled anew at the comic's genius. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He made a passable turkey soup for lunch today.