Matt Heusser’s Blog
Testing at the Edge of Chaos
HP Culture, Circa 1976
Wozniak:”No, I’m never going to leave Hewlett-Packard. It’s my job for life. It’s the best company because it’s so good to engineers.” It really treated us like we were a community and family, and everyone cared about everyone else. Engineers—bottom of the org chart people—could come up with the ideas that would be the next hot products for the company. Everything was open to thought, discussion and innovation. So I would never leave Hewlett-Packard. I was going to be an engineer for life there.
…
Livingston: You were designing all of these different types of computers during high school at home, for fun?
Wozniak: Yes, because I could never build one. Not only that, but I would design one and design it over and over and over—each one of the computers—because new chips would come out. I would take the new chips and redesign some computer I’d done before because I’d come up with a clever idea about how I could save 2 more chips. “I’ll do it in 42 chips instead of 44 chips.”
The reason I did that was because I had no money. I could never build one. Chips back then were… like I said, to buy a computer built, it was like a downpayment on a good house. So, because I could never build one, all I could do was design them on paper and try to get better and better and better. I was competing with myself. But that’s just the story of how my skill got so good. It’s because I could never build anything, I just competed with myself to come up with ideas that nobody else would come up with.
– Steve Wozniak
(Link leads to excerpt from Founders At Work)
In the article, we see that Steve is obsessed with the idea of creating designs that are simple and elegant. That just sort of, well, work. That can flow intuitively.
It’s the same with software. If your software sounds complex and hard to understand, it’s probably buggy. Keeping the software simple – searching for the elegant solution instead of the easy one – leads to less lines of code, faster development, and fewer defects. A few years ago I wrote Beautiful Code for Dr. Dobbs, but I suspect it needs a follow-up. Beautiful Systems? Beautiful Solutions? hmm … needs work.
Tomorrow: Blue Man Group. Serious this time!
Errata
I’m pretty buried in side projects right now, but I did want to get a few things out.
First, I found this bit from Joel Spolsky, excerpted from the book Founders At Work, and wanted to share:
I think probably there are a lot of workaday programmers working on upgrades to Enterprise Java (now I’ve insulted all the Java programmers) who never achieve flow. To them, it’s just kind of engineering step by step; it’s never the magic of creation.
– http://www.foundersatwork.com/joelspolsky.html
If you have ever considered going independent, or just find the subject interesting, I think you’ll find it a good read.
Second , my speaking schedule for 2007 is out. I will be moderating lightning talks at STAREast in May, and the “Call for lightning talkers” is on …
Against Systems – IV
I’ve been looking for a way to wrap this up, when I stumbled accross and article titled “Process as a Substitute for Competance” that seems to do it for me …
On one recent project, the software development managers insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.
The code in question? Five lines of SQL.
…
The problem with this model, though, is that anyone who is halfway competent finds himself spending more time on process than on actual, productive development activity. Everything is drawn out over a huge period of time. I think this is the main thing that’s been driving alternative methodologies like Agile and SCRUM — the desire by skilled developers to sweep away all that process that’s “in their way,” and get rid of documentation and meetings.
- http://killthemeeting.com/mt/2006/10/process_as_a_substitute_for_co.html
… I was wrong
A few weeks ago I put out a post on Elisabeth Henricksen’s 2002 presentation, “Why Are My Pants On Fire?”.
My conclusion was that the sentiment was obvious, but people don’t act that way. While we might “know” the material intellectually, our behavior indicates otherwise. So, while the material wasn’t new, we still need more people saying it.
After three weeks of talking to folks, it’s becoming clear to me that this is, in fact, not obvious to a great many people.
That scares me. It tells me that we don’t need more people presenting ideas like this — we need a lot more.
Elisabeth, please accept my apology.
Against Systems: Interlude …
More Against Systems to come, but first, a couple of things …
1) Jon Kohl points out that we only exist because of little systems like circulation, muscular, the solar system, and so on. Obviously, the blog entries “Against Systems”, which I chose for a bit of shock value, are talking about a different kind of systems: Systems developed by humans that are, well, naive at best. If I had to do it again, I’d probably choose a different title, but right now, too many people have linked to the series for me to change the name (and have blogger change the name.) Perhaps I can find a better name for some follow-up-posts.
2) In November I saw Chad Fowler speak at XPWestMichigan, and blogged a bit about it.
Well, the talk is finally Finally Up on Google Video and you can see it for yourself.
When you hear the nerd who likes perl and raises his hand … that’s me. 
Against Systems – III
Did you know that honor codes that consist of a specific list can be gamed? For example, the US Air Force Academy Honor Code, at one time, was:
“We shall not lie, cheat, nor steal, nor tolerate those among us who do.”
So, let’s say you are nineteen, go to a tavern and order a beer. The bartender doesn’t ask your age. You don’t tell him. Did you violate the honor code?
Think about it. You didn’t lie. No one asked you a question! A lot of Air Force Cadets in the 1980’s said “No”, it wasn’t an honor code violation, and therefore found bars where they would not be carded.
The problem is that the more precise you make it, the more holes enter into the system. Trying to nail down all of these little exceptions with more clarifications doesn’t really help; you either get a legal brief that no one reads, or you leave room for someone crafty to think of exceptions.
There is another way. I found this on Wikipedia Today:
Washington and Lee maintains a rigorous Honor System that traces directly to Robert E. Lee, who said, “We have but one rule here, and it is that every student must be a gentleman.” Students, upon entering the university, vow to act honorably in academic and nonacademic endeavors. While “honor” is often interpreted as meaning that they will never lie, cheat or steal, the Honor System actually proscribes whatever behavior the current generation of students decides is dishonorable.
The Honor System has been run by the student body since 1906. Any student found guilty of an honor violation by his or her peers is subject to a single penalty: expulsion. Faculty, administration and even trustees are powerless; the Honor System is defined and administered solely by students, and there is no higher review. Referenda are held every three academic years to gauge each generation’s appetite to maintain the Honor System and its single penalty, and the students always re-ratify the Honor System by a wide margin.
Washington and Lee’s Honor System is distinct from others such as those found at the neighboring Virginia Military Institute and the University of Virginia because it is not codified. That is to say, unlike those others, Washington and Lee’s does not have a list of rules that define punishable behavior.
The Honor System encompasses fundamental honesty and integrity. Other disciplinary frameworks exist to address lapses of social and behavioral standards that do not fall into the category of a student’s basic honor. (If you cheat on an exam or take a book from the library without checking it out, it’s an honor violation. If you go 55 in a 50-mph-zone, it isn’t.)
As a result, a sense of trust and safety pervades the community. The faculty and staff always take students at their word (and indeed, local merchants accept their checks without question; many also extend credit). Exams at W&L are ordinarily unproctored and self-scheduled. It is not unusual for professors to assign take-home, closed-book finals with an explicit trust in their students not to cheat.
The Honor System clearly works. In most years, a few students are expelled after trials conducted by the elected student government (with the accused usually counseled by law students). Recently, expulsions have ranged from 8 in the 2003-04 school year to a more modest 2 in the 2004-05 year. Students found guilty can appeal the verdict to the entire student body, although this daunting option is not often exercised.
Something tells me that the eight-to-two people that got expelled were expelled for a fine reason, and that appeal would just make them look bad.
Is that a “defined process”?
If it produces reliable output, why do we care?
Update: Just FYI, it’s the 200th birthday of Marse Robert.
Three days in Indy?
I will be in Indianapolis on Thursday, March 22nd, Presenting Rethinking Process Improvement at a meeting of the Indianapolis Quality Assurance Association (IQAA), with a one-day workshop on software requirements the day following. We’re value-pricing the workshop to make it affordable – $250 for a one-day class – about the price that a corporate IT manager can expense without having to get sign-off from a vice president.
I haven’t worked out the schedule 100%, but I hope to stay in town for the March Meeting of the Indianapolis Workshop On Software Testing, which is March 25th.
See you there?
Intuition
James Bach is running a rapid software class over the web, and I am enjoying it. (You can take the course for $250 per session; read about it – here).
He also has forums set up for people who are taking the class.
Here’s my latest post to those forums:
Michael Bolton Wrote:
Intuition, to me, means “some cognitive process that I can’t articulate (mostly because I haven’t tried, or I haven’t really thought too hard about it).”
I dunno about that. I might agree with “often” instead of mostly.
A few years back, I heard a speech by Dr. James Dobson, where he claimed that in females, the connections between left-and-right brains are closer, and more active in communicating. That means, for example, that they might connect a nod of the head or look in the eyes with an intent that men don’t pick up on.
Several times since then, when my wife says “I don’t trust that guy …” about someone I might work with, I listen to her. And she is allways right.
We call it women’s intuition, and I think that, physiologically, there is something to it.
I think it’s similar with men. With testers, it’s often more like Deja Vu – we notice that the software is doing something weird, but can’t articulate why, and it’s actually our subconscious that still remembers the SUPERMAN game we used to play on the Atari 2600, where you could win the game just by walking to the left at the beginning instead of going right – which was the action sequence that ’started’ the game.
But we don’t REMEMBER Superman.
So, I’ve learned to trust my gut. I would add that I think there is benefit to be gained from asking your gut “ok, why do you think that’s true?” and active introspection. We might not always get answer, but it’s usually helpful …
So, I guess I’m saying I agree with you, if in a more mild extent .
Great Writing
George Dinwiddie wrote this and it struck me as worth quoting…
5. In spite of a technical background that goes back to childhood, my sailboat has virtually no electronics.
The depth sounder died years ago. I use a leadline. The knotmeter also gave up the ghost. I drop a potato chip off the bow and count the seconds until it reaches the stern. I made up a chart to convert that to knots. I’ve got a VHF radio, but it’s an old one that predates using frequency synthesizers, so it doesn’t have all the frequencies now in use. I’ve got a magnetic compass. And paper charts.
That’s it. No GPS. No radar. Nothing fancy, at all. Of course, the Chesapeake Bay is generally a pretty forgiving place to sail. I’ve only been in pea-soup fog a few times. So partly this lack of fancy toys is an expression of YAGNI rather than me being a luddite.
The main reason to sail without those aids is to experience more deeply using my own senses. I’m more aware of my surroundings because I’m looking around, rather than looking at a dial or screen. I feel how the boat moves through the water, how it responds to the wind and to the helm. And that’s really the reason for going sailing, in my opinion. If I just wanted to get to the other end of the trip, there’s faster and more efficient ways.
- http://blog.gdinwiddie.com
I haven’t seen the Chesapeake Bay for nearly ten years. Oh, and in my mind, about five minutes ago.
What would it be like if more requirements – or any software engineering documents, for that matter – were written like that?
Standards – II
George Dinwiddie has a great response to my previous post on standards. In his post, George says:
Why do people want to choose a standard before they’ve tried something to see how well it works?
… (snip) …
Processes, like software, don’t work well unless they, well, work. So get it working first, and then worry about whether you should standardize on it.
A short while ago I worked tangentially with a team that was implementing a business intelligence tool. The architect of that team was quick to point out that they were really implementing a business intelligence service – a process. In that case, it was important to get the process right. So, once the servers were installed, but before they rolled the software out to a customer, the team had to develop the methodology. They had to define the process to requesting a BI universe, for defining it, for scheduling it, for prioritizing. For each of these sub-processes, the team had to use a standard template. The architect was very clear that the template had to be filled out correctly, and there was some amount of back-and-forth over how to correct describe a methodology component.
They had a template standard. They had a standard standard.
And, eventually, the group threw it all out, choosing to instead actually run a project, then document what they did.
The odd thing that I have seen is that groups that do this often fail in a way that is predictable and repeatable – yet don’t see the problem.
For lack of a better term, I will call this “Paradigm Blindness” – when you see the way you work as “right” and build defenses against it, instead of admitting that experiential evidence should guide the way we work.
With paradigm blindness, when you have documented test scripts and quality stinks, you say “Next time, we need to do a better job documenting our test scripts.”
When the requirements process is a big, painful waste of time and the customer is unhappy with the results, you say “Next time we need to get the requirements right up front, before we ever right a line of code.”
When the company keeps trying to increase the accuracy of it’s estimates and failing, you focus on getting “more accurate estimates” instead of trying to deal with uncertainty as a real thing.
In the mean time, there’s a quality guru named Deming and he came up with an idea called the Plan-Do-Check-Act cycle – where you do a little planning but then conduct an experiment to see if the standard will work, then check results, then move forward – often, you do these in cycles.
There’s another name for this: The Scientific method. And when methodology proponents argue for processes that defy the scientific method as “right”, you’ve probably got a case of paradigm blindness going on.
I’ve been seeing this more often (see the last few posts.) Does anyone have any ideas on how to deal with it?
POSTSCRIPT: I was a bit worked up when I typed this. I hope it makes some sense.
A google search points out that “Paradigm Blindness” is apparently, a real phrase – not quite real enough to make Wikipedia, though. The best definition I found was “Paradigm blindness is a term used to describe the phenomena that occurs when the dominant paradigm prevents one from seeing viable alternatives.” From this web site in Google Cache.
