Joel on Software

Joel on Software   Joel on Software

 

Other Joel on Software Articles in Your Language

Other Joel on Software articles in English

Email The Author

 

User Interface Design for Programmers

Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9

Picking a Ship Date
Wednesday, June 01, 2005

One of the best reasons to make a detailed schedule is because it gives you an excuse to cut features. If there's no way to make the ship date and implement Bob's Singalong MP3 Chat feature, it's easy to cut that feature without making Bob feel bad. So my basic rule for software release cycles is: 1. Set a ship date, which might as well be arbitrary

2. Make a list of features and sort them out by priority 3. Cut low-priority features every time you slip so as to make the date.

The Road to FogBugz 4.0: Part I


Friday, May 20, 2005

Most of our customers, thankfully, understand that the idea here at Fog Creek is to make shrinkwrapped, off-the-shelf software that you buy for a low price and it already does what you need, and if it doesn't, well, we'd like to hear about that, but for $99 you're not getting a customized version of the software, sorry.

Advice for Computer Science College Students
Sunday, January 02, 2005

Most college students, fortunately, are brash enough never to bother asking their elders for advice, which, in the field of computer science, is a good thing, because their elders are apt to say goofy, antediluvian things like "the demand for keypunch operators will exceed 100,000,000 by the year 2010" and "lisp careers are really very hot right now." I, too, have no idea what I'm talking about when I give advice to college students. But that's never stopped me from writing before. College Advice

Camels and Rubber Duckies


Wednesday, December 15, 2004

“When you're setting a price, you're sending a signal. If your competitor's software ranges in price from about $100 to about $500, and you decide, heck, my product is about in the middle of the road, so I'll sell it for $300, well, what message do you think you're sending to your customers? You're telling them that you think your software is ‘eh.’ I have a better idea: charge $1350. Now your customers will think, ‘oh, man, that stuff has to be the cat's whiskers since they're charging mad coin for it!’”  Camels and Rubber Duckies

Please Sir May I Have a Linker?
Wednesday, October 13, 2004

Here's what a linker does. It combines the compiled version of your program with the compiled versions of all the library functions that your program uses. Then, it removes any library functions that your program does not use. Finally, it produces a single executable binary program which people can run on their computers. Please Sir May I Have a Linker?

How Microsoft Lost the API War
Friday, October 08, 2004

Although there is some truth to the fact that Linux is a huge threat to Microsoft, predictions of the Redmond company's demise are, to say the least, premature. Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. How Microsoft Lost the API War

Rick Chapman is In Search of Stupidity
Friday, October 01, 2004

In every high tech company I’ve known, there’s a war going on, between the geeks and the suits. Read all about it in my foreword to Rick Chapman's excellent new book, In Search of Stupidity.

It's Not Just Usability


Monday, September 06, 2004

My goal today is not to whine about how usability is not important... usability is important at the margins, and there a lots of examples where bad usability kills people in small planes, creates famine and pestilence, etc.

My goal today is to talk about the next level of software design issues, after you've got the UI right: designing the social interface. It's Not Just Usability

Mike Gunderloy's Coder to Developer


Wednesday, May 05, 2004

This is my foreword to Mike Gunderloy's awesome new book, Coder to Developer.

Getting Your Résumé Read
Monday, January 26, 2004

Please do not use cover letters that you copied out of a book. If you write "I understand the position also requires a candidate who is team- and detail-oriented, works well under pressure, and is able to deal with people in departments throughout the firm" then at best people will think you're a bullshit artist and at worst they will think that you were not born with the part of the brain that allows you to form your own thoughts and ideas. Getting Your Résumé Read

Biculturalism
Sunday, December 14, 2003

A review of Eric S. Raymond's The Art of UNIX Programming

Craftsmanship
Monday, December 01, 2003

Writing code is not production, it's not always craftsmanship (though it can be), it's design. Design is that nebulous area where you can add value faster than you add cost. The New York Times magazine has been raving about the iPod and how Apple is one of the few companies that knows how to use good design to add value. But I've talked enough about design, I want to talk about craftsmanship for a minute: what it is and how you recognize it.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Wednesday, October 08, 2003

When I discovered that the popular web development tool PHP has almost complete ignorance of character encoding issues, blithely using 8 bits for characters, making it darn near impossible to develop good international web applications, I thought, enough is enough.

