Toadkillerdog's DogHouse

Our small group is starting a study of Donald Miller's book, Searching for God Knows What. It's an entirely engaging read in which Miller challenges the way you think about your faith rather than hitting you over the head with his. Hopefully, I'll have the ability and wherewithal to follow through on a chapter by chapter discussion as we talk about it.

Combat has often been described as lots of boredom followed by seconds of excitement. To bring that analogy into the project management world: projects are months of development followed by weeks of excitement, especially if you're still operating under the "driving blind" paradigm of software development.

The whole driving idea behind project management is to make it boring. You've all heard the aphorism along the lines of : "piss poor prior planning produces pathetic performance." The corollary to that is that good planning should, in the end, remove all panic. Good, up-front project management will reduce all the excitement produced in a project to as close to zero as possible. So, if you're bored on your current project, that's probably a good thing.

"Driving a project from bug data alone is like driving a car with your eyes closed and only turning the wheel when you hit something." - Sam Guckenheimer

I was reading Guckenheimer's book, Software Engineering with Microsoft Visual Studio Team System, (which he wrote with Juan Perez) when I stumbled across the above quote. It made me laugh...and then it made me think: he's really on to something here.

I can't count the number of projects with which I've been associated which, basically, do exactly as described above. It's almost cliché: hand off requirements, build code, release, fix bugs, done. How efficient is it to run a project, much less write code, when all you have to go by, metric-wise, are the defect count and the defect fixed count. And, more often than not, those are after you're already live with your code.

Hence, enter something like the Team System. It's not really all that new of an idea. It just bundles it all together in a nice neat automated package. And that last bit is key. As Guckenheimer goes on to discuss, we've spent a lot of years automating a whole host of business processes, but we've neglected our own internal processes...greatly to our detriment. Instead, as he points out, the best we can do is tack some automation around some intensely manual processes, which, as Guckenheimer says, leaves them still manual only now with overhead to maintain some clunky automation.

Now, with something like Team System, you can write your unit tests, enforce check-in build policies, enforce testing policies, enforce code coverage policies, enforce static analysis policies. If you want to report that your project is 100% bug free because on the last build, it passed all tests and you have 100% code coverage with those test, you can feel reasonably confident that you're correct. And, on top of all that, you have metrics: code churn, project velocity, scope creep, etc.

That's powerful. Now, instead of spending time and money (on average $500 per defect) on fixing bugs, you can spend time on tuning performance or enhancing an administrative interface or, heaven forbid, cleaning up the documentation.

I am, in no way, shape, or form, trying to look at this through rose-colored glasses. There are some significant hurdles and issues to using the Team System. However, that said, the ROI, just based on simple things like true source code control, branching and merging strategies, and defect management, should more than offset those (and I mean in terms of more than just money). And that doesn't even touch the project management and SDLC support baked into the product.

Of course, the difficult part is changing the culture to which the developers have become acculturated. They're comfortable, if uneasy and whiny, about the current state of affairs. Moving to something like this, i.e., process-driven SDLC, is going to shake some of them up. If you ask me, that's a good thing; because right now...the blind are leading the blind. But, as you well know, technical solutions are, at their base, people issues, so understanding the people becomes a critical component of encouraging adoption.

Here are some pictures of the Tartan Days parade held at Frontier Park in St. Charles, MO this past weekend.

MO Tartan Days 2008

Interesting 85 sentences....

"If the present Congress errs in too much talking, how can it
be otherwise in a body to which the people send 150 lawyers,
whose trade it is to question everything, yield nothing, & talk
by the hour? That 150 lawyers should do business together ought
not to be expected."

-- Thomas Jefferson

"Children should be educated and instructed in the principles
of freedom."

-- John Adams

"Let the American youth never forget, that they possess a
noble inheritance, bought by the toils, and sufferings, and
blood of their ancestors; and capacity, if wisely improved, and
faithfully guarded, of transmitting to their latest posterity
all the substantial blessings of life, the peaceful enjoyment of
liberty, property, religion, and independence."

-- Joseph Story (Commentaries on the Constitution, 1833)

“Friendship is unnecessary, like philosophy, like art. . . . It has no survival value; rather it is one of those things that gives value to survival.”
—C. S. Lewis, The Four Loves

Forgive me, since most of you probably won't care, but I found this too funny to pass up since, in one of my bible studies, we're explicitly discussing what it means to be a disciple:

"Disciple is an explicitly lazy dialect of Haskell which supports destructive update, computational effects, type directed field projections and some other useful things."

Haskell is a programming language, however, ignoring that for the moment, let me reconstruct that statement:

A disciple is explicitly lazy and supports destruction, overthinking, projecting, and other useful things.

Adequately describes the state of discipleship today, eh? Nothing like the discipleship as described in Matthew 5 & 6.

(you can read all about Haskell and the Disciple variant, if you're a masochist, on the wiki: http://www.haskell.org/haskellwiki/DDC)

These Berkeleyites are....well...the video pretty much says it all...

http://www.thedailyshow.com/video/index.jhtml?videoId=163653&title=marines-in-berkeley

My favorite part is when he asks the Code Pink chick about how great it would be if there was an institution dedicated to protecting that free speech…

So, I was watching TV yesterday, and I saw a commercial for Special K's new "Special K₂O Protein Water" product. It got me to wondering if the marketing guys who came up with it even knew if that was an actual compound, potassium oxide. My guess is going to be "no," because here's the ICSC for ingestion: "Sore throat. Burning sensation in the throat and chest. Shock or collapse."

Makes me want to run out and buy some right now.

(Yes, I know they didn't actually make it with potassium oxide...but, come one, do some homework.)

Writing from prison -

“These few words are being set down here as they come from my mind and my heart.  And if I must write them with my hands in chains, I find that much better than if my will were in chains.” 

and

"I can say from my own experience how painful life often is when one lives as a halfway Christian; it is more like vegetating than living."

"Society in every state is a blessing, but government, even in
its best state, is but a necessary evil; in its worst state an
intolerable one; for when we suffer or are exposed to the same
miseries by a government, which we might expect in a country
without government, our calamity is heightened by reflecting that
we furnish the means by which we suffer."

-- Thomas Paine (Common Sense, 1776)

I'd like to coin a new word, genericization, mostly because it's fun to say, but it's hard not to go back and try and correct that red squiggly line. Anyway, I didn't really want to talk about new words and automatic spell-checking. What I really want to expound upon is all this talk about innovation and how it occurs in the software development space.

Where I'm currently working, they have some weird calculation involving revenue and GP to measure innovation. I'm not, to be sure, exactly up on all the conceptual math behind it.... At any rate, the prevailing concept amongst the operational and business folks is that innovation should be done on the client's dime. Furthermore, such innovation should always be genericizable, i.e., applicable across all clients. What, apparently, gets lost in translation, is that converting a concept into a software-based process, given a reasonable set of requirements and under an always aggressive timeline, is a shaky proposition anyway. To expect development teams, especially immature or relatively new and unschooled teams, to think generically when they're feverishly working to implement specifically is akin to trying to find something that resembles a pin to stick back into the grenade...

And, of course, when that grenade explodes, all the buts start:

• "But why can't that whatchamacallit be used on my program?"
• "But you made that generic, why do I have to pay for customization?"
• "But I need it to work this way."

What I think most of the business folks aren't realizing is that they are the ones who own the domain. They own the concepts. Of course, translating the conceptual into the physical is one of the roles the architect plays. If you are the architect and you're heads down on specific delivery, i.e., client work,  you'll never have the chance to look around and truly learn the breadth and depth of a particular domain. Therefore, you'll rarely ever be able conceptualize it into something generic. And, you'll just be stuck re-inventing the wheel over and over.