David J. Agans:
Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.
American Management Association,
2002,
0814471684.
Its first sentence says, "This book tells you how to find out
what's wrong with stuff, quick," and that's exactly what it does.
In fifteen (very) short chapters, the author presents nine simple
rules to help you track down and fix problems in software,
hardware, or anything else. His war stories are entertaining
(although I think one or two are urban myths), and his advice is
eminently practical.
Mike Andrews and James A. Whittaker:
How to Break Web Software.
Addison-Wesley,
2006,
0321369440.
This practical companion to [Whittaker 2003]
catalogs things you can do to break web-based applications.
Ant:
http://ant.apache.org,
viewed 2006-02-20.
A Java-oriented build tool that uses XML files instead of
Makefiles.
Apache Web Server:
http://httpd.apache.org,
viewed 2005-07-26.
The main site for the most widely-used web server in the world.
Jorge Aranda and Steve Easterbrook and Greg Wilson:
"Requirements in the wild: How small companies do it".
Proceedings of Requirements Engineering '07,
2007.
FIXME
V. R. Basili and B. T. Perricone:
"Software Errors and Complexity: An Empirical Investigation".
Communications of the ACM
27(1),
1984.
FIXME
V. R. Basili and L. C. Briand and W. L. Melo:
"How Reuse Influences Productivity of Object-Oriented Systems".
Communications of the ACM,
39(10),
1996.
FIXME
Kent Beck and Ward Cunningham:
"A Laboratory for Teaching Object-Oriented Thinking".
SIGPLAN Notices,
24(10),
1989.
A C++ library that enables interoperability with Python.
Stewart Brand:
How Buildings Learn: What Happens After They're Built.
Penguin USA,
1995,
0140139966.
This beautiful, thought-provoking book starts with the observation
that most architects spend their time re-working or extending
existing buildings, rather than creating new ones from scratch. Of
course, if Brand had written "program" instead of "building",
and "programmer" where he'd written "architect", everything he
said would have been true of computing as well. A lot of software
engineering books try to convey the same message about allowing
for change, but few do it so successfully. By presenting examples
ranging from the MIT Media Lab to a one-room extension to a house,
Brand encourages us to see patterns in the way buildings change
(or, to adopt Brand's metaphor, the way buildings learn from their
environment and from use). Concurrently, he uses those insights to
argue that since buildings are always going to be modified, they
should be designed to accommodate unanticipated change.
Frederick P. Brooks:
The Mythical Man Month: Essays on Software Engineering.
Addison-Wesley,
1995,
0201835959.
The classic text in software engineering, most famous for its
discussion of how adding people to a project that's late will only
make it later.
An industrial-strength issue tracking system that is widely used
in open source projects.
Elizabeth Castro:
HTML for the World Wide Web: With XHTML and CSS.
Peachpit Press,
2000,
0321130073.
A clean, clear, comprehensive guide to creating HTML for the web,
with good coverage of Cascading Style Sheets (CSS).
Elizabeth Castro:
XML for the World Wide Web.
Peachpit Press,
2000,
0201710986.
Like other books in Peachpit's Visual Quickstart series, this one
is beautifully designed, and easy to read without ever being
condescending. Its 16 chapters and 4 appendices are organized into
1- and 2-page explanations of particular topics, from writing
non-empty elements to namespaces, schemas, and XML
transformation. Throughout, Castro strikes a perfect balance
between "what", "why", and "how", and provides a surprising
amount of detail without ever overwhelming the reader.
W.G. Chase and H.A. Simon:
"Perception in chess".
Cognitive Psychology,
4,
1973.
The original paper comparing the performance of novice and master
chess players when confronted with actual and random positions.
S. R. Chidamber and C. F. Kemerer:
"A Metrics Suite for Object Oriented Design".
IEEE Transactions on Software Engineering,
20(6),
1994.
Introduced a widely-cited suite of object-oriented software metrics.
Jason Cohen:
Best Kept Secrets of Code Review.
Smart Bear Software,
2006,
1599160676.
A framework for managing continuous builds. Each time you update
something in your version control repository, CruiseControl
recompiles your code, re-runs your tests, and lets you (and your
teammates) know if you've broken anything.
B. Curtis and H. Krasner and N. Iscoe:
"A Field Study of the Software Design Process for Large Systems".
Communications of the ACM,
31(11),
1988.
FIXME
CVS:
http://www.cvshome.org,
viewed 2006-02-17.
A version control system that has been the backbone of the open
source movement almost since its inception. [Subversion]
is slowly replacing it.
Cygwin:
http://www.cygwin.com,
viewed 2005-07-26.
A Linux-like environment for Windows, which brings with it a lot
of other tools (like SSH and GNU Make).
A [Python] web application development framework with
some of the same capabilities as [Ruby on Rails] (but not
as many users, or as much documentation).
Matt Doar:
Practical Development Environments.
O'Reilly,
2005,
0596007965.
Matt Doar has produced a practical guide to what should be in
every team's toolbox, how competing entries stack up, and how they
ought to be used. This book covers everything from configuration
management tools like CVS and [Subversion], to build
tools (make, GNU's Autotools, Ant, Jam, and SCons), various
testing aids, bug tracking systems, documentation generators, and
we're still only at the halfway mark. He names names, provides
links, and treats free and commercial offerings on equal terms.
My copy currently has 28 folded-down corners, which is 28 more
than most books get.
Originally developed by IBM for Java development, Eclipse is the
biggest open source development environment around these
days. There are literally hundreds of plugins for it, and hundreds
of thousands of users. It's not for the faint of heart (and it
definitely won't be happy on a four-year-old hand-me-down
machine), but it's one of the real power tools of modern
programming.
Stephen G. Eick, Todd L. Graves, Alan F. Karr, J.S. Marron, and Audris Mockus:
"Does Code Decay? Assessing the Evidence from Change Management Data".
IEEE Transactions on Software Engineering
27(1),
2001.
Analyzes the evolution of several million lines of telephone
switching software over fifteen years to show that code quality,
comprehensibility, and maintainability decline over time.
An open source tool to connect Python and Fortran code.
Michael E. Fagan:
"Advances in Software Inspections".
IEEE Transactions on Software Engineering,
12(7),
1986.
Empirical data showing that code reviews are the most effective
way known to find bugs.
Chris Fehily:
Python: Visual QuickStart Guide.
Peachpit Press,
2006,
0321423135.
A gentle introduction to Python, beautifully typeset, with lots of
helpful examples.
Chris Fehily:
SQL: Visual QuickStart Guide.
Peachpit Press,
2003,
0321118030.
This very readable book describes the subset of SQL that covers
most real-world needs. While the book moves a little slowly in
some places, the examples are exceptionally clear.
Stuart I. Feldman:
"Make---A Program for Maintaining Computer Programs".
Software: Practice and Experience,
9(4),
1979.
The original description of Make. Last time I checked, Stu
Feldman was a vice president at IBM, which shows you just how far
a good tool can take you...
Michael C. Feathers:
Working Effectively with Legacy Code.
Prentice-Hall PTR,
2005,
0131177052.
Most programmers spend most of their time fixing bugs, porting to
new platforms, adding new features---in short, changing existing
code. If that code is exercised by unit tests, then changes can
be made quickly and safely; if it isn't, they can't, so your first
job when you inherit legacy code should be to write some. That's
where this book comes in. What to know three different ways to
inject a test into a C++ class without changing the code? They're
here. Want to know which classes or methods to focus testing on?
Read his discussion of pinch points. Need to break inter-class
dependencies in Java so that you can test one module without
having to configure the entire application? That's in here too,
along with dozens of other useful bits of information. Everything
is illustrated with small examples, all of them clearly explained
and to the point. There are lots of simple diagrams, and a short
glossary; all that's missing is hype.
The best web browser around, where "best" means "nicest
interface", "most extensible", and "least insecure".
Karl Fogel:
Producing Open Source Software.
O'Reilly,
2005,
0596007590.
A community is more than just a bunch of people. It's a shared
set of values, and rules for how to behave. By this standard, the
open source community isn't just what some programmers choose to
do with their time, and why; it's also how they do it.
This book is an excellent guide to that "how". Every page
offers practical advice; every point is made clearly and
concisely, and clearly draws upon the author's extensive personal
experience. Want to know how to earn commit privileges on a
project? It's here. Do you and other project members have
irreconcilable differences? Fogel explains when and how to fork,
and what the pros and cons are. Want to get your project more
attention? Want to take something closed, and open it up? It's
all here, and much more.
Martin Fowler:
Refactoring: Improving the Design of Existing Code.
Addison-Wesley Professional,
1999,
0201485672.
Like architects, most programmers spend most of their time
renovating, rather than creating something completely new on a
blank sheet of paper. This book presents and analyzes patterns
that come up again and again when programs are being
reorganized. Some of these are well-known, such as placing common
code in a utility method. Others, such as replacing temporary
objects with queries, or replacing constructors with factory
methods, are subtler, but no less important. Each entry includes a
section on motivation, the mechanics of actually carrying out the
transformation, and an example in Java.
Jeffrey E. F. Friedl:
Mastering Regular Expressions.
O'Reilly,
2002,
0596002890.
The definitive programmer's guide to regular expressions.
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides:
Design Patterns.
Addison-Wesley,
1995,
0201633612.
The book that started the software design patterns movement. Much
of the discussion has been superseded by more recent books, and
the use of C++ and Smalltalk for examples feels a little dated,
but it is still a landmark in programming.
The GNU Project debugger is a program that watches and manipulates
other programs. It works with many languages, on many platforms;
when combined with DDD, it's actually not that hard to use.
Robert L. Glass:
Building Quality Software.
Prentice-Hall,
1992.
FIXME
Robert L. Glass:
"The Realities of Software Technology Payoffs".
Communications of the ACM,
42(2),
1999.
FIXME
Robert L. Glass:
Facts and Fallacies of Software Engineering.
Addison-Wesley Professional,
2002,
0321117425.
I really wish someone had given me something like this book when I
took my first programming job. If nothing else, it would have been
a better way to start thinking about the profession I had stumbled
into than the "everybody knows" factoids that I soaked up at
coffee time. Some of what he says is well-known: good programmers
are up to N times better than bad ones (his value for N is 28),
reusable components are three times harder to build than
non-reusable ones, and so on. Other facts aren't part of the
zeitgeist, though they should be. For example, most of us know
that maintenance consumes 40-80% of software costs, but did you
know that roughly 60% of that is enhancements, rather than bug
fixes? Or that if more than 20-25% of a component has to be
modified, it is more efficient to re-write it from scratch? Best
of all, Glass backs up every statement he makes with copious
references to the primary literature; if you still disagree with
him, you'd better be sure you have as much evidence for your point
of view as he has for his.
John Goerzen:
Foundations of Python Network Programming.
APress,
2004,
1590593715.
This book looks at how to handle several common protocols,
including HTTP, SMTP, and FTP. Goerzen also doesn't delve as
deeply into their internals, but instead on how to build clients
that use them. His approach is to build solutions to complex
problems one step at a time, explaining each addition or
modification along the way. He occasionally assumes more
background knowledge than most readers of this book are likely to
have, but only occasionally, and makes up for it by providing both
clear code, and clear explanations of why this particular function
has to do things in a particular order, or why that one really
ought to be multithreaded.
Nathan A. Good:
Regular Expression Recipes.
APress,
2005,
159059441X.
A great how-to for regular expressions, with examples in many
different languages.
Mike Gunderloy:
Coder to Developer: Tools and Strategies for Delivering Your Software.
Sybex,
2004,
078214327X.
This practical, readable book is subtitled "Tools and Strategies
for Delivering Your Software", and that's exactly what it's
about. Project planning, source code control, unit testing,
logging, and build management are all there. Importantly, so are
newer topics, like building plugins for your IDE, code generation,
and things you can do to protect your intellectual
property. Everything is clearly explained, and illustrated with
well-chosen examples. While the focus is definitely on .NET,
Gunderloy covers a wide range of other technologies, both
proprietary and open source. I'm already using two new tools based
on references from this book, and plan to make the chapter on
"Working with Small Teams" required reading for my students.
R. G. Hamlet and R. Taylor:
"Partition Testing Does Not Inspire Confidence".
IEEE Transactions on Software Engineering,
16(12),
1990.
FIXME
Nick Hammond: "Software Carpentry --- A Tool-Based Approach to Monte Carlo Radiation Transport".
Proc. 8th Int'l Conference on Radiation Shielding,
1994.
This book explains which of XML's many features should be used
when: Item 12 tells you to store metadata in attributes, and then
spends six pages explaining why, while Item 24 analyzes the
strengths and weaknesses of various schema languages, and Item 38
covers character set encodings. It's more than most developers
will ever want to know, but when you need it, you really need it.
J. D. Herbsleb and R. E. Grinter:
"Splitting the Organization and Integrating of Code: Conway's Law Revisited".
Proc. ICSE'99,
1999.
FIXME
Roger R. Hock:
Forty Studies that Changed Psychology.
Prentice Hall,
2004,
0131147293.
In forty short chapters, Hock describes the turning points in our
understanding of how our minds work. The book isn't just about
psychology; you'll also learn a lot about how science gets done,
and about the scientists who do it.
H. F. Hofmann and F. Lehner:
"Requirements Engineering as a Sucess Factor in Software Projects".
IEEE Software,
18(4),
2001.
FIXME
Watts S. Humphrey:
Introduction to the Personal Software Process.
Addison-Wesley,
1996,
0201548097.
A methodology for improving programmers' productivity by having
them record and track just about everything they do. The idea has
a lot of merit, but in practice, the cost of record keeping can
outweigh the benefits.
Andrew Hunt and David Thomas:
The Pragmatic Programmer: From Journeyman to Master.
Addison-Wesley,
1999,
020161622X.
This book is about those things that make up the difference
between typing in code that compiles, and writing software that
reliably does what it's supposed to. Topics range from gathering
requirements through design, to the mechanics of coding, testing,
and delivering a finished product. The second section, for
example, covers "The Evils of Duplication", "Orthogonality",
"Reversibility", "Tracer Bullets", "Prototypes and Post-It
Notes", and "Domain Languages", and illuminates each with
plenty of examples and short exercises.
Jeff Johnson:
GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers.
Morgan Kaufmann,
2000,
1558605827.
Most books on GUI design are long on well-meaning aesthetic
principles, but short on examples of what it means to put those
principles into practice. In contrast, GUI Bloopers presents case
study after case study: what's wrong with this dialog? What should
its creators have done instead. And, most importantly, why? The
net effect is to teach all of the same principles that other books
try to, but in a grounded, understandable way.
JUnit:
http://www.junit.org/,
viewed 2006-02-22.
A unit testing framework for Java that has inspired many
workalikes and extensions.
Brian W. Kernighan and Rob Pike:
The Unix Programming Environment.
Prentice Hall,
1984,
013937681X.
I have long believed that this book is the real secret to Unix's
success. It doesn't just show readers how to use Unix---it
explains why the operating system is built that way, and
how its "lots of little tools" philosophy keeps simple tasks
simple, while making hard ones doable.
Brian W. Kernighan and Dennis Ritchie:
The C Programming Language.
Prentice Hall PTR,
1998,
0131103628.
The classic description of the one programming language every
serious programmer absolutely, positively has to learn.
Kid:
http://kid.lesscode.org,
viewed 2006-03-06.
An HTML templating system for Python.
Hans P. Langtangen:
Python Scripting for Computational Science.
Springer-Verlag,
2004,
3540435085.
The book's aim is to show scientists and engineers with little
formal training in programming how Python can make their lives
better. Regular expressions, numerical arrays, persistence, the
basics of GUI and web programming, interfacing to C, C++, and
Fortran: it's all here, along with hundreds of short example
programs. Some readers may be intimidated by the book's weight,
and the dense page layout, but what really made me blink was that
I didn't find a single typo or error. It's a great achievement,
and a great resource for anyone doing scientific programming.
Mark Lutz and David Ascher:
Learning Python.
O'Reilly,
2003,
0596002815.
This is not only the best introduction to Python on the market, it
is one of the best introductions to any programming language that
I have ever read. Lutz and Ascher cover the entire core of the
language, and enough of its advanced features and libraries to
give readers a feeling for just how powerful Python is. In keeping
with the spirit of the language itself, their writing is clear,
their explanations lucid, and their examples well chosen.
The standard build tool for Unix. Users describe
dependencies in a
Makefile, along with the actions that must
be executed to update a file if it is older than any of its
dependencies. Make then determines which actions need to be
executed, and an order in which they may safely be run.
Jane Margolis and Allan Fisher:
Unlocking the Clubhouse: Women in Computing.
MIT Press,
2002,
0262133989.
This book describes a project at Carnegie-Mellon University that
tried to figure out why so few women become programmers, and what
can be done to correct the imbalance. Its first six chapters
describe the many small ways in which we are all, male and female,
are conditioned to believe that computers are "boy's things".
Sometimes it's as simple as putting the computer in the boy's
room, because "he's the one who uses it most". Later on, the
"who needs a social life?" atmosphere of undergraduate computer
labs drives many women away (and many men, too). The last two
chapters describe what the authors have done to remedy the
situation at high schools and university. This work proves that
by being conscious of the many things that turn women off
computing, and by viewing computer science from different angles,
we can attract a broader cross-section of society, which can only
make our discipline a better place to be. The results are
impressive: female undergraduate enrolment at CMU rose by more
than a factor of four during their work, while the proportion of
women dropping out decreased significantly.
Alex Martelli, Anna Ravenscroft, and David Ascher (eds.):
Python Cookbook.
O'Reilly,
2005,
0596007973.
A useful reference for every serious Python programmer, this book
is a collection of tips and tricks, some very simple, others so
complex that they require careful line-by-line reading. The book's
companion web site [Python Cookbook] is updated regularly.
Thomas J. McCabe:
"A Complexity Measure".
IEEE Transactions on Software Engineering,
2(4),
1976.
First description of cyclomatic complexity.
Steve McConnell:
Code Complete.
Microsoft Press,
2004,
0735619670.
This classic is a handbook of do's and don'ts for working
programmers. It covers everything from how to avoid common
mistakes in C to how to set up a testing framework, how to
organize multi-platform builds, and how to coordinate the members
of a team. In short, it is everything I wished someone had told
me before I started my first full-time programming job.
Microsoft Visual Studio:
http://msdn.microsoft.com/vstudio/,
viewed 2006-02-20.
A full-featured IDE for Microsoft Windows development.
G. J. Myers:
"A Controlled Experiment in Program Testing and Code Walkthroughs/Inspections".
Communications of the ACM,
21(9),
1978.
FIXME
MySQL:
http://www.mysql.com,
viewed 2005-07-29.
The most popular open source database around (though many
discerning users prefer [PostgreSQL]).
Donald A. Norman:
Things That Make Us Smart.
Perseus,
1993,
978-0201626957.
FIXME
Oracle:
http://www.oracle.com,
viewed 2006-02-24.
A high-end commercial database system produced by a company of the
same name.
George Orwell:
"Politics and the English Language".
http://www.george-orwell.org/Politics_and_the_English_Language/0.html,
viewed 2006-04-28.
A brilliant description of how turgid language is often used as a
substitute for thought. The particular examples may be a little
dated, but Orwell's writing never is.
The main site for an advanced open source relational database. It
may not be as popular as its main competitor, MySQL, but most
people who have used both have found PostgreSQL easier to work
with.
An incisive summary of the effect of fatigue on human
productivity, the conclusion of which is that crunch mode winds up
making projects later.
Lawrence Rosen:
Open Source Licensing: Software Freedom and Intellectual Property Law.
Prentice Hall PTR,
2005,
0131487876.
If you're involved in open source software in any way, shape, or
form, then this book is a useful read. Its author is intimately
familiar with the field; here, he lays out a general background
for discussion of intellectual property, and the history of
free/open source software, then discusses what various popular
licenses actually mean. The book closes with chapters on topics
such as how to choose a license, litigation, and standards. The
writing is clear---exceptionally so by legal standards---and he
takes time to explain terms and assumptions that most software
developers won't have encountered before. What's more, he doesn't
seem to have any particular axes to grind: the book is US-centric,
but his treatment of the various options open to today's
developers is very even-handed.
A scripting language with many of the same capabilities as
[Python].
Ruby on Rails:
http://www.rubyonrails.org,
viewed 2006-04-30.
A third-generation web application framework that simplifies
programmers' lives by emphasizing convention over configuration.
H. Sackman, W. I. Erikson, and E. E. Grant:
"Exploratory Experimental Studies Comparing Online and Offline Programming Performances".
Communications of the ACM,
11(1),
1968.
FIXME
Bruce Schneier: Beyond Fear.
Springer,
2003,
0387026207.
A thought-provoking look at how we are encouraged to think about
security, and how much security is actually desirable. For
example, he explains why security systems must not just work well,
but fail well, and why secrecy often undermines security instead
of enhancing it.
Bruce Schneier:
Secrets and Lies: Digital Security in a Networked World.
Wiley,
2005,
0471453803.
Having written the standard book on cryptography, Schneier now
argues that technology alone can't solve most real security
problems. The book covers systems and threats, the technologies
used to protect and intercept data, and strategies for proper
implementation of security systems. Rather than blind faith in
prevention, Schneier advocates swift detection and response to an
attack, while maintaining firewalls and other gateways to keep out
the amateurs.
A simple set of guidelines for code reviews from the Mozilla
Foundation.
Mary Shaw:
"Prospects for a Discipline of Software Engineering".
IEEE Software,
7(6),
1990.
FIXME
Ed Skoudis:
Malware: Fighting Malicious Code.
Prentice-Hall,
2004,
0131014056.
This 647-page tome is a survey of harmful software, from viruses
and worms through Trojan horses, root kits, and even malicious
microcode. Each threat is described and analyzed in detail, and
the author gives plenty of examples to show exactly how the attack
works, and how to block (or at least detect) it. The writing is
straightforward, and the case studies in Chapter 10 are funny
without being too cute.
A software project management portal whose main installation is a
clearing house for thousands of open source projects.
Diomidis Spinellis:
Code Quality: The Open Source Perspective.
Addison-Wesley,
2006,
0321166078.
A companion to the same author's earlier
[Spinellis 2003], this book concentrates on what
distinguishes good code from bad. The first one was great; this
one is even better.
Diomidis Spinellis:
Code Reading: The Open Source Perspective.
Addison-Wesley,
2003,
0201799405.
The book's preface says it best: "The reading of code is likely
to be one of the most common activities of a computing
professional, yet it is seldom taught as a subject or formally
used as a method for learning how to design and program."
Spinellis isn't the first person to make this point, but he is the
first person I know of to do something about it. In this book, he
walks through hundreds of examples of C, C++, Java, and Perl,
drawn from dozens of Open Source projects such as Apache, NetBSD,
and Cocoon. Each example illustrates a point about how programs
are actually built. How do people represent multi-dimensional
tables in C? How do people avoid nonreentrant code in signal
handlers? How do they create packages in Java? How can you
recognize that a data structure is a graph? A hashtable? That it
might contain a race condition? And on, and on, real-world issue
after real-world issue, each one analyzed and cross-referenced.
There's also a section on additional documentation sources, and a
chapter on tools that can help you make sense of whatever you've
just inherited.
Joel Spolsky:
"The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)".
http://www.joelonsoftware.com/articles/Unicode.html,
viewed 2005-07-26.
Joel Spolsky's 15-minute guide to character set encodings, and
what you have to do to deal with the fact that most of the world
doesn't use the standard American alphabet.
SQLite:
http://www.sqlite.org,
viewed 2005-07-26.
A small, simple, and very fast relational database that can be run
on its own, or integrated into other applications.
A tool for generating Perl, Python, and other bindings for C
programs.
William Thomas, Alex Delis, and Victor R. Basili:
"An Analysis of Errors in a Reuse-Oriented Development Environment".
Journal of Systems and Software,
38(3),
1997.
FIXME
Herbert H. Thompson and Scott G. Chase:
The Software Vulnerability Guide.
Charles River Media,
2005,
1584503580.
My current favorite guide to computer security for programmers,
this books walks through each major family of security holes in
turn: faulty permission models, bad passwords, macros, dynamic
linking and loading, buffer overflow, format strings and various
injection attacks, temporary files, spoofing, and more.
A [Python] web application development framework with
some of the same capabilities as [Ruby on Rails] (but not
as many users, or as much documentation).
Jon Udell:
"Internet Groupware for Scientific Collaboration".
http://udell.roninhouse.com/GroupwareReport.html,
viewed 2005-07-26.
While it is now several years old, Udell's examination of what the
web could be, and how it could help scientists collaborate more
effectively, is still as thought-provoking as it was when it first
appeared.
Larry Ullman and Marc Liyanage:
C Programming: Visual QuickStart Guide.
Peachpit Press,
2004,
0321287630.
A gentle introduction to C, with many examples.
University of Toronto:
http://www.utoronto.ca,
viewed 2005-07-26.
Canada's biggest university, and the host institution for much of
this work.
Michiel Van Genuchten:
"Why Is Software Late?".
IEEE Software,
17(6),
1991.
Compares call graphs for Windows and Linux web servers.
James A. Whittaker:
How to Break Software: A Practical Guide to Testing.
Addison-Wesley,
2003,
0201796198.
A slim catalog of things testers can do to break software.
James A. Whittaker and Herbert H. Thompson:
How to Break Software Security.
Addison-Wesley,
2004,
0321194330.
This practical companion to [Whittaker 2003]
catalogs things you can do to test (and break) security measures
in programs.
Laurie Williams and Rober Kessler:
Pair Programming Illuminated.
Addison-Wesley,
2003,
0201745763.
A combination of an instruction manual, a summary of the authors'
empirical studies of pair programming's effectiveness, and
advocacy, this book is the reference guide for anyone who wants to
introduce pair programming into their development team.
Greg Wilson:
Data Crunching.
Pragmatic Bookshelf,
2005,
0974514071.
Every day, all around the world, programmers have to recycle
legacy data, translate from one vendor's proprietary format into
another's, check that configuration files are internally
consistent, and search through web logs to see how many people
have downloaded the latest release of their product. It may not be
glamorous, but knowing how to do it efficiently is essential to
being a good programmer. This book describes the most useful data
crunching techniques, explains when you should use them, and shows
how they will make your life easier.
WingIDE:
http://wingware.com,
viewed 2005-07-29.
A commercial IDE targeted solely at [Python] developers.
Scott N. Woodfield:
"An Experiment on Unit Increase in Problem Complexity".
IEEE Transactions on Software Engineering,
5(2),
1979.
Makers of Prince, the document formatter and generator used to
produce the PDF version of these notes.
Andreas Zeller:
Why Programs Fail: A Guide to Systematic Debugging.
Morgan Kaufmann,
2006,
1558608664.
This well-written, copiously-illustrated book from the creator of
DDD (a graphical front end for the GNU debugger) is a survey of
current and next-generation debugging tools. Some are old
friends, like bug trackers and symbolic debuggers. Others are
new: there's a detailed look at the pros and cons of replay
debugging, an automatic divide-and-conquer tool that can strip
test cases down to their essentials, and a whole chapter on how
dependency analysis and program slicing can be used to isolate
faults. If, ten years from now, debuggers have taken a
much-needed leap forward, much of the credit will go to this book.