So I have an announcement to make: if you are a programmer working in 2003 and you don't know the basics of characters, character sets, encodings, and Unicode, and I catch you, I'm going to punish you by making you peel onions for 6 months in a submarine. I swear I will.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Bionic Office
Wednesday, September 24, 2003

We have, finally, moved, into the new Fog Creek office at 535 8th Avenue, officially ten months after I started pounding the pavement looking for a replacement for my grandmother's old brownstone where we spent our first few years, working from bedrooms and the garden.

Building Communities with Software 


Monday, March 03, 2003

It's no surprise that so many programmers, desperate for a little human contact, flock to online communities - chat rooms, discussion forums, open source projects, and Ultima Online. In creating community software, we are, to some extent, trying treate a third place.

Mouth Wide Shut

 

 


Wednesday, January 15, 2003

Should you talk endlessly about your products under development, in hopes of building buzz, or should you hold off until you've got something ready to go?

Lord Palmerston on Programming
Wednesday, December 11, 2002

Lord Palmerston: "The Schleswig-Holstein question is so complicated, only three men in Europe have ever understood it. One was Prince Albert, who is dead. The second was a German professor who became mad. I am the third and I have forgotten all about it." Programming has gotten too hard.

The Law of Leaky Abstractions
Monday, November 11, 2002

You can't drive as fast when it's raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it's raining (they abstract away the weather), but lo, you have to worry about hydraplaning (or aquaplaning in England) and sometimes the rain is so strong you can't see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the Law of Leaky Abstractions.

Incentive Pay Considered Harmful
Thursday, September 05, 2002

The idea was that you would get a big lucite tombstone the size of a dictionary when your product shipped. This was somehow supposed to give you an incentive to work, you see, because if you didn't do your job-- no lucite for you! Incentive Pay Considered Harmful

Platforms
Friday, August 30, 2002

If you want a platform to be successful, you need massive adoption, and that means you need developers to develop for it. The best way to kill a platform is to make it hard for developers to build on it. Most of the time, this happens because platform companies either don't know that they have a platform (they think it's an application) or they get greedy (they want all the revenue for themselves.)

Strategy Letter V
Wednesday, June 12, 2002

In thinking about the microeconomic principle of complements, I noticed something interesting about open source software, which is this: most of the companies spending big money to develop open source software are doing it because it's a good business strategy for them, not because they suddenly stopped believing in capitalism and fell in love with freedom-as-in-speech. Strategy Letter V

Five Worlds
Monday, May 06, 2002

You're a software developer. Me too. But we may not have the same goals and requirements. In fact there are several different worlds of software development, and different rules apply to different worlds.

Our .NET Strategy
Thursday, April 11, 2002

Fog Creek Software's April 2002 plan for future migration to .NET

Nothing is as Simple as it Seems
Monday, March 04, 2002

The combination of nothing-is-as-simple-as-it-seems and reduce-risk can only lead you to one conclusion:

You have to design things before you implement them.

The Iceberg Secret, Revealed
Wednesday, February 13, 2002

"I don't know what's wrong with my development team," the CEO thinks to himself. "Things were going so well when we started this project. For the first couple of weeks, the team cranked like crazy and got a great prototype working. But since then, things seem to have slowed to a crawl. They're just not working hard any more." He chooses a Callaway Titanium Driver and sends the caddy to fetch an ice-cold lemonade. "Maybe if I fire a couple of laggards that'll light a fire under them!"

Rub a dub dub
Wednesday, January 23, 2002

One reason people are tempted to rewrite their entire code base from scratch is that the original code base wasn't designed for what it's doing. It was designed as a prototype, an experiment, a learning exercise, a way to go from zero to IPO in nine months, or a one-off demo. And now it has grown into a big mess that's fragile and impossible to add code to, and everybody's whiny, and the old programmers quit in despair and the new ones that are brought in can't make head or tail of the code so they somehow convince management to give up and start over while Microsoft takes over their business. Today let me tell you a story about what they could have done instead.

Fire And Motion
Sunday, January 06, 2002

Many of my days go like this: (1) get into work (2) check email, read the web, etc. (3) decide that I might as well have lunch before getting to work (4) get back from lunch (5) check email, read the web, etc. (6) finally decide that I've got to get started (7) check email, read the web, etc. (8) decide again that I really have to get started (9) launch the damn editor and (10) write code nonstop until I don't realize that it's already 7:30 pm.

