painless software management:
Ah yes, you have arrived at the very strange world of Joel on Software. I’m Joel Spolsky. Almost everything you see here is written by me, and it reflects my (shall-we-say) unique sensibilities about software development.
So here it is – Joel’s Programmer’s Bookshelf. This is the short list of all the books that I honestly think that every working programmer needs to read, with my own book hidden in there in case you didn’t notice because I get about two bucks if you buy it.
Have you ever heard of SEMA? It’s a fairly esoteric system for measuring how good a software team is. No, wait! Don’t follow that link! 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.
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:
- Set a ship date, which might as well be arbitrary
- Make a list of features and sort them out by priority
- Cut low-priority features every time you slip so as to make the date.
Why won’t people write specs? People claim that it’s because they’re saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to ‘wing it.’
Treating your rocket scientist employees as if they were still in kindergarten is not an isolated phenomenon. Almost every company has some kind of incentive program that is insulting and demeaning.
First of all, the #1 cardinal criteria for getting hired…:
Smart, and Gets Things Done.
That’s it. That’s all we’re looking for. Memorize that. Recite it to yourself before you go to bed every night. Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it’s better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute.
Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date.
In this comprehensive anthology Peter Naur, one of the world’s foremost computer scientists, presents his selected writings from 1951 to 1990. The book features Naur’s original and stimulating reflections on the nature of computing, with perceptive analyses of many issues that remain controversial. Comprising the author’s published and unpublished writings on scientific, technical, philosophical, and social aspects of computing, the volume highlights his view of computing as, essentially, a human activity.
Some views on programming, taken in a wide sense and regarded as a human activity, are presented. Accepting that programs will not only have to be designed and produced, but also modified so as to cater for changing demands, it is concluded that the proper, primary aim of programming is, not to produce programs, but to have the programmers build theories of the manner in which the problems at hand are solved by program execution.
This chapter may be noted for its early skepticism with regard to phase controlled system development and its advocation of the experimental approach, later known as prototyping.
A characterization of the pervasiveness of intuition in human conscious life is given, followed by some remarks on successes and failures of intuition. Next the intuitive basis of common notions of scales, logic, correctness, texts, reasoning, and proofs, is described. On this basis the essential notions of data models of human activity and of software development, as built on human intuition, are discussed. This leads to a discussion of software development methods, viewed as means to overcoming the hazards of intuitive actions. It is concluded that programmers’ experience and integrity are more important than their use of methods.
Strictly defined notation is familiar to anybody from its occurrence in games. More importantly, strictly defined notation is a building element of constructed models, employed widely in science and technology. Constructed models give rise to major issues related to their use and construction, essentially involving informal issues… The one-sided attention given to purely formal issues in much literature on programming logic is characterized.
|[Last generated: 2016-10-11]|