I know where I want to go…are we there yet?

Standard

On the Creation of a Microsoft Clock

The Ballmer brainwashing quote has already gotten a bunch of attention, but I’m interested in the interview for a different reason than most folks:

[Ballmer] It’s going to take an innovative proposition. In five years are people really going to carry two devices? One device that is their communication device, one device that is music? There’s going to be a lot of opportunities to get back in that game. We want to be in that game. Expect to see announcements from us in that area in the next 12 months.

Yet another “just you wait, we’re going to totally change the rules of the game in n months” quote coming out of Microsoft. This one is just promising “announcements,” at least, but it’s part of a freakish, masochistic cycle that MS just can’t seem to escape. They’re pushing out a lot of good software and ideas these days, but there’s something in the Redmond water coolers that compels management to make big predictions about how soon things will happen, and how earth-shattering the impact of those things will be. In print. Repeatedly.

So in recognition Microsoft’s continuing commitment to trounce its competitors in any and all arenas, approximately 12 months from any given intervew date — in the face of a history of apparently insurmountable odds, no less — idle curiousity dictates that I start tracking this phenomenon.

When I get a few spare hours I’ll put together some code to track and display the data in some exciting, Web 2.0 fashion, but before that I’ll have to ask for the assistance of my loyal readers: if you come across any quotes…or rather when you come across quotes where an MS exec notes that the company will do something, release something, and/or 0wnz0r some market in a specific number of months, pass them along to me. And let your friends know, while you’re at it — the more data there is, the more fun there is for everyone.

del.icio.us or technorati tagging the articles with “msclock” would be ideal, but if you’re old school you can just email them to me.

Technorati Tagging:

Second ‘verse, same as the first…

Standard

Being Some Notes on Life

First Life
Genetics will out, it appears. My 15 month old daughter spent much of yesterday evening dancing in a goofy and uncoordinated fashion to the music of the Pixies and Johnny Cash, and then trying to grab the beer out of my hand between songs. I didn’t think she’d get there until some point in high school, at least.

Second Life
After a significant amount of prodding I’ve finally gotten around to checking out Second Life. Initial thoughts:

  1. It’s nice to see that there were other geeks writing up notes and diagrams as they read Snow Crash, too.

  2. My Second Life is eerily reminiscent of my First Life. To pick three items:
    • No matter what I try, my hair looks way geeky.

    • Having more and/or better memory would probably make Life run a lot more smoothly.
    • My conversations with unfamiliar people tend to trail off into awkward silence.
  3. I’m still trying to find enough hours to fit everything into my First Life.

Interesting, though. Fat bandwidth and improved graphics hardware/software are making [non-deterministic? open objective? experiential?] online environments more worthwhile — i.e. less like text-based chatrooms filled with stiff, bizarrely placed “avatars” jerking from place to place. (Sorry Hive7, for the moment you still fall into this unfortunate category.)

With the technology to capture, describe, and render the more subtle elements of offline communication (both verbal and non-verbal) still looking some ways off, will a programmable gesture-based language start to fill that gap? Has it happened already?

Technorati Tagging:     

Agile Business: just to be clear…

Standard

Since Scoble linked to it, this short post on an HP printer firmware development group getting a 3.4x productivity increase through Agile is likely to get some attention.

I’m in the process of writing about how even a Methodology skeptic can have lots of positive things to say about Agile…but even so, it worries me when I see stuff that appears to promise that Agile (or pretty much anything) will get rid of your gambling debts, quit smoking, be a friend, be a companion, and be the only product you will ever need.

I worry about seeing stuff like this because I have a (perhaps cynical) belief that some people will see these numbers and say something like: “Wow! We’ve got 45 projects that need to be done in the next 90 days, and right now we’re on track to only complete 1/3 of them…if we implement Agile processes and get a 3.4x increase in productivity, we’ll be able to get them all done plus some other shit, too! Alfred — bring me the Bat-phone!” And 90 days later there will be much wailing and gnashing of teeth, because Agile processes did not magically add more hours to the day, nor reduce the scope of those 45 projects.

Looking at the few HP numbers provided, the biggest points made are that were made were that the cycle duration decreased from 9 months to 2 months and that the amount of work in progress descreased 5x. And that, to me, doesn’t sound like Agile worked some magic — it sounds like HP did the smart thing: the didn’t try to work on everything at once, they figured out what the most important things for the company were right then, and they focused on getting those things done. Less work in progress at any given point in time — about 1/5 what they used to have — but the things that they are working on get done in…oddly enough, about 1/5 the time that it used to take.

And just to be clear: that’s an incredibly good thing and a huge achievement…it’s just not magic. It’s an achievement that comes from the company as a whole being willing and able to make some really hard decisions about what’s really important to their business.

Our regularly scheduled Agile series will resume shortly.



Lunchtime Musings: playsh

Standard

playsh, which is described as “a narrative-driven “object navigation” client, operating primarily on the semantic level, casting your hacking environment as a high-level, shell-based, social prototyping laboratory, a playground for recombinant network toys” is pretty retro-MUD-alicious, but it just doesn’t measure up when compared to the classic: doom as a system administration tool.

Technorati experiment:

Micro Persuasion: Institutional Power Declining, Forrester Says

Standard

Steve Rubel’s post on a new Forrester Research report. Very interesting, but “institutional power declining” seems to me like a debateable take-away. Check the logos in The Many forms Of Social Computing and consider how many of them either are Institutions or have been acquired by Institutions within the last year or two.

I’d propose something like “institutions realizing that they need to change the way that they exercise their power.” Hmmmm…maybe it’d actually be more accurate to suggest that a lot of people are sitting down, pulling out their dictionaries, and spending some time thinking about the simiarities, differences, and overlap between power, influence, and authority.

Technorati experiment:

Agile Business: The One True List

Standard

Being the first part of…oh, I don’t know…probably two or three posts over the next couple of weeks on the topic of “Agile” being worthwhile even if it is a “Software Development Methodology,” and also why it’s not really a development Methodology so much as it’s a business Methodology.

Matt has already posted a couple of times on Return Path’s adoption of an agile methodology in a variety of areas, so it’s probably time for me to weigh in. Here it is:

Overall, I’ve been happy with we’ve gotten out of using this methodology.

Now before people start rummaging through my basement in search of Whitney-sized cocoons, let me make a statement for the record: in many cases the phrase “did I tell you that we’ve adopted a new software development methodology?” still makes me as uncomfortable as phrases like “hey, did I tell you that I got syphilis last weekend?” and “no, no, it’s totally not a cult — why don’t you come by the compound tonight so that the Leader can explain it all to you?”

Has everyone processed that statement and continued reading down to this sentence before sending me a “you can’t be serious about buying into some bullshit capital-M Methodology” email? No, I didn’t think so. Oh, well, don’t worry about it. I expected those emails, you punks.

Anyway, why don’t you all sit down, make yourselves comfortable, and read on. Here — do you want a cup of this excellent Kool Aid? Let me tell you about this “one true list” deal…

The One True List of Things to Do
This is a big factor for me. Huge, actually. I’m sure that many of you, whether or not you work in technology, are familiar with the corporate ritual of “the splitting of the list.” In the case of software development it usually works something like this:

After reviewing the list of projects that need to get done and the technical resources available to work on projects, a company finds that there’s no possible way to get everything on that list done. So the project list is split into two sub-lists, with separate business people responsible for the tasks on each of the new lists. Those people, in turn, then split their lists in sub-lists, delegating responsibility for each resulting list to a different person; the process continues until you have approximately 214 business people holding short but critical-to-them to-do lists — and 98% of those people are justifiably pissed off because they can’t understand why the fuck tech can’t accomplish the two simple things that are on their to-do list in a timely fashion. Great.

Following an agile approach you can avoid a lot of this: you have one list of stuff that you’re going to be working on for the next few weeks. I’ll happily admit that doing this isn’t as easy as saying it, and that we (Return Path) are still spending a reasonable chunk of time making sure that the list is and remains the one true list, but having a defined <shudder>methodology</shudder> actually helps here. You’ve got a process that everyone can understand. For lack of a better metaphor, you’ve set your rules of engagement, and everyone can either accept those rules or get gunned down like dogs in the street. Metaphorically speaking, of course.

This does mean that you’ve got a potentially difficult meeting every couple of weeks, where the people with juice need to agree on what’s going to get done and what’s not, but…well, at the end of that meeting you’ve come to some sort of agreement; as conflict-averse as I am, I’d much rather have a heated argument leading to (sometimes grudging) consensus about what needs to be done than have smiles, flowers, and puppy dogs leading to N different understandings of the priorities.

And now we come to the part of the post that I probably shouldn’t write. I really want to be able to take at least partial credit for “Engineering productivity [being] way up,” but there’s a dirty little secret hidden in the agile approach.

You see, even if you’re putting in a lot of time and effort to do the agile thing effectively, your Engineering folks probably aren’t accomplishing much more than they would be otherwise. It may seem like more is getting done, but that’s because a strange and wonderful thing has happened: your newfound agility hasn’t added more people to your team, or more hours to the day, it’s just helped you spend more time on the things that you as a company have decided are the big concerns for you right now. Interesting, huh?

More anon. And one of the issues to follow in a later post is addressing the issue of “we’ve been doing the agile thing, okay, and it sucks ass in cases where the scope of the project falls outside of an (iteration|release), so you can bite me, agile boy,” so you just keep your pants on and don’t send me email about that one, okay?

Eh. Who am I kidding? Go ahead and send those emails. Punks.