Somewhere between step 8 and step 9 there seems to be a bug, because I can't always make it across that chasm.

Getting Things Done When You're Only a Grunt
Tuesday, December 25, 2001

This site is supposed to be about software management. But sometimes you don't have the power to create change in your organization by executive fiat. Obviously, if you're just a grunt programmer at the bottom of the totem pole, you can't exactly order people to start creating schedules or bug databases. And in fact even if you're a manager, you've probably discovered that managing developers is a lot like herding cats, only not as fun. Merely saying "make it so" doesn't make it so.

Back to Basics
Tuesday, December 11, 2001

Thinking about boring first-year computer-science stuff like how strcat and malloc actually work has given you new tools to think about the latest, top level, strategic and architectural decisions that you make in dealing with technologies like XML. Back to Basics

Working on CityDesk, Part Five
Tuesday, November 13, 2001

Working on CityDesk, Part Five

Working on CityDesk, Part Four
Monday, October 29, 2001

Working on CityDesk, Part Four

Working on CityDesk, Part Three
Wednesday, October 17, 2001

Working on CityDesk, Part Three

Working on CityDesk, Part Two
Saturday, October 13, 2001

Working on CityDesk, Part Two

Working on CityDesk, Part One
Friday, October 12, 2001

Working on CityDesk, Part One

Hard-assed Bug Fixin'
Tuesday, July 31, 2001

As a software developer, fixing bugs is a good thing. Right? Isn't it always a good thing? No! Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it. Hard-assed Bug Fixin'

Good Software Takes Ten Years. Get Used To It.
Saturday, July 21, 2001

The trouble comes when you can't think of any new features, so you put in the paperclip, and then you take out the paperclip, and you try to charge people both times, and they aren't falling for it. Good Software Takes Ten Years. Get Used To It.

What is the Work of Dogs in this Country?
Saturday, May 05, 2001

Eating your own dog food is the quaint name that we in the computer industry give to the process of actually using your own product. I had forgotten how well it worked, until a month ago, I took home a build of CityDesk (thinking it was about 3 weeks from shipping) and tried to build a site with it.

Don't Let Architecture Astronauts Scare You
Saturday, April 21, 2001

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all. Don't Let Architecture Astronauts Scare You.

Strategy Letter IV: Bloatware and the 80/20 Myth
Friday, March 23, 2001

There are lots of great reasons for bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make your life better (when you use them) and don't usually hurt (when you don't). Bloatware and the 80/20 Myth

Spring in Cambridge
Monday, March 19, 2001

One thing that arsDigita did very, very, right was the personal voice thing. The biggest thing I think about with Fog Creek is how to maintain that personal voice, and if we can do it, I'll owe a big, big debt to Philip Greenspun.

Human Task Switches Considered Harmful
Monday, February 12, 2001

A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. Human Task Switches Considered Harmful

Human Task Switches Considered Harmful
Monday, February 12, 2001

A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. Human Task Switches Considered Harmful

Daily Builds Are Your Friend
Saturday, January 27, 2001

A daily build is an automatic, daily, complete build of the entire source tree. Daily Builds Are Your Friend. 

Big Macs vs. The Naked Chef
Thursday, January 18, 2001

Let's compare a McDonald's cook, who is following a set of rules exactly and doesn't know anything about food, to a genius like The Naked Chef, the British cutie Jamie Oliver. (If you chose to leave this site now and go watch the MTV-like videos of The Naked Chef making basil aioli, you have my blessing. Go in good health.) Big Macs vs. The Naked Chef.

Up the tata without a tutu
Saturday, December 02, 2000

When I sit down to architect a system, I have to decide which tools to use. And a good architect only uses tools that can either be trusted, or that can be fixed. Otherwise you will be Up the Tata Without a Tutu.

Painless Bug Tracking
Wednesday, November 08, 2000

If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are simply going to ship low quality code. Painless Bug Tracking

Another Business Model That Doesn't Seem to Work
Wednesday, October 25, 2000

Atomz.com is hoping to achieve what I call "stealth lock-in." They don't even want to you realize that you're becoming dependent on a service. In the future, when you're hooked, they can start charging you a bundle, and you'll pay them just to avoid the cost of switching.

