Archive for June, 2009
I attended Ken’s ScrumMaster ™ course over the last two days. Possibly more on that later, but for not I want to focus on something entirely different. People are just very incredibly decent when it comes right down to it.
Ken has an absolution jar in the center of the room to catch the $1 owed for being late back to your table or for cussing in the course. Each day a charity is chosen that has a connection to somebody in the room for the money to go to afterward. On Monday, I mentioned that I ran Dan Shi Martial Arts club, and it was selected as Monday’s charity. By the end of the day the jar held $21, and I took $20 of it to deposit as an anonymous donation. Awesome idea, and thank you everybody!
Tuesday morning I thanked everybody during the morning agenda for sharing their sins with the needy, and commented that they’d sponsored a single student for a single month, which is hugely appreciated. At some point during the day, people must have talked it around, because around 3pm Ken tapped me on the shoulder and told me that the group had collectively decided to send Tuesday’s money Dan Shi’s way as well… THANK YOU!
Around 4:45 I straightened up the money because I was having problems putting my dollar in for being late back from break. I counted ~$30 at that point. At 5:15 I collected the money, and found EIGHTY THREE DOLLARS in the mug. Everybody, thank you! That is hugely significant to an unfunded organization, and we thank you very very much.
You have collectively allowed us to sponsor a child for almost half a year. Thank you. You are all awesome, and it just reminds again that no matter how much we may disagree, argue, or bicker professionally, every single individual is first and foremost a person doing the best they can do.
You have what Chris Matts calls an “Order Taker” as your business analyst. This individual is occasionally your only access to the people that actually understand what’s needed, yet they’ve been positioned as the gatekeepers of knowledge.
Consider this tactic
Combine “The 5 Why’s” and “Feature Injection” and see if you can deduce the real information that led to a specific requirement or change.
The thing is, the person the BA is talking to likely does Feature Injection, even if they don’t know they’re doing it. They’ve created their mental model (or “understanding”) of what problems this software they’ve asked for will solve. Something comes along and breaks the model (or “Doesn’t quite match what we’re doing”), and they change the model (or “submit a change request”).
If you look at the outputs of this (the delta, or the specific change), you’ll observe that they probably share a common theme or two. If you keep asking “why” on the changes, you’ll accomplish two things. You’ll be able to understand what sort of learning occurred, and the further “why’s” will either lead to better answers (less “telephone” effect) or more questions for the actual business owner. Second, you’ll probably frustrate the hell out of the order taking BA, and there’s a tiny chance they’ll learn to act differently.
Either way, you probably understand the intent of the changes better, which means you can do a better job providing value.
btw, please please please try and fix the organizational structure first, but if you can’t do so, then you can begin finding the right ways to work around the impediments.
In the process of debugging an issue with a sample web application, I was forced to learn a bit more about IIS7′s management model, and I found some very valuable information.
The problem: the user my request was running as did not have ACL-level access to the .svc file for that web service.
My old solution: Try random accounts before giving up and just giving access to "Everyone" for the entire web tree. (Yes, bad, but it’s a sample)
My hope: There is a way to find out via logs, console, etc what the actual user is based on the actual failure rather than looking at all security configurations and randomly trying the referenced accounts.
What I found:
Open IIS manager, click at the web site level, and choose "Failed Request Tracing Rules"
On the right, choose "Edit Site Tracing…"
Check "Enable", and note the location of the log files (note, there are implications on production sites. I don’t know what they are. Be warned.)
Now, click "Add…" on the right, and choose your settings:
When you finish, you’ll see something like this:
At this point, you can go to your logs folder and see the XML results of any errors that match your filters:
Opening one of those applies a nice transform (freb.xsl, I assume), and we have our data:
Including my answer:
And lots of other cool information:
And a summary view:
Including some really useful information that I would usually try to get out of Fiddler2 because of the challenge in collecting it in some configurations: