Why Do We Have So Many Screwdrivers?

Jon Raynor added this comment to my previous post about keeping up with the pace of change in software development:

The IT field is basically a quagmire. It's better to accept that fact right away or move on to a different field. I guess someday I wish for Utopia where I won't be obsoleted when I get out of bed each and every morning.

The industry needs to stop running around like a chicken with its head cut off trying to find the next big thing. The tools constantly change, but yet they do the same thing, create code to run on machines. First we get a screwdriver and learn how to use it. Then out comes the newdriver, different than the screwdriver, but does the same thing. Then out comes the phewdriver which is totally different than the screw and new driver but performs the same function of both previous tools.

It's an interesting observation. I'm far from a handyman, but even I own many different screwdrivers: different sizes, different tips, different lengths. They're all performing the same job-- screwing*-- but each one is uniquely useful in the right scenario. I'd hate to throw out all the screwdrivers I own and opt for a one-size-fits-all approach. Sure, I may choose the standard screwdriver 90 percent of the time, but what about that other ten percent?

So a case can be made for having multiple languages and multiple tools, redundancies and all.

However, software developers are awfully eager to throw out existing tools for new ones. Unfortunately, these decisions are often based on myth and wishful thinking, and the decisions are typically made in favor of whatever the hot new thing of the moment is. Here are two mistakes that I see a lot:

1. Let's buy this whiz-bang power screwdriver that will double our productivity.

A silver bullet brand screwdriver, if you will. Just replace the word "Ada" with "Ruby", below:

One of the most touted recent developments is Ada, a general-purpose high-level language of the 1980's. Ada not only reflects evolutionary improvements in language concepts, but indeed embodies features to encourage modern design and modularization. Perhaps the Ada philosophy is more of an advance than the Ada language, for it is the philosophy of modularization, of abstract data types, of hierarchical structuring. Ada is over-rich, a natural result of the process by which requirements were laid on its design. That is not fatal, for subsetted working vocabularies can solve the learning problem, and hardware advances will give us the cheap MIPS to pay for the compiling costs. Advancing the structuring of software systems is indeed a very good use for the increased MIPS our dollars will buy. Operating systems, loudly decried in the 1960's for their memory and cycle costs, have proved to be an excellent form in which to use some of the MIPS and cheap memory bytes of the past hardware surge.

Nevertheless, Ada will not prove to be the silver bullet that slays the software productivity monster. It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition -- the transition up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions. Once those accidents have been removed, the remaining ones will be smaller, and the payoff from their removal will surely be less.

I predict that a decade from now, when the effectiveness of Ada is assessed, it will be seen to have made a substantial difference, but not because of any particular language feature, nor indeed because of all of them combined. Neither will the new Ada environments prove to be the cause of the improvements. Ada's greatest contribution will be that switching to it occasioned training programmers in modern software-design techniques.

2. This screwdriver is for amateurs and hacks. We should buy a newer, more professional screwdriver.

David Megginson notes the self-perpetuating cycle of successful programming languages:

• Elite (guru) developers notice too many riff-raff using their current programming language, and start looking for something that will distinguish them better from their mediocre colleagues.
• Elite developers take their shopping list of current annoyances and look for a new, little-known language that apparently has fewer of them.
• Elite developers start to drive the development of the new language, contributing code, writing libraries, etc., then evangelize the new language.
• Sub-elite (senior) developers follow the elite developers to the new language, creating a market for books, training, etc., and also accelerating the development and testing of the language.
• Sub-elite developers, who have huge influence (elite developers tend to work in isolation on research projects rather than on production development teams), begin pushing for the new language in the workplace.
• The huge mass of regular developers realize that they have to start buying books and taking courses to learn a new language.
• Elite developers notice too many riff-raff using their current programming language, and start looking for something that will distinguish them better from their mediocre colleagues.

It's OK to add a new screwdriver to your toolkit every few years. But make sure you're adding it for the right reasons.

* Yes, it's still funny.

Keeping Up and "Just In Time" Learning

Do you ever feel like you're buried under umpteen zillion backlogged emails, feeds, books, articles, journals, magazines, and printouts? Do you ever feel that you're hopelessly behind, with so much new stuff created every day that you can never possibly hope to keep up?

Well, you're not alone.

Via SecretGeek:

