Posts Tagged ‘Martin Fowler’

Fluency And Maturity

July 4, 2013 2 comments

After reading about Martin Fowler‘s “levels of agile fluency”, I decided to do a side-by-side exploration of his four levels of fluency with the famous (infamous?) five “levels of CMMI maturity“:

proces vs team

As you can easily deduce, the first difference that I noticed was that

The SEI focuses on the process. Fowler focuses on the team of people.

Next, I noticed:

To the SEI, “proactive” is good and “reactive” is bad. Proactive vs. reactive seems to be a “don’t care” to Fowler.

The SEI emphasizes the attainment of “control“. Fowler emphasizes the attainment of “business value“.

While writing this post, I really wanted to veer off into a rant demonizing the SEI list for being so mechanistically Newtonian. However, I stepped back, decided to take the high road, and formed the following meta-conclusion:

The SEI & Fowler lists aren’t necessarily diametrically opposed.

Perhaps the nine levels can be intelligently merged into a brilliant hybrid that balances both people and process (like the Boehm/Turner attempt).

What do you think? Is the side-by-side comparison fair, or is it an apple & oranges monstrosity?

A Blast From The Past

April 16, 2013 Leave a comment

In the 1980s, Ed Yourdon was very visible and influential in the software development industry. Arguably, Ed was the equivalent to what Martin Fowler is today – a high profile technical guru. Then at some point, it seemed like Mr. Yourdon disappeared off the face of the earth. He really didn’t vanish, but he’s much less visible now than he was back then. He’s actually making big bux serving as an expert witness in software disaster court cases.

Since I enjoyed Ed’s work on structured systems analysis/design (before the OO juggernaut took off) and I’ve read several of his articles and books over the years, I was delighted to discover this InfoQ interview: “Ed Yourdon on the State of Agile and Trends in IT“.

In the interview, Ed states that he’s asked many CIOs what “agile” means to them. Unsurprisingly, the vast majority of them said that it enabled developers to write software faster. Of course, there was no mention of the higher quality and/or the elevated espirit de corps that’s “supposed” to hitch a free ride on the agile gravy train.


Working Code Over Comprehensive Documentation

April 8, 2013 2 comments

Comprehensiveness is the enemy of comprehensibility – Martin Fowler

Martin’s quote may be the main reason why this preference was written into the Agile Manifesto

Working software over comprehensive documentation

Obviously, it doesn’t say “Working software and no documentation“. I’d bet my house that Martin and his fellow colleagues who conjured up the manifesto intentionally stuck the word “comprehensive” in there for a reason. And the reason is that “good” documentation reduces costs in both the short and long runs. In addition, check out what the Grade-ster has to say:

The code tells the story, but not the whole story – Grady Booch

Now that the context for this post has been set, I’d like to put in a plug for Simon Brown’s terrific work on the subject of lightweight software architecture documentation. In tribute to Simon, I decided to hoist a few of his slides that resonate with me.



Ad Hoc Docs

Note that the last graphic is my (and perhaps Simon’s?) way of promoting standardized UML-sketching for recording and communicating software architectures. Of course, if you don’t record and communicate your software architectures, then reading this post was a waste of your time; and I’m sorry for that.


Boulders And Pebbles

December 26, 2012 4 comments

When embarking on a Software Product Line (SPL) development, one of the first, far-reaching cost decisions to be tackled is the level of “granularity” of the component set. Obviously, you don’t want to develop one big, fat-ass, 5 million line monstrosity that has to have 1000s of lines changed/added/hacked for each customer “instantiation“. Gee, that’s probably how you operate now and why you’re tinkering with the idea of an SPL approach for the future.

On the other hand, you don’t want to build 1000s of 10K-line pieces that are a nightmare for composition, configuration, versioning and integration. For a given domain, there’s a “subjective” sweet spot somewhere between a behemoth 5M-line boulder and a basket of 10K-line pebbles. However, if you’re gonna err on one side or the other, err on the side of “bigger“:

…beware of overly fine-grained components, because too many components are hard to manage, especially when versioning rears its ugly head, hence “DLL hell.” – Martin Fowler (UML Distilled)

