Wednesday, February 28, 2007

insert snappy title about reading here

I like to read though I seem to have less and less time to do so. Yet inevitably when I find something that catches my interest I manage to finish it. (if it really catches my interest, my wife comments on how much time I've spent in the bathroom recently.)

After having it recommended awhile back by a good friend, I've plowed through about 3/4 of It's Your Ship: Management Techniques from the Best Damn Ship in the Navy in a blistering 3 days.

(I could have gone faster, but the legs go numb...)

It rocks. Seriously. While it's simple, (seemingly) common sense stuff I almost found myself crying (that's right - real bona fide aqueous duct activity) over how much this guy "gets it". Kinda like Peopleware for the Navy. And as the captain of the ship, this guy practiced what he preached. And had the authority to implement. Found creative ways around, over and (sometimes) through the rather moribund Navel hierarchy.

Go read it.

And then scratch your head and ask "if this guy got such exceptional performance out of 'the averagest'...how does it apply to software development and the tech sector in general?"

"How does it apply to me as a leader/parent?"

"How does it apply to me as an aspiring developer?"

"It's got to be a kick to write software that controls those Phalanx CIWS systems.."

cheers!

When is "the right way" too much?

It feels good when you know stuff. And knowing "stuff" lets you get things done.

Case in point: the manager of the group I've been lent to needs some metrics for the performance of the app his group has care-and-feeding responsibilities for. The metrics are available on an existing series of web pages...formatted in a nice table.

Unfortunately, said format does not lend itself to data analysis. And he (the manager) as an old sql slinger wants it in a format he can analyze. (preferably excel...of course)

As a proof-of-concept I whipped up a batch script using wget and sed to determine if it was possible. (and work out the regex kinks) This took about 1.5 hours.

(I was happy...given that I think I've used sed maybe once before. The thorniest part was figuring out the differences in command line syntax/quoting between all the sed tutorials and the gnu-for-windows version of sed..)

After verifying the data was useful, I wrapped the functionality (using C#'s native regex capability) into a nice little windows form app. Two hours later, I had an excel spreadsheet with snazzy pivot table. Data source when "updated" looks in the default location that the forms app dumps the csv. Time, about 2 hours.

This was a quick one off app that'll be used by one person, 1-2x/month, but I did get to thinking what I would do to make it "more robust". To wit:

csv file
overwrites existing (no option to overwrite/append/rename/etc)
filesystem space check (is there enough space?)
filesystem directory check (exception if specified directory doesn't exist)

metrics http source
no specification of server or source page (if it changes, the path'll probably change)
somewhat brittle regex I'm guessing
no handling of "if the server goes away" (.net exception)

architecture
downloads whole whack of data each and every time (but only takes about 30 sec...seemed a good tradeoff)

But...all those things considered...I wouldn't change it given my requirements. The user was very happy. It's something that's used infrequently. It's unobtrusive and quick.

Does it make the user happy? Yes. Does the solution raise them to a higher plane of consciousness? No. I think it's probably more along the lines of "hey, I couldn't get this data before. I can now do it in 30 seconds." The solution got out of the way of what the guy wanted to do - namely, analyze performance metrics.

I'm happy. He's happy.

Life is good.

Wednesday, February 21, 2007

Inspiration provided free...

Alas I am not the inspiring one, but like a true master (uhh...yeah) I try point you to those who can and do inspire.

Seven steps to remarkable customer service
Joel blogged a bit on customer service. It was nothing earth shattering for him...just the usual humorous, insightful, dead-on-target truth. And some funny bits about New York locksmiths and delis.

What tail is wagging the "user happiness" dog?
Kathy Sierra's witty and entertaining insight on who wags whom. (with some unapologetically snarky remarks on six sigma. Mmmm...)

Guy Kawasaki - Ten questions with Michael Raynor.
Micahel wrote The Stragegy Paradox. And while it asks smart questions and gives very gristly answers (gristly = answers with grist to chew on) it doesn't fall into the "follow me, I've found the truth!" trap. From Guy's intro:

I don’t know about you, but there are many companies that succeed, and I can’t figure out why. And there are also many companies that fail (some of which I invested in), and I can’t figure out why.

This book goes a long way in explaining how strategy makes or breaks a company. To put it another way, I won’t think I’m so smart if a company that I invest in succeeds, and I won’t think I’m so dumb if it tanks.

Monday, February 12, 2007

Management by ROI

Or "Management By the Numbers". It's quick, it's easy, no fuss and no muss!

Please note, I'm all for understanding if what you're doing is adding value (or not). However, it does seem that:

0.) It's always and forever all about $$.
1.) Walstreet shareholder-driven managers are often terminally shortsighted when it comes to value
2.) Value is always equated to money, and quick money at that (see #1). No mention of customer goodwill (unless it immediately translates to cashflow. This quarter.) Little beyond lip service for much beyond the next three quarters.

No mention of a company's higher mission/purpose. (assuming it has one)

Jim Collins/Jerry Porras Built to Last has a great bit in it where all the execs of Boeing were sitting around a table discussing the upcoming (I think) 747 project. It was to be a revolutionary project. A huge gamble. What Collins/Porras called a BHAG. (Big Hairy Audacious Goal).

One of the execs asked if they had figures on the ROI.

The response? Essentially "We're not sure."

The exec was incredulious. "Then why would you do it?!!"

"Because we are Boeing. This is what we do."

(Notice a pointed lack of any words relating to "maximizing shareholder value".)

Seems that the pendulum has swung far, far too far into the territory of: “Hey, this management thing isn’t so hard! Just calculate the ROI and if it’s not high enough don’t do it! If anyone calls you on it, you've got numbers to back you up!” Make the most cash possible. And CYA while you're at it.

No insight. No gambles. No spirit. Just dull plodding along to make money. (geez...I think I've just slipped into "diatribe against The Man" territory...)

As with any organic organization, that attitude rolls down...down...down to the downtrodden Rodney Dangerfield of the corporate set, IT. Like a whimpering puppy, IT wants to please it's master and show that I'm good enough, I'm nice enough, and doggone it people LIKE me!

"Validate me!" IT cries to each and every customer. "You use me every day, I try and cater to your every whim, yet still you fume and stomp when email isn't delivered on time. Well...so tell me how much it's worth to you to get your Blond Joke -o- the Day delivered to Outlook on time?!! How much money did you save by getting to your files this morning? I resolved your help ticket and got your MSN communicator working in record speed - that adds bucks to our bottom line, right?"

Gotta track those numbers. Translate everything to dollar signs. Metrics to show how fast email is delivered, tickets resolved speedily and servers humming with uptime.

Metrics are all good and well…but can we really reduce the art of management and leadership to number crunching and CYA justifications?

Even as clueless as I often am, I know there’s more to good management then that.

In a fit of pique awhile back, my mind drifted into an alternate (but not too alternate) universe...

***************************

[helpdesk:]“Hello, This is the helpdesk”

[caller:]“This is Stan from payroll. Our file server is down.”

[hd:]“Hmm…Stan, I see from our metrics that you’re utilization of the server is only at 18.732%. That corresponds to a space costs us approximately $386.62/month.”

[caller:]“Umm..ooohh kaaay. When will it be back up?”

[hd:]“Well sir, according to our tracked metrics and ROI calculation, you obviously don’t need the space that bad.”

[caller:]“WTF?!! We USE that file space!”

[hd:]“I completely understand sir. However, IT now has to justify all our resources to the CIO and CFO. If an asset’s usage falls below a certain point it’s determined that the resource isn’t contributing enough to the bottom line."

[caller:]“Wha? But… Ho… What am I going to do now? That server had figures I need!”

[hd:]“Well sir, we do have one alternative. Can you tell me how much they’re worth?”

[caller:]“What?!”

[hd:]“How much they’re worth.”

[caller:]“Worth?!! They’re worth a LOT! I can’t do my JOB without them!!”

[hd:]“Ah sir, I wouldn’t use that argument. After all, your job is an expense on the balance sheet. If the only consequence of losing the data is you losing your job, that’s…well…that’s an easy win for IT metrics. We look good, because we've just reduced expenses and all that. Just between you and me I’d try a different tack…”

[caller:]

[hd:]“If we can put a $$ figure on the data, I can put forth a request to have the server brought online. Of course, you’ll want to estimate high as the techs are only authorized to expend 80% of their cost time in the recovery effort.”

[caller:]“80 percent…uh…ok....”

[hd:]“Oh, and you’ll need to show your calculations. It’s a new SOX requirement. Transparency and accountability and all that.”

[caller:]“……..”

[hd:]“Sir..? Sir….?”

Wednesday, February 07, 2007

Test Driving Test Driven Development

Ask and ye shall receive. Kvetch and ye shall be hit upside the head with a wet fish.

(something like that)

Anyway, as I've been bemoaning my lack of insight into how really to effectively utilize unit tests beyond the simplest things, what do I find but a wonderful tutorial on exactly that!

(http://www.testdriven.com/modules/newbb/viewtopic.php?topic_id=4375&forum=6 )

Gishu, by his own admission, started to write a 10 page "How to do Test Driven Development" in response to the whiners who said "it can't be done!"

(more specifically, "You can't really do TDD with a UI app".)

"Phiffle", cried Gishu. (I'm taking literary licence here) "Indeed it can!"

And lo and behold his 10 pager grew into a 200 page document that walks the newbie through his stream-of-consiousness development of a complete UI app and it's attendant tests. And not just dry "this is the principle" stuff, we get to see the nitty gritty code, laugh as he muses tradeoffs, and weep as his unit tests go from red to green.

I'm about 17 pages into it, and I'm loving it. The scales are falling from my eyes. The heavens are opening up and angels are singing. I'm spontaneously dropping into lotus and humming the almighty "om......."

No, really. Or maybe it's just the lack of caffine in my bloodstream. Or the koolaid I drank. Whatever.

It's written informally, but that just keeps my brain engaged.

Thank you Gishu!!!!! Kudos!