• You do NOT have to refactor all your code.
• You do NOT have to keep up with the latest news from microsoft, and know everythnig there is to know about longhorn, whidbey, avalon, XAML, indigo and star wars III.
• You do not have to have perfectly de-coupled tiers in your technology independent SOA software.
• You do not have to comply to every standard, achieve the perfect balance between maintainability and performance. Usability and familiarity.
• You don't have to do "first things first every day"
• You DO NOT have to memorize and understand every patten the gang of four have catalogued.
• You do NOT have to read every technical blog, print out every technical article and learn every technical thing there is to learn.
• You are beautiful just the way you are.
• You are brilliant, interesting, wise and fun to be around.
• You rock.

Via Kathy Sierra:

I remember when the first public release of Java came out, and it had 200 classes. You could fit the entire class library in the same space as Miss January. But then 1.1 came out and the API more than doubled to 500 classes. It no longer fit on a centerfold-- but you could get it on a wall poster. With 200 classes, you really could master the entire API. With 500, it took some effort, but you could at least be familiar with just about everything, given enough time. By Java 1.4, the library had swelled to 2300 classes. And today? It's something like 3500 classes just in the Standard Edition -- not including the mobile and enterprise extensions. You could wallpaper an entire room with the class library.

By the year 2000, it had become impossible for even a Sun Java engineer-- someone creating the API-- to be familiar with everything in the standard library. Yet the rest of us were feeling guilty. Like we were falling behind. Like we weren't hardcore Java programmers.

It's time to let that go. You're not keeping up. I'm not keeping up. And neither is anyone else. At least not in everything.

Kathy has a few suggestions to combat Information Anxiety:

• Find the best aggregators
• Get summaries
• Cut redundancy
• Unsubscribe from as many things as possible
• Recognize black holes (gaming, slashdot, etc)
• Pick categories for balance; include some from outside your main field
• Be more realistic about what you're likely to get to; throw the rest out
• In anything you need to learn, find someone who can tell you what is
  • Need to know
  • Should know
  • Nice to know
  • Edge case
  • Useless

I don't worry about keeping up with the Joneses; I focus on the specific problem at hand. I take a "Just In Time" attitude to learning new technology. I can't possibly learn everything. But I do try to learn enough to know what the new thing is, and when I might need it. Most of the time, I don't need it. And when I do, I can learn it Just In Time to help me solve the current problem I'm working on.

Of Spaces, Underscores and Dashes

I try to avoid using spaces in filenames and URLs. They're great for human readability, but they're remarkably inconvenient in computer resource locators:

1. A filename with spaces has to be surrounded by quotes when referenced at the command line:

   XCOPY "c:\test files\reference data.doc" d:\
   XCOPY c:\test-files\reference-data.doc d:\
   

2. Any spaces in URLs are converted to the encoded space character by the web browser:

   http://domain.com/test%20files/reference%20data.html
   http://domain.com/test-files/reference-data.html
   

So it behooves us to use something other than a space in file and folder names. Historically, I've used underscore, but I recently discovered that the correct character to substitute for space is the dash. Why?

The short answer is, that's what Google expects:

If you use an underscore '_' character, then Google will combine the two words on either side into one word. So bla.com/kw1_kw2.html wouldn't show up by itself for kw1 or kw2. You'd have to search for kw1_kw2 as a query term to bring up that page.

The slightly longer answer is, the underscore is traditionally considered a word character by the \w regex operator.

Here's RegexBuddy matching the \w operator against multiple ASCII character sets:

As you can see, the dash is not matched, but underscore is. This_is_a_single_word, but this-is-multiple-words.

Like NutraSweet and Splenda, neither is really an acceptable substitute for a space, but we might as well follow the established convention instead of inventing our own. That's how we ended up with the backslash as a path seperator.

A Blog Without Comments Is Not a Blog

James Bach responded to my recent post, Are You Following the Instructions on the Paint Can?, with Studying Jeff Atwood's Paint Can. I didn't realize how many assumptions I made in that post until I read Mr. Bach's pointed response. The most amusing assumption I made-- and I had no idea I was doing this-- was that I ran a painting business in college! The paint can instructions make sense to me because of that prior experience. Pity the would-be handyman who has never painted anything before and has only a few paragraphs of text on the back of a can to refer to.

But I'll reserve a complete response to Mr. Bach for later. My immediate frustration is that James has comments disabled on his blog, so I can't form a public reply to James without creating a post on my own blog.

I firmly maintain that a blog without comments enabled is not a blog. It's more like a church pulpit. You preach the word, and the audience passively receives your evangelical message. Straight from God's lips to their ears. When the sermon is over, the audience shuffles out of the church, inspired for another week. And there's definitely no question and answer period afterward.

Of course, I'm exaggerating for comedic effect. Maybe a blog with comments disabled is more analogous to a newspaper editorial. But even with a newspaper editorial, readers can make public comments by sending a letter to the editor, which may be published in a later edition of the paper.

However we slice it, with comments disabled the reader's hands are tied. If readers want to have a public dialog with you, then your readers must have blogs of their own. This strikes me as awfully elitist.

It's unreasonable to expect people that disagree with the tenets of your religion to build a church and start their own religion.

It's unreasonable to expect people that disagree with your newspaper editorial to buy a printing press and start their own newspaper.

And it's unreasonable to expect people to start their own blogs to make a public reply to your post.

Yes, the barriers to entry for blogging are radically lower, but not everyone has the time or inclination to become a full-bore blogger. Are you really comfortable saying, in effect, unless you have a blog I am not interested in what you have to say? Because I'm not.

That said, I realize that comments aren't appropriate for every blog in the world:

Blogs are susceptible to the same problems as social software sites (as well as having to deal with comment spamming scum). The more popular the blog, the bigger the problem. Just ask Heather or Jason.

Most blogs allow comments. There's no doubt about it; having comments enabled is likely to increase the popularity of your blog.

But that, in and of itself, is not a good justification. It assumes that popularity is desirable. The truth is that, when it comes to personal publishing, it's not the amount of people who visit that count, it's who those people are why they're visiting that's important.