The primacy of system functions and system function groups allows a new member of the product line to be treated as the composition of a few dozen high-quality, high-confidence components that interact with each other in controlled, predictable ways as opposed to thousands of small units that must be regression tested with each new change. Assembly of large components without the need to retest at the lowest level of granularity for each new system is a critical key to making reuse work. – Brownsword/Clements (A Case Study In Successful Product Line Development)

SPL Granularity

Tell Me About The Failures

May 25, 2011 1 comment

As the world’s rising population becomes more and more dependent on software to preserve and enhance quality of life, efficiently solving software development problems has become big business. Thus, from the myriad of “agile” flavors to PSP/TSP, there are all kinds of light and heavyweight techniques, methods, and processes available to choose from.

Of course, the people who acquire fame and fortune selling these development process “solutions” seem to only publicize success stories. In each book, case study, lecture, or general article they create to promote their solution, they always cite one or two concrete examples of wild success that “validate” their assertions.

Besides the success stories, I, as a potential consumer of their product, want to hear about the failures. No large scale software development system is perfect and there are always failures, no? But why don’t the promoters expose the failures and the improvements made as a result of the lessons learned from those failures? Humbly providing this information could serve as a competitive differentiator, couldn’t it?

The difference between a methodologist and a terrorist is that you can negotiate with a terrorist – Martin Fowler

Bend It Like Fowler

August 22, 2009 10 comments

Remember the popular soccer movie “Bend It Like Beckham“? Well, I like to “Bend it like Fowler”. Martin Fowler, that is. In his terrific book UML Distilled, Martin recommends bending the UML when you need to communicate some application-specific design information and you’re not a UML language lawyer. Rather than leaving an important snippet of information out of your model because you don’t know how to capture it via a language formality, do whatever it takes to record it. It’s the stuff that falls through the cracks which causes downstream schedule delays and rework.

As a survivor of the structured analysis CASE (Computer-Aided Software Engineering) tools fad of the 80s, I’m leery of the expensive automated UML and SysML tools on the market today (Telelogic‘s Rhapsody and Artisan Studio come to mind). I think that both the UML and SysML are great languages for communicating a shared understanding of analysis and design information across a diverse team, but unlike general vector-based drawing tools (e.g. Microsoft Visio), language-specific tools are “handcuffers“. They usually require you to be a language lawyer and they force you to be syntactically and semantically correct or else your model won’t “compile“. Being goaded by a piece of software into spending a ton of time looking up and learning some obscure and arcane language detail when you’re under schedule pressure to produce output is not kool. I think that’s the reason why the 80s CASE tool push failed, and it may be why the UML/SysML tools won’t take hold (without coercion) in the mainstream now.

Bend It

Disclaimer: I’ve dabbled with, but haven’t actually used one of the big, formal UML/SysML tools on a “real” project, so I’m just pulling this stuff out of you-know-where. Thus, don’t believe a word I say 🙂 .

Categories: sysml, uml Tags: , , ,

The Beauty Of Quotes Is…

April 25, 2009 2 comments

that they are both dense and concise. When I hear a quote that hits close to home it rocks my world like a Mike Tyson power punch (when he was in his prime). Sometimes the effect is positive and sometimes it’s negative, but it’s always impactful. Here’s a top 10 list of my current favorites:

  1. “Nothing is impossible for the man who doesn’t have to do it himself.” – A. H. Weiler
  2. “An undefined problem has an infinite number of solutions.” – Robert A. Humphrey
  3. “A picture is worth a thousand words. A metaphor is worth a thousand pictures.” – Ben Tamari
  4. “Comprehensiveness is the enemy of comprehensibility.” – Martin Fowler
  5. “Creation is an intimate act of communication between the creator and the created.” – W. L. Livingston
  6. “Facts are useful because they give the conscious mind something to do while the emotions decide what’s true” – Dale Dauten
  7. “I hold great hopes for UML, which seems to offer a way to build products that integrate hardware and software, and that is an intrinsic part of development from design to implementation. But UML will fail if management won’t pay for quite extensive training, or toss the approach when panic reigns.” – Jack Gannsle
  8. “If I had an hour to save the world, I would spend 59 minutes defining the problem and one minute finding solutions” – Albert Einstein
  9. “I know that I am intelligent, because I know that I know nothing.” – Socrates
  10. “It is only by risking our persons from one hour to another that we live at all.” – William James

What’s your current favorite list?

%d bloggers like this: