Software is about people, not code.
Now, I’m sure tons of people will scoff at the idea of not having graphics in their feed. They’ve gotta have that curvy candy coated interface with the flash video about Steampunk Buttplugs posted by BoingBoing blaring right in their fucking face or else they don’t feel alive.
I laughed harder than I had in several weeks when I read that.
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...
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
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
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:
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
My name is Matt Blodgett, and I believe the most important problems in software development are non-technical.
I write from Chicago, Illinois.
Copyright © 2022 Matt Blodgett