Comments are a shortcut to a Pyrrhic victory of popularity at the cost of having your pages cluttered with pointless remarks (by pointless, I don't just mean the negative stuff: "me too!" and "great post!" achieve as little as "you suck!"). If popularity is your aim, it's better in the long run to claw your way towards that goal on the strength of your writing or design skills.

But comments can add value. They are particularly useful on sites that have a narrow, focused scope. The focused nature of the subject matter ensures that visitors share a common interest -- otherwise, they wouldn't be there. The more general a site's focus, the less chance there is of it receiving quality comments. A site that covers everything from politics (Republican vs. Democrat) to computing (Mac vs. PC) is going to be flame-war central.

Jeremy's observation about the effect of topic on comments is interesting. Again, something I wouldn't have anticipated based on my experience with a very focused blog.

However, to deny public conversation by disabling comments right out of the gate --based on the presumption that the comments will be of low quality -- is, again, awfully elitist. Have some respect for your audience. Enable comments and experiment before making the assumption that 90 percent of the comments will be crap! Personally, I've found that the comments can be the best, most informative part of a blog. Anyone who has visited Amazon and skipped directly to the user reviews will know exactly what I'm talking about.

Some people refuse to enable comments because they don't want to deal with the spam problem. I can appreciate this concern, but a simple CAPTCHA is extremely effective at blocking machine spam. And a simple daily browse of your comments will catch those rare manually entered spam comments. Why in the world would you enable comments if you're not planning to read them at some point?

I am sympathetic to issues of scale. Comments don't scale worth a damn. If you have thousands of readers and hundreds of comments for every post, you should disable comments and switch to forums, probably moderated forums at that. But the number of bloggers who have that level of readership is so small as to be practically nil. And when you get there, believe me, you'll know. Until then, you should enable comments.

The more I think about this, the more I keep coming back to my original position: a blog without comments enabled is not a blog. I'm not sure what it is, exactly, but it definitely isn't a blog.

Comments?

Web 2.0 and The "Whatever Box" Server

One of the key differences between the original dot-com bubble and the Web 2.0 bubble we're entering now is that our servers are a lot cheaper and a lot more powerful. Moore's Law in action isn't exactly news, but the new web is definitely powered by cheap "whatever boxes":

In the 10 years between Excite and JotSpot, hardware has literally become 100X cheaper. It's two factors – Moore's law and the rise of Linux as an operating system designed to run on generic hardware. Back in the Excite days, we had to buy proprietary Sun hardware and Sun hard drive arrays. Believe me, none of it was cheap. Today, we buy generic Intel boxes provided by one of a million different suppliers.

We recently specced out a new server at work and I was curious about this: exactly how much more powerful did servers get in the last six years?

The parts list for our homebrew server is saved in a newegg wishlist. I set out to find a year 2000 equivalent by looking up a typical Dell server on the mid-2000 internet archive of Dell's website. According to that page, an entry-level PowerEdge 4400 server started at $4,814. I can't get to the detailed spec pages, so I'm estimating the entry-level specs based on the many PowerEdge 4400 machines for sale on eBay.

Now, this comparison isn't entirely fair. The PowerEdge 4400 supports real hot-swappable power supplies and hardware RAID-ed hard drives; our homebrew rig has to be powered down to switch out a failed hard drive or (single) power supply.

But the general thrust of the comparison is still valid. In a nutshell, we get..

• 10x the network bandwidth
• 8x the memory
• 4x the memory bandwidth
• 16x the disk space
• 10x the CPU power

.. all for about one-third the price. And we have the luxury of running a commonly available 64-bit operating system in native 64-bit mode, too.

I would still argue that the the relative costs of software and hardware-- relative to the cost of human labor, I mean-- haven't changed that much in the last six years. But you can plainly see where this extravagant excess of server power makes it possible to use labor-saving software that wasn't viable in the year 2000. You can build your site on extremely high-level software, such as interpreted languages like Ruby and Python, and still scale across thousands of simultaneous user requests.. even on a single "whatever box" server.

If the User Can't Find It...

I was lucky enough to attend a week-long Human Factors International session on usability a few years ago*. As a developer with a long term interest in getting to the human root cause of so many programming problems, I loved it. One of the freebies from the course was this button:

It's excellent advice. I still have this button clipped to my mug boss to periodically remind me that, no matter how cool the feature may be, if users can't find it-- or understand it-- you're wasting your time. So make sure you have your priorities in order before you start: usability first, feature second.

Jensen Harris provided a striking example of this phenomenon in action today:

One of the most startling and consistent pieces of feedback we've received from the early deployments of Office 2007 Beta 1 has been: "It's great that you added the drawing tools to all of the Office programs! Now I don't need to create the drawings in PowerPoint and copy them into Word/Excel/Outlook..."

Surprised? I certainly was.

While the drawing and graphics engine has certainly been massively improved in Office 2007, the same basic drawing capabilities have been available in Word/Excel/PowerPoint since Office 97. Yet, again and again we hear stories about people assiduously creating drawings in PowerPoint and copying them over piece by piece into their Word or Excel document. I remember during a site visit watching a man create a simple flowchart in Excel which should have taken 3 minutes actually take 15 minutes because of all of the cross-application, clipboard, and windowing work it took to keep moving shapes between the apps.

When is a ten year old feature suddenly a "new" feature? When users can actually find it!

* HFI also has a great technical reference section on their site, which includes the archives of their UI Design Newsletter back to 1998. It's worth checking out if you haven't done so already.

The Cartoon Guide to.. Programming?

I recently found a link to a series of Larry Gonick's mathematical cartoons that were originally published in Discover magazine:

• Beauty and the Beasts (neural nets)
• Prime Time (cryptography)
• Proof Positive? (probabalistic proofs)
• Lumps, with Mother Nature (chaotic mixing)
• Speed (relativity)
• The Solution (traveling salesman's problem)
• Filler Up! (space-filling solids)
• The Bowerbird's Dilemma (game theory)
• El Topo (DNA topology)
• Portrait of a Problem (protein-folding energy landscsapes)
• It's the Pits (wavelets)

It's great stuff. Here's a sample panel from the one on cryptography:

I've followed Larry Gonick's work for ages. He's famous for his easy to grasp, beautifully illustrated treatment of complex topics -- as exemplified in the series of books he's published:

• Cartoon History of the Universe Vol I (1990)
• Cartoon History of the Universe Vol II (1994)
• Cartoon History of the Universe Vol III (2002)
• Cartoon History of the Modern World Vol I (ETA late 2006)
• Cartoon History of the United States (1991)
• Cartoon Guide to Chemistry (2005)
• Cartoon Guide to the Computer (1983)
• Cartoon Guide to the Environment (1996)
• Cartoon Guide to Genetics (1991)
• Cartoon Guide to (non)Communication (1993)
• Cartoon Guide to Physics (1992)
• Cartoon Guide to Sex (1999)
• Cartoon Guide to Statistics (1994)

Although I made fun of the Learn ASP.NET in 24 Hours meme, I am a big fan of learning subjects in cartoon form. You learn more when you're having fun doing it.

Windows Vista: Security Through Endless Warning Dialogs

Paul Thurrott's scathing article Where Vista Fails highlights my biggest concern with Windows Vista:

Modern operating systems like Linux and Mac OS X operate under a security model where even administrative users don't get full access to certain features unless they provide an in-place logon before performing any task that might harm the system. This type of security model protects users from themselves, and it is something that Microsoft should have added to Windows years and years ago.

Here's the good news. In Windows Vista, Microsoft is indeed moving to this kind of security model. The feature is called User Account Protection (UAP) and, as you might expect, it prevents even administrative users from performing potentially dangerous tasks without first providing security credentials, thus ensuring that the user understands what they're doing before making a critical mistake. It sounds like a good system. But this is Microsoft, we're talking about here. They completely botched UAP.

The bad news, then, is that UAP is a sad, sad joke. It's the most annoying feature that Microsoft has ever added to any software product, and yes, that includes that ridiculous Clippy character from older Office versions. The problem with UAP is that it throws up an unbelievable number of warning dialogs for even the simplest of tasks. That these dialogs pop up repeatedly for the same action would be comical if it weren't so amazingly frustrating. It would be hilarious if it weren't going to affect hundreds of millions of people in a few short months. It is, in fact, almost criminal in its insidiousness.

We have fairly recent internal builds of Vista for a project we're working on at Vertigo, and we've run into this problem too. Even though you're ostensibly logged in as an "Administrator", you're inundated with a sea of security dialogs if you try to do anything even remotely, well, Administrator-y.

The problem with the Security Through Endless Warning Dialogs school of thought is that it doesn't work. All those earnest warning dialogs eventually blend together into a giant "click here to get work done" button that nobody bothers to read any more. The operating system cries wolf so much that when a real wolf-- in the form of a virus or malware-- rolls around, you'll mindlessly allow it access to whatever it wants, just out of habit. As Rick Strahl notes, this is the ultimate form of nagware:

Then there are the security dialogs. Ah yes, now we're making progress: Ask users on EVERY program you launch that isn't signed whether they want to elevate permissions. Uh huh, this is going to work REAL WELL. We know how well that worked with unsigned ActiveX controls in Internet Explorer – so well that even Microsoft isn't signing most of its own ActiveX controls. Give too many warnings that are not quite reasonable and people will never read the dialogs and just click them anyway… I know I started doing that in the short use I've had on Vista.

But there's an even deeper problem lurking under the surface. Why doesn't Vista respect my choice to be an Administrator? Who is really in control here: me, or my operating system? There's something awfully paternalistic about an operating system that lets me log in as an Administrator, but treats me like a regular User. If you're going to treat me like a User, at least have the decency to create a regular User account for me. That would certainly make more sense.

Rick Strahl confirmed that, indeed, Vista downgrades Adminstrators to regular Users by default, in a misguided attempt to enhance security. He also posted a workaround that applied only to the Vista Beta. But the good news is that in the final, released version of Vista, it's quite easy to disable UAC:

1. Launch Control Panel
2. Type "UAC" in the search box at the upper-right hand corner of the window
3. The option to disable UAC is the first search result.

Then log off and log back on.

I seriously hope Microsoft reconsiders these bizarre policies before Vista is released, but sadly they did not.

1. Let administrators really be Administrators!
2. Create all new users by default as plain Users. If a user opts to upgrade to an Administrator, that's the appropriate time to pop the scary warning dialog.
3. If a user tries to do something that requires Administrator rights, show a dialog telling them so, and offering links to a) log in temporarily as an Admin, or b) enter the Admin credentials in-place for a quick one time operation.

