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
2006.Feb.22 Wed
William Pietri writes, in the XP mailing list:
Like many others here, the metaphor of software development shop as factory has always raised my hackles. There are a lot of reasons it's misleading, but I finally put my finger on what I think is the biggest one.
Imagine a traditional factory with your standard assembly line. Let's just think of a simple one: you've got your receiving department on one end, five stations on the line, and some final quality control just before the shipping department. Let's further assume that your people all get things right 99 times out of 100. Sounds pretty good, right? Of course, when you multiply it out, that means either quality control or your customers will toss out circa 5% of your parts, but as long as you account for that in your pricing, you're good to go.
Now let's imagine that's software they're making. If the typical bug database is any guide, software quality control is not as effective as factory quality control. Let's suppose that half the bugs make it through and onto the truck. Then the truck pulls away and pulls right back up at your receiving department. In other words, the main input to most software development is what the team produced the day before.
This difference entirely breaks the factory model, If you repeat the same quality-reducing operations over and over on the same material, your quality inevitably declines and your costs for producing something worthwhile will increase. In the end, you have to throw out everything as unsalvageable. Which sounds exactly like a lot of software projects I've seen.
To survive with a circular assembly line, aiming for perfection isn't good enough. Instead, every time we touch the code, we need to leave it better than we found it.
Quoted with permission.
Encapsulation Wasn't Meant To Mean Data Hiding
Martin Fowler: "the point of encapsulation isn't really about hiding the data, but in hiding design decisions, particularly in areas where those decisions may have to change. ... When you are thinking about encapsulation I think it's better to ask yourself "what peice of variability are you hiding and why" rather than "am I exposing data. (Craig Larman wrote a nice column for me on this.)" Larman quotes Parnas: We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then design to hide such a decision from the others.
In Cocoa programming, we often have to declare a bunch of getter methods in certain objects using "key-value-coding/observing/binding" conventions so that user-interface views can synchronize their data with controllers and model objects. It's explained rather well here.
Outside of special purpose getters required by a framework, it is appropriate to look for opportunities to move methods closer to the data they work with. If a method in one class is calling several getters of another class, perhaps that method belongs to that other class. Fowler writes: "...a simple rule of thumb ... that I first heard from Kent Beck, ... always beware of cases where some code invokes more than one method on the same object. This occurs with accessors and more reasonable commands. If you ask an object for two bits of data, can you replace this with a single request for the bit of data you're calculating? If you tell an object to do two things, can you replace them with a single command? Of course there are plenty of cases where you can't, but it's always worth asking yourself the question."
Allan Shalloway wrote (starting with a quote from Design Patterns: "Consider what should be variable in your design. Focus on encapsulating the concept that varies. This mandate was a bit confusing to me at first. To me, encapsulation meant "data-hiding". But to the Gang of Four, it means something else: Encapsulating the concept that varies is encapsulation of type."