Quote of the Day

Watch where the footpaths go before you lay down the sidewalks.

Grooks

By way of Tim Berners-Lee, I found this wonderful collection of Grooks by Piet Hein. They have a wonderfully whimsical character, like this one:

BUDGETING: THE FIRST LAW 

If you want to know
where your money went,
you must spend it quickly
before it's spent. 

Great Quote

Darren Hobbs: Agile Answers

Developing incrementally does not (in my opinion) mean taking your brain out before starting.

What happens when you don't "get it"

PragDave

Without exception, these early attempts at imitation failed: the car companies replicated what they saw Toyota doing, but only on the surface. They didn't really understand what was behind these practices. It was like trying to become an artist by copying the angle and velocity of the brush held by a master.

You see this happen often with various "agile" practices, like test driven development, XP, or Scrum. If all of the participants don't grok the practice, then they blindly execute a series of steps, and say, "See. It didn't work!"

There are two possible resolutions to this problem.

You can tighten up the process. Unfortunately, if you didn't "get it" in the first place, you are likely to cause more harm than good. At its pathological extreme, your team works like the staff of a McDonald's, with each person following a carefully prescribed methodology. If you are building the software equivalent of a Big Mac, then this might be perfect for you.

You can invest in your people. The old saw about giving a man a fish versus teaching him to fish applies here. For even the most simple project, it is nearly impossible to prescribe everything. At some point, personal judgement has to kick in, therefore it makes sense to equip the team with the mental tools needed to make the right decisions.

I don't mean to "dis" process, but I think you reach a point of diminishing returns, with "process improvement" whereas "people improvement" will always pay off handsomely.

Design by Contract is trademarked!

I was reading this article called Contract Programming 101, when I ran into this little gem:

Note: the term Design By Contract was trademarked in 2003 by Dr. Meyer, so all the little free software pixies are dropping the term like a hot coal. The latest favoured term is Contract Programming, as suggested by Walter Bright in 2004 and used in the recent proposal by Thorsten Ottosen and Lawrence Crowl to the C++ standards body.

That is not cool!

Index Cards

Extreme Programming has this strong tradition of using index cards to track user stories, or to aid in design through the use of CRC cards.

Now, I have always had a strong preference for Excel spreadsheets.  You can print them, e-mail them, share them, and save them.

But there is something wonderful in the very nature of index cards.  Their very constraints create interesting feedback loops.  Think of all the objections that you might have against them:

Index cards are too easy to lose.

Yes – but why are you writing anything important on an index card in the first place?   At the end of the day, the only important work product is the code.  Requirements and any other models exist to facilitate conversations about the code.  If you have been writing tests along the way, when the coding is done, the requirements don’t need to exist anymore.  The requirements aren’t sacred.  The only thing that is sacred, the desires of your users, cannot be captured in any format, but must be discovered through a constant dialog.

Index cards are too bulky.

If you have more index cares than you can manage, then your user stories are either too fine grained or your scope is too ambitious.  Either way, the cards are telling you that you need to change.

This is a pet peeve of mine.  Quite often, when you are doing the wrong thing, it will be difficult.  The correct solution is not to make it easier to do the wrong thing, but to change what you were doing in the first place.  

Only one person can “own” an index card at a time.

So what?  Distributed ownership is the worst thing that can happen in project management.  If everyone owns a task, then no one is really responsible for carrying it out.  

Having said all that, I am still mulling over the use of index cards in my process, and have started collecting links about index cards in del.icio.us.

Holistic thinking is disruptive

In the November issue of the Atlantic Monthly, there was a brief article about the heuristics used by the US intelligence community to detect spies.

They may also take a "holistic view of world affairs" that could lead them to believe espionage is "morally justifiable."

You can read this any number of ways, and I won't debate the ethics of making decisions to support particular policies of this adminstration in spite of common sense (or holistic thinking) telling you otherwise.

But I would like to touch briefly on his this might affect your organization. When it exceeds a certain size, every organization begets a hierarchy of departments. While the organization, as a whole, might wish to move in one direction, each department has its own incentives, which sometimes contradict the organization's larger goals.

In such a world, to think holistically is to think about disruption, as any move to re-align the departments with the organization's goals will result in disruption to that department's practices.

Behavior Driven Development

I recently read an interesting paper by Dave Astels, entitled A New Look at Test-Driven Development, which suggested that Test Driven Design is overly focused on testing, which gets in the way of reaping the true benefits of TDD.

I agree that using the word “test” when describing TDD definitely gets in the way, when explaining it to other people.  Management asks, “Why are we hiring testers if developers will be writing tests?”  Developers ask, “Why should I write unit tests for code that will get tested by the (manual or automatic) acceptance tests?”  And so on.  You get the usual objections to TDD.

So I am down with giving TDD another name, but what threw me was the suggestion that we ought not to use the word “test” when actually writing the tests.

In Behavior Driven Development, tests are called “specifications.”  Fixtures are called “contexts.”  And instead of assert, one would say “should.”  (Dave’s essay has examples of their usage.)

Initially, I was fairly dismissive of what seemed like a cosmetic change, but I decided to give it a go for the past week.  Here is what I found.