Painless Functional Specifications
Monday, October 02, 2000

Part 1: Why Bother?
Part 2: What's a Spec?
Part 3: But... How?
Part 4: Tips

Fog Creek Compensation
Wednesday, August 30, 2000

Fog Creek Software's Final Compensation Policy

UI For Programmers Summary
Wednesday, August 09, 2000

The Joel Test: 12 Steps to Better Code
Wednesday, August 09, 2000

Have you ever heard of SEMA? It's a fairly esoteric system for measuring how good a software team is. It will take you about six years just to understand that stuff. So I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to medical school.

Microsoft Goes Bonkers
Saturday, July 22, 2000

Microsoft Goes Bonkers, a critique of premature hoopla surrounding .NET.

Whaddaya Mean, You Can't Find Programmers?
Thursday, June 15, 2000

There are hundreds of thousands of programmers out there, and you can hire them, if you know how. This article is about the "programmer's perspective" on how to find people and convince them to work for you.

Strategy Letter III: Let Me Go Back!
Saturday, June 03, 2000

The best way to eliminate people's objections to switching to your product is to make it easy to switch back. Nobody wants to switch to a product that is going to eliminate their freedom in the future.

Strategy Letter I: Ben and Jerry's vs. Amazon
Friday, May 12, 2000

Building a company? You've got one very important decision to make, because it affects everything else you do. No matter what else you do, you absolutely must figure out which camp you're in, and gear everything you do accordingly, or you're going to have a disaster on your hands.

Top Five (Wrong) Reasons You Don't Have Testers
Sunday, April 30, 2000

You would think that after all the Quality mania of the 80s, with all kinds of meaningless international "quality" certifications like ISO-9000 and buzzwords like "six-sigma", managers today would understand that having high quality products makes good business sense. In fact, they do. Most have managed to get this through their heads. But they still come up with lots of reasons not to have software testers, all of which are wrong.

Where do These People Get Their (Unoriginal) Ideas?
Wednesday, April 19, 2000

Knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done.

Things You Should Never Do, Part I
Thursday, April 06, 2000

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong.

Painless Software Schedules
Wednesday, March 29, 2000

Why doesn't anybody make a schedule? One, it's a real pain. Two, nobody believes that it's worth anything. Why go to all the trouble working on a schedule if it's not going to be right? Here's a simple, painless way to make schedules that are actually correct.

NDAs and Contracts That You Should Never Sign
Tuesday, March 28, 2000

NDAs and Contracts That You Should Never Sign

Strategy Letter II: Chicken and Egg Problems
Friday, March 24, 2000

If you're in the platform creation business, you are probably going to suffer from what is commonly known as the chicken and egg problem. Nobody is going to buy your platform until there's good software that runs on it, and nobody is going to write software until you have a big installed base. Ooops.

Command and Conquer and the Herd of Coconuts
Thursday, March 23, 2000

Nobody at Juno owned anything, they just worked on it, and different layers of management happily stuck their finger into every pie, giving orders left and right in a style which I started calling hit and run management because managers tended to pop up unannounced, give some silly order for exactly how they wanted something done, dammit, without giving any thought to the matter, and leave the room for everyone else to pick up the pieces. Command and Conquer and the Herd of Coconuts

The Guerrilla Guide to Interviewing
Thursday, March 23, 2000

An important thing to remember about interviewing is this: it is much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. If you have any doubts whatsoever, No Hire. The Guerrilla Guide to Interviewing

Converting Capital Into Software That Works
Tuesday, March 21, 2000

Imagine that the goal of your software company is not to solve some specific problem, but to be able to convert money to code through programmers.

Two Stories
Sunday, March 19, 2000

At Microsoft, if you're the Program Manager working on the Excel macro strategy, even if you've been at the company for less than six months, it doesn't matter - you are the GOD of the Excel macro strategy, and nobody, not even employee number 6, is allowed to get in your way. Period.

More on Sabbaticals...
Saturday, March 18, 2000

I took a self-funded sabbatical in 1995, and another in 2000. I think they're great.



Joel Spolsky is the founder of Fog Creek Software, a small software company in New York City. He graduated from Yale University, and has worked as a programmer and manager at Microsoft, Viacom, and Juno.


The contents of this page represent the opinions of one person.
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky