About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2003.Sep.30 Tue
Thanks to Martin Fowler for providing a link to his description of Jim Johnson's speech at the XP2002 conference, vaguely mentioned in my previous blog entry. Fowler wrote:
Johnson's comparison of two SACWIS systems. SACWIS is a child welfare system that all the states in the US must implement. He stated that Florida began its SACWIS system in 1990 with an original cost estimate of $32 million for delivery in 1998 with a development team of around a 100 people. When they last looked the new cost was $170 million due to ship in 2005. He pointed out the state of Minnesota has to build the same capability with pretty much the same demographic issues as Florida - leading to very much the same broad system requirements. Minnesota started work in 1999, finished in 2000 with eight people costing $1.1 million.
Measuring by effort, 16 person-years versus 1500 (projected) person-years, shows the Minnesota project was 93 times more productive.
James A. Robertson links to a comparison of two implementations of an example web application. It compares source code rather than effort... the Java/Struts sources are six times larger than the Smalltalk implementation, and have three times more classes. The author of the Smalltalk implementation says "I do recall the folks at the users group saying that they typically spent about 5 to 10 times as long to do wafer in the Java based frameworks (1 day vs 1 - 2 weeks)".
2003.Sep.29 MonMartin Fowler has blogged on this subject, saying that we can talk sensibly about the effectiveness of tools and methodologies because "we can't measure the productivity of development teams. Strictly the problem is that we can't measure their output - how much stuff gets cranked out."
I suggest we can measure productivity, but only at a higher level: how much time and effort does it take to satisfy the customer? Not just for the initial product, but also for changes to the product.
For example, if the customer only needs a simple word processor, and team A delivers a simple one like MacWrite in three weeks, and team B delivers a complicated one like current versions of MS Word in three months, and both satisfy the customer, I would say that team A was more productive, regardless of number of lines of code generated or the number of function points implemented.
I'd like to quote the example of two states' implementations of the same federally-mandated tracking system (Florida and Minnesota?), where one was developed in two years or less with less than a dozen people, and the other (over-budget) one was predicted to take five or more years and employ up to a hundred people, but I can't find a link. I think it was first mentioned in a keynote speech of an agile conference.
2003.Sep.22 MonSome quotes from a MacIntouch page on justifying buying Macs...
Converting from Windows to Mac server:
Actually a 100% Windows client company that I'm familiar with went the other way. They bought a Mac OS X Server to replace their farm of Windows servers. If "it all comes down to $", this was much cheaper as X Server has an unlimited license version that is more cost-effective than the Microsoft offerings. Windows clients seem to work as well with the Mac server as with a Windows server.
Their previous Windows servers crashed regularly, caught viruses on occasion, were rather slow and cost a lot of money and time to buy and maintain. Patches every week and constant trouble calls from users. This kept the admin more than well employed.
The single Mac server that replaced them is blindingly fast, can't catch Windows viruses and hasn't been rebooted in all the months since it was installed. The admin now only has maintenance on the Windows client machines; the server requires little more than changing backup tapes....
"Today there is not a single known virus on the Mac OS X -platform"
Virus woes
I teach at the University of Texas in Austin. Recently at a faculty meeting we heard a report from our school's computer support director. She was relating the experience of her department in the weeks before school started, when the university was plagued with the now-familiar series of Windows-related viruses and worms.
It was a nearly unbelievable tale of woe and hair-tearing frustration....
For a couple of weeks, it was a common sight to see computer techs rolling around large carts filled with PCs headed for "remediation."
The head of IT services later told me that another weird twist to this tale is that students, and sometimes parents, who brought a computer from home and then started using the campus network with that computer, would reintroduce a virus/worm to the campus network. And sometimes these computers were wireless, which meant that the IT services techs were literally chasing users around a building, up and down stairs or elevators, trying to find the infected machine and get it off the network.
Our school's support tech said to me, "If it weren't for the fact that a third of our computers are Macs, I would have jumped out a window."
None of the Macs on campus needed to be "remediated." Zero. After I heard this, I asked my fellow faculty members, "Why does anyone still use Windows?" Moreover, for institutions that are facing budget constraints and a shortage of trained personnel, why on earth would any institution think that it's fiscally responsible to depend on Windows machines?
Homogeneous computing is not only stupid, it's irresponsible.
"If you look at the IT departments at prestigious private schools -- Harvard, for instance -- standardization is a dirty word."
InfoWorld's Tom Yager: "Windows doesn't live here anymore" The client switch away from Windows is permanent, and the server switch is next.... I am turning away from two core assumptions: that all x86 machines are destined to run Windows and that all worthwhile entry-level servers, business desktops, and serious notebooks use Intel CPUs. "
Cost of support
I am an "army of one" supporting 20 Windows PC's, 67 Macs for teachers, and 64 iBook laptops for students. For the past two years I have documented my service calls and support issues and I have found the split to be almost exactly 50/50. This means that 20 Windows PC's require as much support as 131 macs.
Regarding Microsoft Access (the only part of Microsoft Office that isn't available on the MacOS X platform)
2003.Sep.21 SunAbsolutely nothing has 100% compatibility with Access, not even Microsoft's own Visual Fox Pro for developers. Access is the worst database I have used. It has no clean migration pathway to any other database application. You can transfer data by exporting Access database tables, but you can not transfer Access forms, macros, or Visual Basic customizations. If you jump through some hoops, you can convert Access queries to SQL and copy them to another database. That's it.
If you need an easy to use, crossplatform database, I recommend FileMaker Pro (relational) or Panorama....
I looked up Kaizen Events because of a blog entry by Joe Ely. He emphasizes that kaizen events take practice, must adapt to local conditions. They reshape expectations about change, and help you re-think your job. He says that goal clarity is critical, simple real-time documentation is essential, and visual tools are critical too.
Google finds this definition:
The Kaizen method is a "rapid improvement process" utilizing a cross-functioning group of managers and employees working as a team to meet targets in a results-oriented focus on a predefined project area. The process may take the following steps: define the problem/opportunity, choose the best people, and correct the problem in one week or less using Kaizen tools and techniques. The ultimate goal is to significantly reduce costs, reduce lead times, reduce required inventory space, enhance workforce empowerment, eliminate waste, and focus on continuous improvement. The Kaizen process may include: new product development, robotics, total quality control, Just-in-Time, statistical quality control, labor and management relations, or other concepts.
Another page claims these results from Kaizen Events
- 30-50% Productivity Improvements
- 30-50% Reductions in Floor Space Requirements
- 50-70% Quality Improvements
- 70-80% Reductions in WIP [Work-In-Process] Inventory
- 40-50% Reductions in Lead Time
Of course, those results came from improving conditions and processes of manufacturing (not the processes of designing and engineering), but I think most typical software processes, from requirements gathering to delivery, could obtain a 50% gain in productivity and an even higher reduction in defects by adapting a lean / agile software development process.
How would a company do this? Perhaps by starting with a facilitated retrospective. Maybe followed or preceded by a few observant people walking through the entire requirements-to-delivery process - counting how many information-lossy hand-offs there are between workers, how often work sits in queues waiting for actions or approvals, and other efficiency-killers.
Just found another definition, here:
2003.Sep.20 SatKaizen Event
Any action whose output is intended to be an improvement to an existing process. Kaizen Events are commonly refered to as a tool that:
- Gathers operators, managers, and owners of a process in one place
- Maps the existing process (using a deployment flowchart, in most cases)
- Improves on the existing process
- Solicits buy-in from all parties related to the process
Kaizen Events are an extremely efficient to quickly improve a process with a low Sigma score. Kaizen Events are also useful for convincing organizations new to Six Sigma of the methodology's value.
The true intent of a kaizen event is to hold small events attended by the owners and operators of a process to make improvements to that process which are within the scope of the process participants
Science Daily: "Testing Information Systems During Development Will Prevent Problems"
A story at http://www.sciencedaily.com/releases/2003/09/030918093222.htm> says:
"Rather than waiting to test projects until they are completed, evaluating them at increments can prevent such troubles. That can keep projects from having cost overruns and needing time extensions."
Unfortunately, this news report is vague, mostly talking about metrics:
"The researchers developed a mathematical framework that groups metrics around the stages of project requirements; design specifications; implementation; and operation in the software system's intended environment. The framework revealed that some metrics are applicable only at certain product stages while others are applicable at multiple times. The researchers also realized few metrics exist for measuring the processes employed and resources expended during software development."
The original news release is here: http://www.psu.edu/ur/2003/testinginfosystems.html. The researchers' results are published in "Product Metrics for Object-Oriented Systems," ACM Computing Surveys, June edition.
Some other news releases at Penn State:
2003.Sep.15 Mon
Marathons and Software Development
Dave Hoover has a nice comparison of running/training for marathons and software development at http://www.redsquirrel.com/dave/work/marathon.html.
2003.Sep.13 SatOn the subject of separating code into loosely-coupled components... see PicoContainer. (This may be ancient history [June 2003] for some people.) Some quotes:
"PicoContainer is very simple container for very simple components. It honors the Inversion of control pattern (IoC) in a way that we calling it type 3 IoC. [...] The idea is that this might scale from embedded containers for simple beans to enterprise and distributed applications."
"Inversion of Control: What is this all about? IoC is a design pattern that is also sometimes called the Hollywood Pattern ("Don't call us we'll call you") or the Chain of Command pattern. Simply put, an IoC component does not go off and get other components that it needs on instantiation. It instead declares them to its boss, and the boss supplies them."
"Pico components (to remind you) are simple java classes that declare their dependencies in the constructor(s). No meta XML for dependencies. No classes/interfaces to extend/implement."
Note that the link to composite components is incorrect, it should link to http://www.picocontainer.org/compositecomponent.html
A blogger named Rickard wrote:
"PicoContainer: Here's something on the bright side. I just found the PicoContainer/NanoContainer projects, and to me they look like the perfect way to build loosely coupled component-oriented architectures. It's just bloody brilliant. WebWork used the type 2 IoC, and XWork currently does too, but they always felt a little awkward due to the extra coding needed. But this type 3 IoC stuff is just the way it should be. Nice and tidy, with flexibility for the implementation, and supports unit testing quite nicely. Just bloody brilliant. I can't wait to toss out our own kludgey service architecture in SiteVision in favor of this."
Rickard has an example of the usefulness of constructor-specified inversion of control here.
Last word: I was expecting a paradigm shift, and all I got was a lousy constructor
2003.Sep.06 SatIf you have insights about the following ways of organizing and documenting code, or recommendations for reading about these subjects, please email me. How do you structure your source code or otherwise document the following aspects of your projects?
I have read Lakos's book on Large Scale C++ Design and his recommendation for acyclic dependancies of packages and bottom-up implementation and testing of packages.
I've also read Robert Martin's book on Agile Software Development that has also recommends acyclic dependencies of classes and packages, and has a chapter on package design for managing dependences.
There's hasn't been much written about "refactoring to packages" and I'd like to know why.
2003.Sep.03 Wed
Book Review: Extreme Programming Refactored
See Ron Jeffries' review here: http://www.xprogramming.com/xpmag/books20030904.htm.
Some quotes:
2003.Sep.01 MonIt is dangerous to read for anyone who does not understand what XP is, because the authors have gone to such pains not to understand, to take out of context, and to distort.
A book satirizing XP might have been amusing to some people, but would have been informative to none. A book addressing XP's limitations and how to deal with them would have been valuable to a wide range of people and might even have been made entertaining as a side effect. The intimate mixture of satire, error, and somewhat good advice is unmanageable by anyone who doesn't already know the material, and largely unnecessary for anyone who does.
Almost half the book relies on demolishing the reputation of the C3 project through mockery and satire. Unfortunately, much of the discussion is as poorly researched [...].
The authors raise one of the most important issues with XP, namely that it won't work if you don't do it. As far as I know, no process will work if you don't do it, including the authors' own favorite. While they are quick to point out, and rightly, that a so-called XP project will go off the rails if the team doesn't do XP, they do not address the same issue for other proposed processes and practices.
For more valuable discussion of the limitations of XP and what to do about them, I would recommend either Pete McBreen's Questioning Extreme Programming, or Barry Boehm and Richard Turner's Balancing Agility and Discipline.
Marco Abis on the XP mailing list mentions a message-thread on RUP and Scrum/XP on the Scrum mailing list... here are some snippets:
Ken Schwaber: "Let us hypothesize that having a Scrum plug-in for RUP is an idea worth pursuing.[...] Is this type of metaphor appropriate for agile processes, or does this level of delineation lead to them being fodder for M/S project,for 'hands-off' management, and for robotic tracking of plans while ignoring realities?"
Ron Jeffries: "The comments from Rational clearly did not reflect the soul [of XP]. They do not get 'agile' in my opinion.[...] Their philosophy, again in my opinion, is based in large-systems experience, old-style 'up front' thinking, and a command and control orientation.[...] My involvement with the RUP XP plugin was based on my belief that it would be better with me than without me, and I think it is. Even so, it is still a long way from expressing what XP is."
Adriano Comai: "having been involved in many RUP customizations, I think RUP_Scrum makes sense (much more, in my opinion, than RUP-XP). RUP needs _exactly_ the Scrum practices to become agile. As you know, many shops with an existing waterfall culture buy RUP as an help to move towards a more effective development approach, and then misuse it."
Alan Shalloway: "You can take a committed dev group (most are) and have them do RUP/Scrum in a way that an upper management that doesn't want to hear about agile will accept.[...] here's a chapter discussing this I've just put on our public wiki (Dan Rawsthorne and I are writing a book on effective software development and this is a likely chapter). See http://www.netobjectivesbooks.com/N_O_BookFeedback_Wiki/owbase/ow.asp?DontTryToSellXP"
Marco Abis: " will try to explain why I think so (after years of effective RUP implementations!): RUP is fundamentally a very, very big framework [...] I will no spend time to write why managers like RUP but Scrum [...] makes me think that what managers want is something that isn't really useful to deliver the right project and often is the first impediment to the project success."
Adriano Comai: "Sometimes it's difficult to tell these organizations, who made huge investments into RUP: throw it off, there are more effective approaches out there, try them instead. In such cases, I believe, it is better to suggest an improvement using agile practices in the context of the existing process."
Marco Abis: "I experienced a lot of clients (of mine, of course) professing they were implementing an "Agile version" of RUP but when I analysed their work I found they were just cutting off some documents feeling "more lightweight". I definitly think this is one of the main issues: a lot of people believe Agile means just less docs, they try to cut off some of their docs and then affirm Agile is nothing more than this. As stated by Jim [Highsmith]: they are missing fundamental understanding of the unpredictability of project activities. [...] For those who haven't read it I suggest 'Agile Revolution' by Mike Beedle.
Marco referred to http://www.crystalmethodologies.org/cgi/wiki?AgileVsSelfAdapting, from which I quote Jim Highsmith: "So self-adapting, by itself isn't agile." and Alistair Cockburn: "criticisms of RUP [...] Doing the change case is very laborious. Just heard of an airline company that wants to use RUP, so they spent 6 months creating a RUP-for-them. Now every project has to spend 2 months turning that into a RUP-for-the-project. Problem is when the project is only 6 months long, this is too long."
Another Highsmith quote on that page: "But lightweight is only one aspect of agile, the other two are collaborative values and principles and a fundamental understanding of the unpredictability of project activities (although outcomes can be achieved). Agile is much more than lighter documentation and fewer processes. Rational is trying to have it both ways--still telling corporate managers what they want to hear in terms of predictability, control, productivity, etc. while at the same time touting that they are 'agile' also."