I just stumbled upon a blog posting by Chad Myers titled “Good Design is not Subjective.” It’s hard for me to believe, but apparently this is a controversial subject in the software community today. The thrust of his position is that a good design is characterised by its ability to easily maintain and enhance while a bad design is characterised by its difficulty to maintain and enhance. A bad design exhibits characteristics of rigidity, fragility, and immobility. It’s an interesting article, and it is reminiscent of many of the themes advocated on this blog. A good design is the essence of agility. A good developer knows it when he sees it. Read the article. I’m sure you’ll like it. The comment thread is interesting as well.
As a kid, I recall watching the Jerry Lewis Telethons.To my surprise, I understand that the Telethon continues to this day, but I haven’t watched one since I was a kid. The Telethons are always successful in reaching their goal, yet they only have a fixed amount of time to achieve it: 24 hours, if I recall correctly.
The Telethon’s success in achieving its seemingly unreachable goal left an impression on me:I guess because our family was always cheering for Jerry to reach his goal towards this worthy cause, and he always managed to exceed it within the waning minutes of the event.There’s nothing like wresting victory from the jaws of defeat to leave an impression on someone.
August 05, 2008By: Bill Miller Category: Analysis, Design
I enjoy playing FreeCell. It’s a form of stress release for me, sort of like smoking is to some. Whenever I need a quick break or I’m looking to take my mind off of something, I’ll often play a game of FreeCell.
FreeCell is a puzzle, requiring analysis and strategy to win. They say every game is winnable, and I believe that it’s likely to be true. Whenever I lose a game and I’m determined to win, I eventually win after repeated retries of the same game.
Recently, when playing FreeCell to take my mind off an essay I was writing, a thought occurred to me: FreeCell illustrates the value of upfront analysis and design. On a number of essays on yuwantitwhen.com, I’ve advocated that doing proper upfront analysis and design on our software projects is the best way to secure success for our projects and to shorten schedules. Similarly, in FreeCell I’ve won more games on the first try when I devoted more time to upfront analysis and developing a strategy.
As a reader of Businessweek, I usually start from the back. That’s where Jack and Suzy Welch answer questions from the readers. In the June 30th publication, there is a quote from the Welch’s that hits upon a recurring theme of mine, and I’d like to share it. They talk about the challenge of balancing future requirements with current requirements. Here’s what they have to say:
… Because, in our opinion, one of the fundamental tenets of management is that you have to eat while you dream, meaning, you have to make money in the short term while you invest for the long. Any dope can do one or the other. To keep the cash flowing, simply squeeze everyone and everything you’ve got. The same goes for strategy. Just tell everyone to buzz off — you’re busy envisioning the future. The challenge of leadership is balancing today’s needs with tomorrow’s opportunities.
Tomorrow’s opportunities need to be balanced with today’s needs. There’s no formula here, and notice where he says that opportunity lies: in the future. Many use the word “enough” to describe this relationship favoring the present over the future, but “balance” is more appropriate as it doesn’t favor either the present or the future. It’s situational as it should be, and overly favoring the present sacrifices opportunity. Who can afford that? Finally, it’s the essence of good leadership. Here’s the article: “While Coporate Europe Fiddles…“
The second quarter was another successful three months for yuwantithwhen.com. A number of essays were very popular with the site’s visitors. The most popular essay for the quarter was “Why It Takes So Long.” Thanks to Steve Johnson over at Pragmatic Marketing for directing his readers to the posting. There are often very good reasons it takes longer than expected to deliver a software product, but there are things that we often do to make projects take longer than they should. I’m thinking of writing the sequel to the essay: “Why it Takes Longer Than it Should.” I’m not sure when I’ll pen that one, but it’s in the queue.
For about 10 months I’ve had the world map displayed on the top left sidebar of this web site. It’s a really cool free widget created by amung.us. Whenever a visitor visits the web site, it posts a marker on the world map identifying the location of each visitor. Recently, the markers on the map have been resetting everyday. Since I like the cumulative record of visitors on the map, I contacted the company and asked why they made the change, and here is their response:
We experienced some technical difficulties at one of our data centers which resulted in some users missing stats data. We are attempting to recover any lost data, and restore the service to full working capacity.
Thank you for bearing with us during this time.
Christopher C. Shannon
whos.amung.us
Christopher responded quite rapidly, and I appreciated his frank response. However, I grew impatient waiting for a fix, and I’ve been thinking about upgrading to feedjit.com for a while now. I hesitated because I didn’t want to lose all the data that has accumulated since I’ve been using maps.amung.us. While I was drawn to feedjit.com’s widget because I like the map better, it wasn’t enough to make me switch even though maps.amung.us hadn’t made a single improvement since I began using the widget ten months ago. However with this defect, there was nothing to lose by giving feedjit.com’s widget a try, and so I did.
The web changes everything. Now that so much software is offered for free, the barrier for switching vendors based on price is gone. Consequently, high quality is even more important when the barrier to switching vendors is nearly zero. Quality and useful features on the first delivery are a competitive advantage, and they are often more important to consumers than new/enhanced features delivered frequently. Incremental, frequent enhancements to satisfied customers is simply not required, but if you get your quality wrong or deliver the wrong features, you will lose customers — even formerly satisfied customers.
If you liked this essay, you may also like the following related posts.
It’s suggested that the web has changed everything. Whatever requirements there were for delivering desktop applications, the requirements for delivering web applications has changed.
For the web, the thinking goes; delivery of new features to customers is paramount to remain competitive. Maybe it’s true, but what’s the evidence? My own experience with popular web sites does not support this conclusion.
Agile doesn’t work in the real world is essentially the conclusion of David Starr, an Agile proponent, in his article “Why Agile Doesn’t Work.” First, he informs us of what is the primary objective of Agile software development methodologies:
Sure, TDD works, so does continuous integration, and a host of other great development practices. The truth is, though, that the real Agile value proposition was never about code. Better software with higher quality and excellent craftsmanship is a great side effect, but Agile is really about changing how products are created and delivered. Agile intends to fundamentally change the model of your relationships with clients and coworkers.
While reading a June 12, 2008 Time Magazine article “How He Did It,” an account of how Barack Obama came to win the Democratic nomination, it reminded me of the dynamics of a software project. Early in the Obama’s campaign near panic set in as Obama was drawing record crowds and record donations, but he still trailed Hillary Clinton by 20 points in the polls. Many in his campaign feared his approach to politicking would not get the job done. Obama’s “top moneymen were urging him to rethink his strategy, shake up his staff, go negative.”
and 
. She describes her Lean manufacturing experiences at 3M and how they relate to Agile Software development.
