If It Hurts, Do It More Often

There's a soundbite I like to use in an agile context: if it hurts do it more often. Its surface illogicality makes it memorable, and there's a real truth in there. Many difficult activities can be made much more straightforward by doing them more frequently. XPers are particularly well known for applying this principle to testing, integration, design, and planning...

- Martin Fowler

Select Quotes from Peopleware, Part 4

In my early years as a developer, I was privileged to work on a project managed by Sharon Weinberg, now president of the Codd and Date Consulting Group.  She was a walking example of much of what I now think of as enlightened management.  One snowy day, I dragged myself out of a sickbed to pull together our shaky system for a user demo.  Sharon came in and found me propped up at the console.  She disappeared and came back a few minutes later with a container of soup.  After she'd poured it into me and buoyed up my spirits, I asked her how she found time for such things with all the management work she had to do.  She gave me her patented grin and said, "Tom, this is management."

Sharon knew what all good instinctive managers know: The manager's function is not to make people work, but to make it possible for people to work.

Peopleware, pg. 34, This Is Management

Select Quotes from Peopleware, Part 3

Projects on which the boss applied no schedule pressure whatsoever ("Just wake me up when you're done.") had the highest productivity of all.  Of course, none of this proves that Parkinson's Law doesn't apply to development workers.  But doesn't it make you wonder?

The decision to apply schedule pressure to a project needs to be made in much the same way you decide whether or not to punish your child: If your timing is impeccable so the justification is easily apparent, then it can help.  If you do it all the time, it's just a sign that you've got troubles of your own.

Peopleware, pg. 29, Some Data from the University of New South Wales

OFF-TOPIC: This is post-punk (Muxtape)

Here's a new muxtape I just finished.  Take a tour through post-punk, starting in 1979 and continuing, in chronological order, through the post-punk revival of the 2000s.

Enjoy:

This is post-punk.

Select Quotes from Peopleware, Part 2

Allowing the standard of quality to be set by the buyer, rather than the builder, is what we call the flight from excellence.  A market-derived quality standard seems to make good sense only as long as you ignore the effect on the builder's attitude and effectiveness.

In the long run, market-based quality costs more.  The lesson here is,

Quality, far beyond that required by the end user, is a means to higher productivity.

If you doubt that notion, imagine the following gedanken experiment: Ask one hundred people on the street what organization or culture or nation is famous for high quality.  We predict that more than half the people today would answer, "Japan."  Now ask a different hundred people what organization or culture or nation is famous for high productivity.  Again, the majority can be expected to mention, "Japan."  The nation that is an acknowledged quality leader is also known for its high productivity.

Wait a minute.  How is it possible that higher quality coexists with higher productivity?  That flies in the face of the common wisdom that adding quality to a product means you pay more to build it.  For a clue, read the words of Tajima and Matsubara, two of the most respected commentators on the Japanese phenomenon:

The trade-off between price and quality does not exist in Japan.  Rather, the idea that high quality brings on cost reduction is widely accepted.

Peopleware, pg. 21, The Flight from Excellence

How I Got Started in Software Development

I've decided to take Mike Eaton's challenge and answer some questions on how I got started in software development.

How old were you when you started programming?

I was 18.

How did you get started in programming?

When I was looking into possible majors prior to starting college, it came down to two choices: Psychology or Computer Science. I thought psychology was more interesting at the time, but computer science was the more practical choice. (Come on, we all have a relative or friend who graduated with a psychology degree, but ended up working in a restaurant or something.) The first time I saw source code was in the second semester of my freshman year of college. I had no idea what it meant to program a computer up until that point.

What was your first language?

Java.

What was the first real program you wrote?

I'm not entirely sure what you mean by "real" program, but....I believe it was a Java console application where the user could type in a number of pennies and the program would print out how many dollars, quarters, dimes, nickels, and pennies it broke down into.

What languages have you used since you started programming?

Java, C, C++, C#, Assembly, SQL, Prolog, Visual Basic, Common Lisp, Tcl, Bash script, MS-DOS script, JavaScript, Ruby

What was your first professional programming gig?

My first professional programming gig was developing extensions for a CAD/CAM software package called Unigraphics NX in C, C++, and C# for a die company.

If you knew then what you know now, would you have started programming?

Definitely. I really can't imagine doing anything else for a living. I get to be creative and make things out of thin air on a daily basis. I get to work with incredibly smart people on challenging problems that often require intense intellectual effort. And all from the comfort of an air-conditioned office!

If there is one thing you learned along the way that you would tell new developers, what would it be?

Developing software in the real world is almost nothing like developing software in the academic world. For example, you won't have clear, unambiguous requirements like you had in college. Rather than just doing things, you'll spend an enormous amount of effort just trying to figure out what you're supposed to do. In general, your people skills end up being more important than your technical skills.

What's the most fun you've ever had programming?

In my sophomore year of college, I took a class taught by Dr. Scott Grissom, in which we were split up into small teams and collaborated heavily on complex (at the time) programming assignments. Prior to this class, I was really questioning my choice of Computer Science as a major and really wasn't enjoying programming. The more complex programming challenges that I encountered in this class and the great interaction finally made something click in my head. I got way into the assignments, working night after night on my programs, and I ended up acing all the assignments (and ultimately the class). Programming came quite naturally to me and I started to really enjoy the challenge. That class convinced me that I had found my calling.

Select Quotes from Peopleware, Part 1

The main reason we tend to focus on the technical rather than the human side of the work is not because it's more crucial, but because it's easier to do.  Getting the new disk drive installed is positively trivial compared to figuring out why Horace is in a blue funk or why Susan is dissatisfied with the company after only a few months.  Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work.

If you find yourself concentrating on the technology rather than the sociology, you're like the vaudeville character who loses his keys on a dark street and looks for them on the adjacent street because, as he explains, "The light is better there."

Peopleware, pg. 5, The High-Tech Illusion