It could be so much simpler if Microsoft just followed the established conventions.

Remote Desktop Tips and Tricks

I'm with K. Scott Allen: the pervasiveness of Remote Desktop functionality in Windows has fundamentally changed the way I work.

The fact that it shipped in the Windows XP box-- and as a default component of all the server operating systems since Windows 2000-- has done wonders for its adoption. It's truly ubiquitous. And it doesn't hurt that it's actually the best performing remote control tool I've ever used; I have yet to try any other remote control tool that performs as well. It's so responsive that it almost makes the idea of physically sitting in front of a computer seem quaint.

Almost.

One thing you quickly learn with Remote Desktop is that not all the windows shortcut keys work as you would expect them to. The "Apply Windows key combinations" setting defaults to "full screen only", so you may see different behavior depending on whether or not you're running full-screen; use the Ctrl+Alt+Pause shortcut to switch back and forth.

The help file contains a list of the special Remote Desktop key combinations:

Alt + Page Up

Switches between programs from left to right.

Alt + Page Down

Switches between programs from right to left.

Alt + Insert

Cycles through the programs in the order they were started.

Alt + Home

Displays the Start menu.

Ctrl + Alt + Break

Switches the client between a window and full screen.

Ctrl + Alt + End

Brings up the Windows Security dialog box.

Ctrl + Alt + Pause

Toggles between fullscreen and windowed mode
(note that this does not set the client desktop to the correct size)

Alt + Del

Displays the Windows menu

Ctrl + Alt + Num -

Places a snapshot of the client's active window on the clipboard

Ctrl + Alt + Num +

Places a snapshot of the client's entire desktop area on the clipboard

To shut down or restart the remote computer, either bring up the Windows Security dialog , or use Task Manager.

Scott also provides a great list of additional resources for hacking Remote Desktop:

• Shadowing the current login session with Windows Server 2003
• Shadowing the current login session with Windows XP (aka Remote Assistance)
• A description of the .RDP file format
• Managing Remote Desktop Sessions Remotely (or use the GUI tool)
• Connect to Remote Desktop via Linux
• Change the default Remote Desktop listening port

I have two tips of my own. The first has to do with multiple monitors. Both my work and home computers have three monitors. Before you laugh, guess who else was on the three monitor tip back in the day? Google's Larry Page. And Bill Gates. At any rate, I've gotten at least one email on this, so I know it's not easy to figure out. Here's how you run a remote desktop session maximized to a particular monitor:

1. Start a windowed (non-fullscreen) remote desktop session
2. Drag the windowed session to the monitor you want
3. Close the remote desktop session
4. Set the properties for the connection to "full screen". It must be "full screen", not the actual resolution of your monitor (1280x1024, etc).
5. Start a remote desktop connection; it'll be full screen on the target monitor

I know it's convoluted. But at least it remembers which monitor it is full screen to. It'd be simpler if we had a way to change the client desktop size without closing and re-opening the connection, say via the display properties dialog. But we don't.

Here's my second tip: if you're not on a fast LAN, drop the color depth down to either 256 or 15-bit color, and select "Modem" on the Experience tab. Color depth is the single biggest contributor to performance over a slow connection. You may be tempted to go to 16-bit color or even 24-bit color to make things look prettier, but remember all those additional bits have to be transmitted across the wire. I know 256 colors can look desperately bad with most of today's websites and applications-- but 15-bit color is a good compromise.

Are You Following the Instructions on the Paint Can?

We're currently undertaking some painting projects at home. Which means I'll be following the instructions on the paint can.

But what would happen if I didn't follow the instructions on the paint can? Here's a list of common interior painting mistakes:

The single most common mistake in any project is failure to read and follow manufacturer's instructions for tools and materials being used. In regard to painting, the most common mistakes are:

• Not preparing a clean, sanded, and primed (if needed) surface.
• Failure to mix the paints properly.
• Applying too much paint to the applicator.
• Using water-logged applicators.
• Not solving dampness problems in the walls or ceilings.
• Not roughing up enamel paint before painting over it.

What I find particularly interesting is that none of the mistakes on this checklist have anything to do with my skill as a painter. My technical proficiency (or lack thereof) as a painter doesn't even register! To guarantee a reasonable level of quality, you don't have to spend weeks practicing your painting skills. You don't even have to be a good painter. All you have to do is follow the instructions on the paint can!

Sure, it seems like common sense. But take a close look at the houses on the streets you drive by. Each street has that one house where the owners, for whatever reason, chose not to follow the instructions on the paint can.*

For years, software development was an entire subdivision of badly painted houses. But the field of software development is now mature enough that we have a number of paint cans to refer to. Here's one such checklist from Joel Spolsky, circa 2000:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

The type of paint can you choose-- and the instructions you follow-- are highly debatable, of course. But make sure, at the very least, you're following the instructions on the paint can for your software development project.

* oddball color choices notwithstanding