Debugged code is not free, whether proprietary or open source. Even if you don’t pay cash dollars for it, it has oportunity cost, and it has time cost.
On bugs
Do you fix bugs before writing new code?
In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
A programmer should never, ever work on new code if they could instead be fixing bugs.
Fixing bugs is only important when the value of having the bug fixed exceeds the cost of fixing it.
The other thing we do is consider each and every tech support call to be evidence of a bug. When we take the call, we try to figure out what we could have done to eliminate it.
Get crash reports from users - automatically!
Schedule
A schedule forces you to decide what features you are going to do, and then it forces you to pick the least important features and cut them rathen than slipping into featuritis (aka scope creep).
The process of culling features to fit a schedule was the best thing we could have done.
(…) you have to make a schedule.
Your tasks should be measured in hours, not days.
Keep track of the original and current estimate.
Put debugging time into the schedule.
Do you have an up-to-date schedule?
Specs
You have to design things before you implement them.
Three minutes of design work saved me hours of coding.
Failing to write a spec is the single biggest unnecessary risk you take in a software project.
When you design your product in human language, it takes only a few minutes to try thinking about several possibilities, revising, and improving your design. Nobody feels bad just deleting a paragraph in a word processor. But when you design your product in a programming language it takes weeks to do iterative design.
(…) without a detailed spec, it’s impossible to make a schedule. (…) for almost any kind of real business, you just have to have to know how long thing are going to take, because developing a product costs money.
Humans don’t want to have to decode something, they just want to read it in order and understand it. For humans, you have to provide the big picture and then fill in the details.
When you design a product, inside and out, the most important thing is to nail down the user experience. What are the screens, how do they work, what do they do. Later, you worry about how to get from here to there.
A paper prototype is simple: it’s just a piece of paper where you’ve drawn - in pencil - a mock-up of the user interface.
On hiring
When I look at resumes, I look for things that indicate selectivity; in other words, I look for evidence that the person has gone through some particularly difficult selection process in the past and passed.
It’s much better to reject a good candidate than to accept a bad candidate.
You are looking for people who are:
1. smart
2. get things done
A good way to interview candidates for testing jobs is to give them a simple operation and ask them to enumerate all the things that can possibly go wrong.
But in general, the way to learn the most about a person is to let them do the talking. Give them open-ended questions and problems.
As a rule of thumb, you can make a nice place to work, or you can promise people they’ll get rich quick. But you have to do one of those, or you won’t be able to hire.
Managing developers
Number-one required skill in a program manager is learning to make software developers do what you want by making them think it was their own idea.
(…) the power and rewards accrue to those rare individuals who know how to translate between Programmerese and MBAese.
You should let people work on more than one thing at once.
On business
If it’s a core business function - do it yourself, no matter what.
If you have customers, never outsource customer service.
Customers don’t know what they want. Stop expecting customers to know what they want.
Listen to your customers, not your competitors.
Smart companies try to commoditize their product’s complements. If you can do this, demand for your product will increase and you will be able to charge more and make more.
There’s nothing wrong with being in a market that has established competition. (…) The only strategy in getting people to switch to your product is to eliminate barriers.
Microsoft was the only company on the list that never made a fatal, stupid mistake.
On complexity
Excel’s Team Motto: “Find the dependencies - and eliminate them”.
Humans can only deal with so much complexity, and nobody has time to manage the permissions for all their apps on a fine-grained basis.
Software, by its nature, is very easy to divide into smaller and smaller components, so it’s always possible to divide responsibility among people and let people own an area.
It’s important to remember that if you start from scratch, there is absolutely no reason to believe that you will do a better job than you did the first time.
On product development
(…) stop when the software is “good enough”.
A lot of software developers are seduced by the old “80/20” rule. It seems to make a lot of sense: 80 percent of the people use 20 percent of the features. So you convice yourself that you only need to implement 20 percent of the features, and you can still sell 80 percent as many copies. Unfortunately, it’s never the same 20 percent. Everybody uses a different set of features.
Fire and Motion, for small companies like mine, means two things. You have to have time on your side, and you have to move forward every day. Sooner or later you will win.
Feedback
Our three best sources for feedback:
- the “Send Feedback” menu item in CityDesk. Goes right into our bug tracking database, and generates so much (excellent) feedback that we simply can’t reply to any of it; we’re lucky if we have time to tally votes for feature requests.
- a general policy that there should be an email link at the bottom of every page on our website.
- online discussion forums
Spolsky, J. (2004). Joel on software: and on diverse and occasionally related matters that will prove of interest to software developers, designers, and managers, and to those who, whether by good fortune or ill luck, work with them in some capacity. Berkeley, CA: Apress.