Rediscovering the Obvious

9:15pm, sitting outside, listening to the birds, working on the computer, drinking a beer, and generally enjoying the evening.  Oh, and reflecting on a VERY successful Team System SIG.  I saw a few people I knew, met a few new people, got to help some people, learned a few things, and generally was able to experience the evening. I’d like to put a special thanks out to Paul Hacker for making it happen… he’s making a difference.

Microsoft yet again has provided a formatting option to fit the way I work.

Tools, options, Text editor, C#, Formatting, Wrapping.

I unchecked both options, and now when I hit ctrl-K, ctrl-D it does what I want it to… breaking {} statements up to their individual lines per coding standard. 

Well, having tried the free Xceed data grid for a while, and not being fully pleased, I’m going to give Infragistics control a try. They’ve released the XamDataGrid for free (link currently broken?), and also put out a promotional on their full suite for MSDN subscribers for only $199 a seat.

My biggest concerns at this point will be their support responsiveness, especially as concerns their forums, as I’ve struggled with them before. Their controls are generally among the best looking, but I’ve often found it a struggle to get their controls to behave exactly as desired. First glance at the WPF suite seems to show significant improvement in this regards, but we’ll see how they respond to specific challenges.

The last of a very good series of posts at http://feeds.feedburner.com/~r/2-speed/~3/117149909/ inspired me a little bit in how metrics and data in general should be presented.

Consider the two Churchill quotes he presents, only substitute the word “specification” (or requirements doc, etc) for “report”:

“This specification, by its very length, defends itself against being read.”
“Please be good enough to put your conclusions and recommendations on one sheet of paper in the very beginning of your specification, so I can even consider reading it”

How many of us, in our roles as developers and architects, have begun designing and even implementing a system without having even READ the entire spec? Why does an author expect somebody to read, understand, and recall thousands of “The system shall foo the bar of the blaz” statements over a period of many months? I know that I’ve typically gained my most important understandings of a system from listening to stakeholders explain WHY they want something, and from looking at powerpoint presentations that give the overview of what the system should do. I’ve long asked for “bullet point requirements” to do initial estimates and planning on. The most accurate bid I’ve made was off a very short request for quote, but we had very skilled domain experts on-hand to lay it out.

That said, what’s the value of having the spec “up front”?

Argument 1: Scope management

This is the one I hear the most… “how else do we know how big something is?”  I usually counter with “How does 1500 detailed requirements tell you how big something is?”

Argument 2: It helps prevent changes/churn

Embrace it! I’ve not seen a large spec with less than 20% churn anyway.

Argument 3: The [ FDA | FAA | DOD | CMMI | DVL ] made me do it

Do they? Or is that just the default assumption from a casual reading of the process/model descriptions? Thanks David Anderson for opening our eyes to the possibility of time-shifting these needs to a JIT approach… yay for throughput.  For more on this, I highly recommend reading Anderson’s blog and the Lean Software Engineering Blog, which extends many of the concepts related to Anderson’s work.

Actually, it’s a complaint with the interface to source control in the Solution Explorer. I’m doing some basic shifts of the deployment structure… moving classes around between assemblies, etc, and it seems that none of the drag-and-drop options will actually do a source control “move” operation (which preserves history), they all do a delete/add (which is poor engineering practice because it drops history).

 Well, off to explicit-land… what a pain.
 

http://phacker.wordpress.com/2007/05/02/new-team-system-sig-in-indianapolis/

That’s right – a special interest group, IN INDY, dedicated to team system (and by extension, team foundation)  This could be very good. Way to go, Paul!
 

I never thought so, but then I realized I had five years to understand the justifications behind them. To me, they’ve become one of the common, core aspects of unit testing, and they always would have stayed that way until I started considering how to introduce them as part of a basic Unit Test training approach.  I’m trying to bring one of the guys on my team up to speed on unit testing theory and practice… starting from near zero.  This is a challenge, both for myself and for the gentleman in question.

As always, the result of teaching is a better understanding of how things work, and tonight I can much better articulate interface-based programming (and testing), inheritance, serialization, events, inner classes, Stimulus / response behavioral testing, the model/view/presenter design pattern, and the factory design pattern…. all because of a 60 minute lecture/lesson.

Empowering, enlightening, and so much damn fun!  [Shameless plug: Anybody that gets all this stuff want a job?]