Make the Implicit Explicit

I broke one of my own suggestions for doing software better last week: always make the implicit explicit. As with most large companies,
we’re spending time
integrating our product with other products. To further that along, we
branched mainline to do the first cut of integrating with a new
framework, an internal SDK.

Of course, with most large integration efforts, it’s expected that
things will be broken for awhile and that we’ll need to fix all the
broken integration points before working on the new features. So, at
the beginning of this week, we happily merged the branch back into
mainline. And, of course, many things are broken: they need to be
converted to the new framework.

However, everyone in the team wasn’t expecting this broken-ness to
the degree that we (the branch people) thought acceptable. Thus, after
having merged everything in, there was a collective “uh…everything
is broken” type of response.

We’d just assumed everyone would know, and be ready, for that. It
was implicit in the whole process (to us, at least). What we
should have done is make it extremely explicit before we merged back
in.

Anyhow, lesson learned…yet again ;>

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s