Hecksel's Software Zone

An evening with Gerald Weinberg I had a once in a lifetime opportunity on Monday (03/14/05) to spend several hours of one on one time with one of the IT industry's best and most influential leaders - Gerald (Jerry) Weinberg. I was attending / presenting at the Software Developer Expo (SDExpo West ) conference at the Santa Clara Convention Center. The following are some of my own thoughts / observations. In addition, I am reposting some comments on the lunchtime keynote by Gerald Weinberg from the SDExpo 2005 Blog site SDExpo West First, I got to spend 30 minutes with Gerald Weinberg before his session - Dan Rawsthorne saved a seat up front for me, and Gerald was sitting in front of us until he got up to speak. After my presentation late in the afternoon, I had the opportunity to go to dinner with Jerry and 9 others at 7:30pm. At 9:30pm, all had left but Dan Rawsthorne, myself, and Jerry. We sat at the restaurant and talked until 12:30am. Quoting Dan R. from dinner last night "What a 24 hours it has been". My observations: ----------------- Prior to his lunchtime keynote, Jerry asked several of us seated near him "How can you tell a Dog is really a Dog". He stated that the definition is "A dog is that which other dogs know is a dog". And then he quipped "You know, it works for programmers too", and gave one of his nods and smiles. Think about it - how do you know a very good developer? That which other developers think are very good - other people will define/decide. How do you know a good application architect? ( nod and smile ). When Jerry started at IBM in the 1950's, his title was "Applied Science Representative". The RAMAC storage device, IBM's "secret" and first introduced computer disk storage device ( the size of two hotel rooms ) held 4.4MB capacity, each platter was 24 inches in diameter, and there were dozens of platters stacked vertically in which an arm would go up and down selecting the right platter, then move in to read the right Track / Sector / Head ( my first job at IBM was writing mainframe disk device drivers for the VM mainframe operating system ). Jerry asked in the lunchtime keynote: What is an intermittent bug? Answer: Only a bug if someone is trying to use the feature where the bug resides. He used a vacuum tube example that is perhaps the best memorable story I'v heard on why frequent and iterative testing is so important to do. He was showing the inside of IBM's mainframe manufacturing facilities in the 50's/early 60's. He stated that it took months for each computer to be built. He stated that a common problem on the manufacturing line ( as well as once on the customer site ) was that of "borrowing a vacuum tube". Tracking down / debugging a missing vacuum tube was hard, but doable. But tracking down more than one vacuum tube missing at the same time, that was "much harder" than a single tube missing. People got good at recognizing the problem of a given tube being out. But with multiple tubes, hybrid behaviors would manifest themselves, causing many more ( and more difficult ) problems to track down and fix. The intent of the story is that the same concept is true with Software defects. Test iteratively and incrementally. If debugging software, be productive and chase the one bug rather (after modifying/writing just a bit of code ) rather than let things build up, creating situations where bugs begin to mask, influence, and morph one another's behavior. For example, a given defect may look like the letter "E", but in reality there are two defects that are combining to create the illusion of a single defect when in fact there are two defects - letter "F" and letter "L". Write some code, test it, shake any individual (easier) bugs out right away. Don't let them build up over time as so many organizations still do today, performing weekly or every other weekly builds. Do you think those weekly / every other weekly builds will be viewed as successful? Back in the days of punch cards, rubber bands were used / viewed as the configuration management system. "Good" programmers used two rubber bands on a deck of cards. They also did three (3) builds a day with cards - morning, afternoon, and overnight. There was a humorous comment on "transparent" program changes. How many times have you heard "Oh, don't worry, that change is transparent to us". Jerry defined "transparent change" as a "change you only find out about when you walk into it". On the screen was a picture of a 4 propeller commercial passenger airline in flight. The propellers were not obviously visible as they were in rapid motion. But believe me, you would know it if you walked into it - the transparent change. He had some great strories about software education and training in the late 1950's. He stated that during a two - three month class, there was only one opportunity for the class ( not each person in the class, but just one event for the entire class ) to actually attempt to run a program on the computer. This was due to the limited resources ( IBM was prioritizing deliveries to customers with the greatest need - customers with applications requiring 8 hours of processing time were deemed in more need that a customer having an application that needed only 1 hour of processor time to run even though both customers had the same amount of money to pay for the computer. Demand simply was outstripping supply in those days, with long ( multi month ) manufacturing cycles, and lengthy installation / training / customer setup ). Can you imagaine taking a computer class, and not having any ( none, nada, zip ) time on the computer to run actual programs? He said one "programming class" took the 400+ page "Principal of Operations" manual ( Note: I'm showing my age here, but I had a Principal of Operations manual within arms reach my first 4 years of my career at IBM ) and went down the instruction set, in alphabetical order. How's that for an exciting class? ZZZZZZZZZZZZZzzzzzzzzzz ... Now, after the lunchtime session, Jerry was in the audience on my session titled "Expert Panel on Agile Software Development". After the session was over ( during the session, he expressed a strong opinion that "People" is the source of most software issues, not technology ( Java vs. .Net ), not whether a company had a Service Oriented Architecture, but about the People doing the Software tasks. He questioned why the conference had so few sessions in the "People" track, and so many in the technical track if People was the real problem that needed to be addressed ), a group of nine of us went to dinner at the Westin next door. About 9:30pm, there were 3 of us left - Jerry, myself, and Dan Rawsthorne. The three of us wound up talking until 12:30am, discussing more about early days at IBM, the problems encountered in the US education system related to "gifted" children, his transition from high school to college, his transition from college to the work force, where he lived, our children and families, it was stories that both Dan and I related too, and to quote again Dan the following day: "Wow, what a 24 hours" ( referring to his past 24 hours at the conference ). Here is a reposting of text from another attendee's of Gerald Weinberg's keynote at SDExpo 2005 on Monday: ------------------------------------------------------------------ Today's opening keynote by author and consultant Gerald Weinberg, "Fifty Years of Software Development--Lessons From the Ancients, " was an entertaining romp through his early years at IBM. Here are some highlights: Thinking like a computer: Hired early on as a "computer," or person who performed mathematical computations by hand, Weinberg said that it had affected him ever since. "When I perform an operation, I think like a computer. I can look at a program and see if it will perform well or poorly. How many in the audience know what I'm talking about?" There was a smattering of hands raised. Making transitions: He noted how at myriad junctures in IBM's history, people were lost: For example, when the first disk drive, RAMAC, was developed, some people didn't make the transition. When the change from paper tape to punch cards happened, some didn't like that change. When the move to programming on a screen rather that with wires on a board happened, some were left behind. The origins of open source: Though some like to claim it is a recent invention, he mentioned an early organization, SHARE, which was an open consortium for interchanging source code. [I'll have to look into that in greater detail--I'm interested in writing a piece on the history of open source, going back earlier than most do.] The importance of programmers: In the 60s, at a company meeting of 500 or so programmers, he overheard two executives say, "It can't get any worse than this," meaning there couldn't ever be more programmers hired. "I'm happy to say that now you can't fit all the IBM programmers in one room." Recognizing star developers: Pointing to a slide showing several decks of punch cards, he said that the one with two rubber bands holding it together was the one by the best programmer, because that was the configuration management system of the day, and he knew that you had to fully use all of it, not disable some of the functionality by trying to get away with just one rubber band. IBM's arrogance: Early on, Big Blue refused to sell its computers. In one instance, it turned down a handsome purchase offer because the company in question wanted to perform a calculation that only took one hour a day. IBM execs felt that was a waste of the awesome power of the machine. "But I'd had some sales training before that, and I started working on the program, and when I was done with it it took 8 hours a day to do the calculation [audience laughter]." I'd be interested in hearing from audience members as to what they enjoyed most about Weinberg's talk. Feel free to post comments here! ( Mar 16 2005, 01:51:13 PM CST ) Permalink Comments [1]