I wrote more, smaller test fixtures.  Whereas I used to write test fixtures with names, like CustomerFixture, I found myself creating many little contexts, with names like CustomerWithOverdueBill or CustomerWithoutAddress.  

I wrote more asserts per test.  Each test started with a particular context, invoked a particular operation in that context, and then verified the expected resulting context.  That verification often took multiple asserts.

The tests naturally had better names.  In the past, when writing tests for a Customer class, I might have tests with names like testSetAddress.  Now, I find myself thinking in terms of scenarios, so that the CustomerWithoutAddress context might have a specification like settingAddressForFirstTimeSendsNotifcation.

In summary, this change in perspective has proven extremely useful, so I am sticking with it.

Could You Pass 8th Grade Math?

You Passed 8th Grade Math

Congratulations, you got 10/10 correct!

Could You Pass 8th Grade Math?

Planarity.net

A way cool game that tests your facility with spacial relationships:

Planarity.net

Are iterations hazardous to your project?

Are iterations hazardous to your project?: "That surprise experience helped open my eyes to why 'iterations' may be hazardous to your project: Danger grows when the results of the iteration are not directly linked to delivering the product to the end user. Without that linkage, iteration results hang in the air just as badly as the old, pre-agile forms of wandering in the wilderness."

This could be filed under the general heading of "Don't let the process become the goal," which is a disease that strikes nearly every organization.

Here is how it happens:

Management wants feedback that the team is making progress towards a particular goal, so they add instrumentation to the process to gather metrics. The team responds by trying to improve those metrics. If management chooses the wrong metrics, the end effect is that they drive the team away from its goals, rather than towards them.

I think that all of Alistair's observations and recommendations are dead-on.

Laziness Driven Design

I have become fanatical about writing unit tests for every method on every class, regardless of how trivial that method first appears. ( "But it's just a getter!" )

This leads to an interesting laziness driven feedback loop. Here's what happens:

I am implementing a feature, and think that the shortest distance between two points, is to add another dependency onto one of my classes, but then I realize that this new dependency would further complicate all of my tests, requiring large changes. Ugh! I don't have time for sweeping changes to my test suite.

So, in my laziness, I skip over the initial, obvious solution, think a little bit harder, and come up with a truly simpler solution.

The PO-STAR Movement

In the past year, I have seen an increasing number of "Plain Old *" abbreviations:

• POJO - Plain Old Java Objects
• POCO - Plain Old CLR (.NET runtime) Objects
• POX - Plain Old XML

At this point, I think it qualifies as a crypto-movement, and the clue to the genesis of this movement is in Andy Smith's "Why Frameworks Suck."

Frameworks hurt sharing. I’d really like to give you this fork Jimmy, but you’re gonna need a knife and plate to use it.

The alternative to PO* is to buy into some framework, which inevitably prevents code reuse as your classes become riddled with framework junk.

You know a library is really a framework when:

• It requires you to derive your classes from some library class.
• It requires you to use their main() function.
• It requires you to use their Application class.
• It requires your classes to depend on some third party library.
• The setup() and teardown() methods of your test suites become really complex.

Nearly every time that I have written framework-like functionality into an application, I have found that I was able to factor it out in favor of simple library classes that are themselves PO* objects.

I Heart Python

I have been playing around with Python at home, developing a simple web application, and I just wanted to say that I think that Python is awesome.

Fear of the Domain Model

Did you ever notice that many programmer's tend to shy away from developing a domain model?

This is a pretty reasonable reaction. We want to exploit our strengths, and leave the domain to the domain experts. We want to continue to improve our knowledge of computer technology, because this translates into a personal asset.

I think that the ability to elicit domain knowledge from a domain expert and convert this into a viable domain model is a more important skill than the knowing the latest technology that your tools vendor is trying to push at your CIO.

A rich domain model is truly fertile ground for developing applications, and building working, valuable applications is way more important than extending one's knowledge of the solution domain.

The Garden

Originally uploaded by Jennifer Dunne.

This is picture of a flower in my wife's garden.

Thoughtless Interfaces

Here is a great write-up on how to not create an interface: IFoo as Foo's interface is evil and should be punished.

It's all about responsibilities, people!

Toothpaste

Originally uploaded by Jennifer Dunne.

My wife took these wonderful pictures of toothpaste, which had quietly extruded itself from the tube in the middle of the night.

Trust is an essential deliverable

From Exploration Through Example:

Sometimes teams are jumping into Agile to avoid the horror of the previous release. The code was too buggy, or too late, or cost too much per feature, or all three. In such a case, the programmer team is probably not trusted by the business people. If so, trust is an essential deliverable. It's not enough to be better; you have to be visibly better soon. Delivering tested, working features at frequent intervals is a key way to get trust back. Another way is close cooperation with a product owner that demonstrates that the team's orientation is toward helping her meet her goals. But more generally, the team should pay active attention to how well they're doing at building trust, not just at building code.

A Perfect Recipe for a SOA Failure

From SOA is a Business-Driven Architectural Style:

"It means that for SOA to be successful, it must be a 'top-down' approach. And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure. "

I will go a bit further and say that any architecture that isn't bent on solving a particular problem is a recipe for failure.