Date: Sat, 15 Jul 2006 12:46:17 -0700 From: James Bullock Subject: Re: Thanks for listening. Class, Thank you for your time. I hope it was useful to you. I put a great deal of thought into what might be most valuable to you, and how to present it so that you could take it in. We had a great example of the main point right at the end of the class, when the projecting computer went silly, and suddenly wouldn't do what I wanted next. The one thing I wanted it to do, it turns out. So, exactly that kind of thing is one reason why an early, "Zero Feature Release" is very, very useful. Your tool chain will mess up. Count on it. In reviewing today, I am pleased that I covered all of the points I set out to cover, with examples, concepts, and usually both. I touched up the notes I made to myself after the class, and included them below. They may help you recap the main points. (I always review anything important that I do, to see what I might do better. I recommend the habit.) Please feel free to contact me via email if you want to. If I get busy, it may take me a while to answer. I always answer eventually. Thank you again for your time. - Jim **** Main concepts: - Software engineering is about what we do to make software. One way to think of this is as "The Development System" - the collection of people, processes and tools we use to make the system of interest. Software engineering is studying "The Development System", and a collection of tools & practices that can make it up. - The "tool chain" is a big part of how we make software. It won't necessarily work out of the box, or work for any given problem. - We make tools to help us build software because building software is hard. In particular, building software includes a great deal of both detail complexity, and structural (or intrinsic is the other term) complexity. Computers are good at detail complexity, so we off-load that to free the humans to do what humans are good at: inference, deduction, synthesis, and other "having a clue" stuff. Anything repetitive or strictly derived from already available information is a candidate for the computers to deal with for us. String a bunch of that together, and you get "the tool chain." - Computers tend to be bad at reasoning, particularly in ill-defined situations, so attempts to automate the reasoning part of developing software are suspect. There was a great wave of attempting to do this over about 15 years that produced approximately nothing. Related to this, be suspicious of generators - including Rails. They'll be great for what they handle and may be active impediments for what they don't. - One way to look at building software is as a series of transformations of a definition of a system, from value proposition, through behaviors, to design, implementation, to something that runs. These transformations tend to be pretty good candidates for automation vs. deriving, deducing, or other thinking things which are less so. The transformations tend to involve a lot of repeated work and a lot of detail complexity - exactly what computers are better at than people. - Your tool chain (and your team, and your processes) are choices, to make it easier to get your system built. So, you can adjust your tool chain to be more or less help, if need be. We had the example in class of making a generator for Rails, so it would generate some new kind of stuff. Indeed. Yet, creating that capability isn't free either. FWIW many tools and even more frameworks have been made and never used because someone thought that "obviously" you could generalize some problem, and make the computers absorb it. As a heuristic to protect against doing ineffective automation modify your tool chain to solve a concrete problem at hand, only, and get immediate feedback on how well your automation is working. "Rails" actually came from the common parts of several web sites. - "Flushing out the tool chain" is a wise thing to do early. Having the tool chain fail stalls other work - not good. Tool chain issues tend to be integration issues, which as a category tend to have long resolution times, stall other work, and mask other issues. Again not good, because "Time - calendar time - is part of the game, too." So, find out that your tool chain is broken while you still have time to do something about it. (And assume that it is broken until you can demonstrate otherwise.) - Conceptually, the issue addressed by "flushing out the tool chain" is that "You don't know what you don't know." This is the key thing about engineering real systems - there is a whole lot of discovery. One term for this is: "terra incognita." Discovery projects are organized very differently from projects without unknowns. So, the tool chain is an analogy for doing the real work. "We don't know what we don't know." about how the tool chain will screw up, just like "We don't know what we don't know." about the system we are trying to build. So, try it. --- Any time you think you are out of "terra incognita" when building software, be suspicious. "All commercial software problems are large and novel" - they are the only kinds of problems worth the cost. This puts them all in "terra incognita." This is exactly unlike a traditional classroom experience. - You get at least these benefits from doing a "zero feature release" early, benefits which ought to make sense given the ideas above: --- Flush out the tool chain, to identify integration problems or capability gaps. A capability example is that possibility that "Hey, a different generator would help." in Rails. Do you need one or not? We don't know right now. --- An early release creates an opportunity to calibrate your planning assumptions. Do a zero feature release so you can make nothing, end to end. Then, do a "tiny feature release", and see whether your estimates hold - one week to make that first screen which matches our prediction, or one month and we're in trouble. --- Again with a "tiny feature release", it lets you get an early look at architectural risks, like "Does the network connectivity native to Java work well enough?" (Boehm's early "Spiral Development" methodology is organized around risks like these. He was working with tactical and similar systems where there are lots of architectural risks, so organized work as a series of experiments each addressing one risk.) Two examples in addition to what we talked about: A "zero feature release" may show you that the big server library you are depending on won't work with the version of Java that your GUI needs - another architectural risk. Or it could show you that there are no ANT tasks for the test harness you selected, and the tool chain itself is broken. Both would show that you have work you hadn't planned on. Good to know. --- Doing a "zero feature release" is a team building thing, to start learning how to work with each other before it is midnight the night before the project is due and you each have twelve weeks' ego wrapped up in "your" piece. It is nice to get an early success working together. - Doing a "zero feature release" early is really a separation of concerns thing (which you should be familiar with as a principle of good design.) Get confident that the tool chain works so you can forget about the tools while you work with the content of the system you are building. That will be hard enough without distractions. Notice how flushing out the tool chain off-loads you, the developer, to focus on designing the system at hand vs. other things. - Your tool chain will mess up. Count on it. Your tool chain won't work exactly as you intend. We can't even keep a simply slide projection thing running for an hour, as we demonstrated in the class today. So, assume it won't work until you have demonstrated that it does. - As a purely concrete, tactical suggestion, carry your tool chain on your project risk list until you've made it go. I always do. - Jim -- Listen to a "round table" of experts in these books from Dorset House: Roundtable on Project Management, http://www.dorsethouse.com/books/rpm.html Roundtable on Technical Leadership, http://www.dorsethouse.com/books/rtl.html