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]

Software Developer Expo / Special Events As I was doing some final co-ordination with the panelists ( making sure they are showing up , minor edits to my presentation, ... ), I visited the SDExpo 2005 site and was surprised to find my session listed on their Special Events page. This explains several email inquiries I received recently on the session that was referring to a writeup I had not seen before. I thought perhaps they were looking at the hardcopy program guide. I'm marking this one down on the "positive surprise" side. If you are attending the SDExpo conference next week, I'll be presenting at 5:30pm Monday 03/14/05 at a session titled "Expert Panel on Agile Software Development". Since this is the "Developer" zone, I thought I'd give it a mention. I have done four similar sessions elsewhere before - you might say it's become my "niche signature" event - agile development panel sessions. Two at JavaOne, the other two at the "No Fluff, Just stuff" conference series. The first was in 2002, and I was fortunate enough to have Martin Fowler accept my panelist invitation. Panelists that year were Martin Fowler, Scott Ambler, Alan Shalloway, and Brendan McCarthy. Even though it was scheduled just before lunch on the last day of JavaOne ( Friday ), the session still had an overflow audience - they had to set up an overflow room for the session. People started lining up outside the room 30+ minutes before the prior session was going to end. I did a similar session last year at JavaOne ( which is how I got connected with SDExpo - the SDExpo conference director came up to me after the presentation and said "I would like you to do one of these at SDExpo" ) - last year I had panelists Scott Ambler, Joshua Bloch, Dan Rawsthorne, and Dan Steinberg. This is the first time I'v presented at (or attended) SDExpo, though in 1997, I recall that JavaOne and SDExpo shared the Moscone that year, and I wandered the SDExpo vendor/expo floor one afternoon as the JavaOne badge was "good" for admittance to the SDExpo floor. I'll post an entry next week with some observations / updates on the "cool stuff" that I saw, and news I thought was significant. Here's a link to my session on Monday, March 14 2005: http://www.sdexpo.com/2005/west/specialevents.htm Oh, here is today's article that raised my eyebrows the most: http://news.zdnet.com/2100-3513_22-5604690.html?tag=nl.e550 Describes Microsoft's plans for an OS / RFID application / Database bundled suite offering for RFID. The "solution" suite packaging is what caught my attention - not just selling it as a piece/part, but the OS / RFID application / and SQL/Server bundled together - with their goal of being one of the low price offerings. So is anyone else still mourning over Duke's loss to the Tarheels? 11 straight points at the end of the game to tie, then take the lead? Oh, Coach K. He had "that look" on his face. I'v been meaning to read this book for quite a while, and still haven't: http://www.amazon.com/exec/obidos/ASIN/0446676780/qid=1110492289/sr=2-1/ref=pd_bbs_b_2_1/002-1270087-6881608 ( Mar 10 2005, 02:42:36 PM CST ) Permalink Comments [0]

Netbeans / Eclipse, and Role of Software Architects Two items caught my eye recently.

Topic One

First, Sun announced today the "Switch to NetBeans" program. Primarily targeting Eclipse users, those who download the NetBeans 4.1 Beta will find functionality to import an Eclipse module into NetBeans. If you are using Eclipse and getting frustrated with the plug-in maze, perhaps it's time to give NetBeans a(nother) try. Switch to NetBeans

Topic Two

I ran across an excellent article on the growing influence and demand for Software Architects within Information Technology organizations. I also liked the fact that it ( not by name, but by description ) advocated the "Hands On Architect" Team Composition Pattern. For a great read on the value of architecture, Click here And finaly, welcome to my Blog! - David Hecksel ( Mar 09 2005, 03:56:52 PM CST ) Permalink Comments [3]