Recovering from corrupted perf counters

Don’t know if any of you have ever had this happen to you or not, but it paniced me a bit when it happened to me. I opened up perfmon, and instead of nice names of counters and categories, I had nothing but numbers in their place. The last thing I wanted to do was to have to rebuild my VPC, so I really wanted a way to fix this.

Google Is Your Friend

Google led me here, where another gentleman, ScanIAm, had the same problem. He posted about it on that forum, and eventually found his answer. If you look at message at the end of that thread, he posts his solution:

 1) KB300956 this will clear you out.
2) To fix .Net performance counters Click Here
3) To fix Asp.Net performance counters, head to your c:winntMicrosoft.netframeworkv1.1.4322 path and type:  lodctr aspnet_perf.ini

I did just what he said, and everything came back perfectly. I had been seeing a strange exception while trying to run installutil on one of my assemblies, which started this whole slide into perf-counter-hell. But this post brought me back, and I’m very happy to say it all works again!

I hope this helps someone else out there someday as much as it helped me.

— bab

 

What Makes a Good War Room?

If you could design your own war room for a software team, what would be in it? I’m talking about the kind of stuff that a company can provide, not the soft stuff like candy, etc. Here are my choices:

A shared, isolated space

Teams need a shared space to work, but they need to be isolated from everything else. All folks involved with the project need to be welcome in the war room, but no one not on the project should be in there. The buzz of relevant conversations is a good thing — the noise of irrelevant conversations is distracting.

Pairing Stations

Whether you pair program or not, you need tables that will allow you to pair when needed. This means desks that are wide enough for two people to comfortably sit side-by-side. This explicitly does not mean those horrible corner tables that fit into cubes. Those need to be banned.

I prefer the tables to be arranged such that you can see the other people on your team, rather than all sitting in a row. I think that keeps the overhead of spontaneous conversations as low as possible.

White boards

A team should have a white board that all members can gather around. You shouldn’t have to reach over anything to use this white board. It should also be large enough for a good conversations. And it should be erased often.

Unencumbered wall space

Teams need to be able to hang up Information Radiators along their walls. This includes stories and tasks, burn-down charts, and any other information radiator that is needed. Corkboards work well for some of this, as do giant stick pads. You also need a blank, white wall to act as a projector screen.

Speaker Phone

So team can take team-wide calls right there in the team room

Comfortable chairs

We sit all day. We should have nice chairs.

Have I left anything out? Please let me know.

— bab

Agile Speaking

I was asked by the local VB.Net User Group to give a talk on Agile Development. The problem with giving a talk like this is that there are so many possible things to cover in the time allotted. And I never know what kind of background the folks showing up will have.

So, if I explain this in another way, I have a specific time in which my talk has to fit, I have a specific amount of resources to deliver the talk (me!), and my requirements are unclear. This sure sounds like most agile software projects! What I’ve done now twice in a situation like this is to let the talk itself become an example of agility. I walk in with an idea about the subjects I want to cover. For example, last night it was

  • What are Agility and Extreme Programming
  • How do they work
  • What is a programmer’s life like
  • How do we adopt it

When I walk in, I give a short intro talking about how I they are my customers, I am their value-giver (developer), and my goal is to give them the most value for their next hour of time. We discuss how I am going to run the talk as if it is a software project, and we proceed to brainstorm for what questions, or features, I can answer for them in the next hour.

They brainstormed way more questions than I could answer in the time given, so we had a quick conversation about prioritizing based on business value. Then I gave them a quick estimate of about 2 minutes per question and told them that I was breaking the talk up into 10 minute releases or iterations. So we chose our top 5 questions from the first line in the list above, and we started off.

At the end of ten minutes, I  had answered 3 of the questions, which led into a quick discussion of planning and feedback. I told them that I could now promise them 3 questions every 10 minutes, since that’s the progress we had measured, and I had them pick out their next 3 questions to get answered. It turned out I answered 4 questions this iteration, with one being really short and quick in the final minute.

We did one more iteration after that, followed by a wrapup discussion of how the talk was planned and executed and related that back to a software project.

I’ve found that this is a good way for me to give a talk when I’m not sure of my audience. It lets me tailor the talk as we go to exactly what they’d like to hear, and prevents me from giving the wrong talk to the wrong group, which I’ve done before

— bab

The Delta Lounge V2

Enterprise Library V2 is starting up, and we’re having problems getting traction. Scott Densmore, Mani, and I are the only holdovers from the original project, and we’ve picked up a new tester, Gokul (I know I spelled this wrong — sorry!) and two new developers, Brad Wilson and Fernando Simonazzi. In short, we’re basically starting over from a team point of view. And I get the sense that we’ve been thrashing the past couple of weeks, because we’re still trying to understand all kinds of different things. We are trying to get a handle on our requirements. We’re trying to bring Brad and Fernando up to speed on the codebase. We’re trying to define the exact feature set that we want to deliver, and we have a very aggressive timeline. Lots of things working against us. And this stress was making me feel bad.

It was making me feel so bad that I sought out Peter Provost, whose opinion I respect trememdously, and I talked to him about it. I was feeling the pain of us not having formed into a team yet. Peter, with his usual wisdom, reminded me that we were still very early in the project, and that the original Enterprise Library team went through growing pains orders of magnitude worse. He advised me to give it time. Not a lot to go on, but I still felt a bit better.

Now, the one thing that we have going for us is that we all want to work together, in the same room, at the same time, as much as humanly possible. We’re doing everything we can to find a war room in which we can work. We have this shared belief and desire to all sit together, developers and programmers, and learn from each other, get to know each other. Events are conspiring against us, as we keep losing rooms to the CRCC (Conference Room Conversion Committee), but we keep fighting. We found a new room to work in this week, and we didn’t pass up the opportunity to squat there. And as the week went on, sure enough, Peter’s advice was right (I hate it when that happens!). As we went from Tuesday when I showed up, to Friday when I left, I felt the beginnings of a team forming. I convinced/nagged Scott to move his laptop into the shared room, Fernando and Brad started getting up to speed and began to feel more comfortable asking for help, and everyone helped me with a sticky design issue I was facing. I monopolized most of the team’s time over the past couple of days, whining about the feature I’m working on. I’m clearly thrashing on it, because I don’t know how to start, where I’m going, or how to get there. But, you know what, because everyone was there in the room, and they had (been forced) listened to all the design conversations I’ve been begging for, a design came out today that everyone is happy with. I could not have done it alone. Period.

Working in this war room brought us together as a team, allowed us to make more progress than we would have individually, and provided me with the support system I so desperately needed.

— bab

The Power of the War Room

I was just reading an article in Fast Company. The theme of this issue was “Design”, and the first article in there was about designing workspaces for knowledge workers. The article was written from the point of view of the author as she was writing the article, in a shared work area, with all kinds of interruptions going on around her. Every now and then in the text, she’d add an aside about how someone just came up to her to ask a question, or she’d mention that she overheard some conversation going on a few desks over. It was breaking her concentration, and preventing her from working as efficiently as possible.

Cut to my group at Microsoft today. We’ve just started working on Enterprise Library V2, and Scott Densmore and I, along with our tester Mani, are the only carry-overs from the first release. We’re essentially starting the team building process all over again. This means that we have to get all the new folks up to speed on how Enterprise Library works internally, and we have to begin to learn to work together as a team. We also get to have lots of design discussions, ask for, receive, and give help, and get to know each other. I prompted a conversation today about whether or not we were getting value from our standup meetings in the morning, and the general consensus was that everyone was getting more value out of just being together in a room all the time than from the meeting itself. Working in a war room, in the opinion of everyone in the room, was the deciding factor in helping us to go faster.

So, what is the difference between these two situations? I believe the difference is that we are acting as a team, whereas the author was acting alone. (Pretty obvious conclusion, eh? I amaze myself sometimes :)) The sole practitioner, thrown into a room with other sole operators, is lost in the white noise of all the conversations. One who belongs to a team revels in that same white noise, as that noise is the shared knowledge floating around the room.

My real point (I actually do have one) is that I believe this is why it is difficult for agile teams to convince management to give them a war room. Very few of the people who we must ask for such a room have ever lived the shared work experience. One kind of person that we must beg for that shared space is a facilities/HR/admin kind of person who has no first hand knowledge of how we work. In their experience, software people want their own offices and private spaces, because that’s how we work. We come in, put our headphones on, and pound on the keyboard all day long, never talking to anyone. That’s the stereotype, right? The other type of person we have to cajole is someone who used to work as described above, but has gotten promoted out of that role into management. From their own personal experience, they wanted their personal space, and they want to do good for their people. So they want to get them those private offices or cubes. In both cases, I believe the ones being asked are acting in the what they perceive to be the programmers’ best interests, since that’s how programmers have worked for eons. They just don’t know.

We have to take it upon ourselves to educate them. We have to speak up about how war rooms help us do our job better. We have to write articles, we have to invite our bosses into our war rooms, we have to blog about our experiences. We have to get the word out, so that our bosses will begin to offer us the open workspace that we crave so badly.

The fault is not theirs — the fault is ours. It is we who have changed, in our work habits, in our space desires. We have to communicate that to the world at large so that they will learn that programmers have emerged from their cocoons^h^h^h^h^h^h^hcubicles and are ready to work together.

— bab