FrazzledDad

Handy WinForm Dialog Box Error Trick

2008-08-05T05:32:00.001-05:00

You may not have realized it, but you can quickly copy error messages off WinForms dialog boxes with Ctrl-C. You'll get something like this below:

---------------------------
My Dialog's Title/Caption
---------------------------
My Dialog's message text
---------------------------
OK (List of buttons here)
---------------------------

This makes it quick to copy error messages into bug reports.

(Not that I've ever written a single line of code with a bug in it, mind you. I'm just saying.)

Looking for Java Work? We're Looking for You.

2008-07-30T09:48:00.001-05:00

Quick Solutions, the great company I work for, has a significant number of openings for sharp folks in the Java domain. We're looking for folks at all skills levels, so we'd be happy to talk with you regardless of whether you're a senior architect or a passionate newcomer.

All slots are in the Columbus, Ohio, area.

Feel free to contact me via the link on the sidebar if you have any questions.

The Importance of a Mentor

2008-07-28T23:26:00.001-05:00

Mentors are an awfully important part of one's growth in any aspect of your life: personal, professional, community. I've been lucky to have a number of solid mentors during different phases of my life, some of whom I didn't realize were performing that role until years later as I looked back in reflection.

I strongly believe a good mentor is a critical part of your success in your professional life. A good mentor acts as a calm, wise advisor who can help you unmask some of your weaknesses, then help you discover a roadmap to fill those gaps. All of this can happen on many levels: communications, technical, business sense, etc.

A good mentor's an invaluable asset when you're in over your head with something, or in a situation where you're having problems finding the way out. A mentor's been there, done that, and has the scars to prove it. Because they're not right in the middle of your problem, and because they've likely experienced similar messes before, a mentor can help you discover new options which you weren't able to see. Sometimes it's as simple as pointing out to you that you can call clunky sections of code written by your team mates "technical debt" instead of "badly written poo." The latter gets someone's hackles up; the former acknowledges that success was achieved, but with a less-than-optimal piece of code which needs refactoring in order to move forward.

Looking back I realize my best mentors never spoon fed me. I remember vividly one Sergeant during my time flying on big radar planes: "You're not a teapot that I'm going to pour knowledge in to. You need to do the work." That man's words (and some other choice ones when I screwed up) have stuck with me for a long time.

One of the reasons I joined Quick Solutions was to work under and be mentored by Brian; however, he moved on to a great job, leaving me with some thinking work to do regarding how to find a new mentor. I'm at a spot on the relatively flat hierarchy at Quick where there's nobody above me suitable a technical mentor. Sales and business development? Covered in spades. Someone to help me further my technical growth and vision? Not so much.

It's taken me a bit of time to work through thinking this out, but I've come to realize that I need to morph my concept of mentoring. I need a fundamental shift to something akin to distributed mentoring. Heck, splitting work into distributed components works great for software, why not for mentoring?

Not surprisingly, my short list of technical mentors is made up from the groups I'm closely tied to and passionate about: peers at Quick Solutions and peers in the regional developer community. I'm blessed with being in the middle of two groups where I'm not even close to being the smartest guy in the room. I'm blessed with being in the middle of two groups whose excitement, passion, and vastly differing viewpoints lift me up when I'm stuck in a funk.

I don't want to specifically list out the folks I consider as mentors (you may not return my calls or IMs anymore), but I wanted to write about the mentor shift I'd come around to.

It may work, it may not. I'll re-evaluate where I'm at in four to six months and let you know.

Save The Date! 20 Sept: .NET University in Columbus, Ohio

2008-07-28T05:50:00.001-05:00

Jeff Blankenburg and a few other community folks are scrambling around trying to get a .NET University organized for 20 September. Time and venue are still being nailed down, but it will be held somewhere in the Columbus area.

.NET University events are like mini-Code Camps, but are targeted at newcomers to the .NET platform. Code Camps tend to dive into 300 and 400 level topics. .NET U is much more introductory, focusing on fundamental 100 and 200 level concepts.

More details to follow!

Paying off Technical Debt Versus Completing Features

2008-07-22T04:58:00.001-05:00

I hate technical debt. Kludgy code, architectural things which looked good then but look like poo now, overly complex or "tricky" sections of a system. Maybe even low test coverage metrics or shallow tests which get good coverage metrics during stats runs but perhaps don't fully exercise the system.

Technical debt should be paid off as you continue to work on your system, but sometimes, for whatever reasons, we make other choices, skip paying debt down, and let it accumulate as we continue. This can make a big mess when we hibernate a project for awhile, then attempt to quickly pick things up again at a later point, perhaps even with a set of different folks working on the project.

I just finished up a third phase of a project (third-and-a-half, depending on how you look at it) which has been going in fits and jumps since last April. The latest phase on the project was to finish up some custom security infrastructure we developed for the client.

The client had a very small bucket of money for this phase and wasn't going to be able to get all the features she needed completed. She had enough money for 135 hours of feature development, and her total need was about 210. Without those 210 she couldn't move on to her global deployment phase, but hours are hours are hours and we don't fudge or cover up the amount of work. We're completely open with our clients which is awfully important for building long-term relationships.

Well, it turns out that Phil and I kicked butt on the work and completed the 135 hours in amazingly short order. Now I was at a decision point: pay off some of the technical debt that had accumulated over the entire lifecycle of the project, or push forward with feature development in order to get the system to a point where the client could deploy it?

I spent several commute trips mulling this over (a long commute gives me a lot of time to mull things over...) and decided to press forward with feature hours instead of paying down debt. It's not a choice I'm overly happy with, but neither option would have left me 100% satisfied. Why did I make that particular choice in this instance? Several factors.

First, risk. My main target for debt paydown would have been the persistence architecture I inherited when I took over the project. It's overly reliant on static goo and is overly complex. Testing of that code during refactoring? Time consuming, even though it's absolutely worthwhile. The persistence bits work and are fairly sound as written, it's just hard to extend for future use. It makes no sense to do such major rework this late in the game, particularly since I'm all over YAGNI and it looks like there isn't much more extension needed in the near future.

The next target would have been some WinForms code littered with goo because we did a bad job of enforcing MVPness early on. I've been slowly refactoring out pieces of that, but it's slow going. Again, this is a risky section since getting things decoupled and moved out to better separation impacts a lot of different functionality. Increased regression testing would have been required by the QA folks, and they didn't have a lot of time available.

Decision for these problem areas? Leave them and move on.

Second, client needs. The client doesn't understand a hooting thing about how our implementation of NHibernate tracks sessions, uses too many static calls, or loads its configuration. She doesn't know about MVP patterns enabling better testing and separation of concerns, easing testing and extensibility. The client only knows she has a need to deploy the system in a few months, and she can't do it without the full security stack in place.

Decision for this issue? Leave the debt in place, enable the client to hit her latest goals -- in part because we all as a team (us + client) had missed some earlier goals.

The client's now on track to hit her goals, and she's much happier where she's at. I'm happy that she's going to meet business needs with this latest delivery; after all, we need to deliver value to the customer. Obviously I'm bittersweet about having missed an opportunity to clean up past technical debt. At least I can console myself in that I added no new technical debt to this phase of the work.

Would I do it again? Highly, highly doubtful. This situation was pretty unique, and the victory I got may have been a bit Pyrrhic in that we'll still need to pay off that debt if we get any sort of follow on work.

(By the way, do not confuse me as putting forth features over stable code. That's not what I've been saying at all. Technical debt is, to me, an issue different than the stability of what you're writing now.)

(And more by the way, we completed 252 feature hours on her budget of 135 feature hours. Our velocity chart kicks ass!)

Troubleshooting 101

2008-07-16T21:48:00.001-05:00

Troubleshooting and/or debugging is a large part of our job as geeks. Bad code, misbehaving apps, finicky servers, we have to juggle all that and more. Trying to wade through complex systems is never fun, particularly when you're under stress for a delivery or trying to get a production server back up.

I've had a number of years' experience troubleshooting different systems, both hardware and software. I do not claim to be a troubleshooting ninja, but I've picked up a number of solid lessons learned over time. This post won't be an in-depth treatise on using the debugger or some obscure tools, rather its on more high-level approaches to help cut your churn.

First off, get serious and go buy a copy of David Agans' Debugging. This book distills Agans' amazing skills into a highly readable, awesome guide. Everything I have to say pales in comparison. Go, buy it right now. I'll wait.

Now that you've ordered that book (and gotten me at least $0.07 in referral fees from Amazon.com, thanks) here are some things I find highly useful for my approach to troubleshooting. The items aren't listed in any particular order, just a stream of consciousness. Let's start off with two things which require an incredible amount of self-discipline.

TIMEBOXING

Time box your efforts, right from the start. Time boxing is perhaps the hardest thing for us geeks to deal with. "Just five more minutes and I know I'll find the answer!" Yeah, you said that yesterday morning, dumbass, and now it's 4:30pm the day before delivery. (That would be me, talking to me.)

It sounds silly, but get yourself an egg timer. Honestly. The first step you take before doing anything in a non-trivial problem should be to set yourself a time box. "I will work on this data transfer issue for no more than one hour before stepping back and reassessing." Work until that timer goes off and then stop! Step back, re-evaluate the problem, and look for someone to bounce your assumptions and theories off of.

STEP BACK, REASSESS, ASK FOR HELP

Sometimes you can get yourself wrapped around too many red herrings and lose sight of the forest for the trees, to mix metaphors in a really ugly way. You have to discipline yourself to take a break from the issue, then come back to it and look at things again. Our office has a hallway that runs in a loop around it. Now folks who work in the office with me may know why I wander that hallway on frequent occasions mumbling like some deranged bag lady.

When you get back from that break, look over your your forensic evidence you've gathered, the assumptions you've made, and any bits you've managed to wicker out about the problem.

Asking for help is uncool. Folks will begin to know how big a putz I really am if I ask for help. No, they won't, at least they won't if you've made some basic effort before reaching out. You may not need anything more than a body to repeat your problem statement and assumptions to.

Some book I read at some point had a funny story about a high-level dev in a shop who was plagued by folks busting in to his office to get his advice on problems they'd obviously not thought out first. The constant interruptions crushed his productivity on tasks he was responsible, and the other devs didn't grow their own skills. The lead took to putting a stuffed bear in a chair in his office. Devs would come in to his office and his first comment to them would be "Tell it to the bear." The devs, simply by verbally stating the problem, their assumptions, and theories, would often solve the problem themselves. Not that I'm telling you to go get a bear and start talking to it at work, but you get the idea. Bounce ideas off someone, even if it's someone outside your domain.

RTFM

M as in Messages. Error messages. Dialog boxes. Log files. Console output. Read them carefully. If it's late at night or after a long session, consider re-writing the messages out on paper. Seriously. I can't count the number of hours I've lost because I blew over a message and let my (bad) assumptions con me into reading something the message didn't say.

A good buddy told me he made one of his mentorees read error boxes to him aloud and verbatim. Prior to that the mentoree had a bad habit of not taking initial steps himself, or not catching important details which were clearly displayed on the screen in front of him. A couple weeks of reading those messages aloud finally kicked the mentoree into taking more initial action himself. (My pal's much more patient than I. I'd have lost it after a couple days of trying to prod the guy into doing that...)

THE RULE OF HALVES RULES

Look at your system as a pipe of data. Break that system into halves. Probe at the halfway point and figure out if your data is good or bad at that point. Continue breaking the remainder in half until you isolate something you can get your hands around.

DRIVE THE SYSTEM WITH TESTS, NOT UI

It doesn't matter if you do test driven development or not. Use tests (integration, unit, whatever) to drive your system as you're narrowing down the problem. Don't waste your time trying to input data to a web form and try to catch data on the other side. Write an integration or unit test to stimulate parts of your system and work from there. You're locking down valid areas of the system while beginning to isolate the part that's borked. You get the added benefit of deepening your coverage of the system. (I'm not talking just code coverage here, but effective testing of your code. Two different things.)

WRITE IT DOWN

I use the Jot function of SlickRun as a scratch pad for writing down bits and pieces of more problematic problems I'm having problems with. Use a whiteboard. Lay out the pipeline of the system and break it in half. Note your inputs, outputs, and areas of concern. Visualizing a problematic system can be a great help.

MAKE A PLAN

This is last, but it's likely the third-most important tip next to time boxing and stepping back. Don't just jump into code or whip open a telnet session to your misbehaving server. Take a moment to look at your assumptions once more and figure out a plan of attack. Write it down or verbalize it to see if your plan's a solid one:

"OK, so the object coming across the wire from the server to the client is borked when it's saved. It's showing client local time instead of server time. I will cut the data pipe in half and start looking at the data on the client side of the web service. I'll check to see if the correct server time is coming in the data transfer object. If that's correct then I've isolated it to client side. If it's not I'll go look at the server side and go from there. I'll do that first check by writing an integration test to call the web service and get one of the DTOs and validate its timestamp."

LOOK TO THE SIMPLE STUFF FIRST

Assumptions are a tricky thing. You need to make some assumptions as you begin chasing the issue, but you may have made wrong ones and may end up chasing a red herring. Look to the simple answers before diving into the deep end. The simple solutions are the right fix 87.682% of the time.

If you are spending hours discussing minutia of timestamp comparisons and getting into the bowels of a widely used framework like NHibernate then you are likely on the wrong path. If your first thought is that your OutOfMemoryException errors are caused by a service pack bug instead of a code change, maybe you should look back over the history of that module you just updated. (That would have been me, chasing a herring for an hour last week instead of noticing that a colleague had updated how a namespace was handled in a call to XmlDocument.CreateElement -- at my vague direction. Yeesh.)

TIMEBOX, AVOID BURNOUT

Time boxing is so important I've listed it twice. Avoid letting yourself get too frustrated over a problem. Take a walk, go get some fresh air. Shoot nerf bullets at your co-workers. If you're working next to a colleague who's been churning for some time then show them some love and get them to take a break.

Simple, but critical.

IN SUMMARY...

None of these things I've written down here are rocket science. You're likely doing all these and more, so please feel free to comment with things you find helpful, or resources you've found useful when trying to improve your troubleshooting skills.

UPDATE:

Jeff Hunsaker pointed out one of the most elementary things which I'm shocked I missed:

WHAT CHANGED?

Take a few minutes and look over what in your system changed since the bug/problem/issue appeared. Look over the code history. Look over the data. Look over the environment your system's running in. Something's likely changed, but you need to be realistic and careful about going too far down a rabbit hole. See that part about "Look to the Simplest Stuff First" above.

Another Great Open Source Mind Joins Microsoft

2008-07-16T05:15:00.001-05:00

Hamilton Verissimo, founder of the Castle Project with all its amazing goodness, will be joining Microsoft as a PM for the Managed Extensibility Framework. As Hamilton notes in his blogpost, MS is allowing him to continue his work on Castle. That's awfully, awfully cool!

This is another sign of the slow, terrific changes afoot at Microsoft. We need to be honest in our (valid!) criticisms of Microsoft, but we also need to be honest and give them props where they're due. Picking up folks like Hamilton, Phil, and others from the open source community ensures the positive changes at MS continue to move in the right directions. Pulling in folks like this ensures that certain mindsets in MS will continue to be changed for the better.

Very, very cool. Congrats, Hammett!

(BTW, Hamilton wrote a great article on the Castle bits for James's and my book.)

Votes of No Confidence, Voting With Your Feet, or Putting Too Much Faith in False Prophets

2008-07-07T23:33:00.001-05:00

I am so tired of hearing the hyperbole coming out of some folks in the .NET community who are far too wrapped up in themselves. Yeah, Bellware, I'm talking about you and your ilk. [1]

I'm tired of seeing all Microsoft described as morally corrupt, or covering their asses, or whatever overly broad, hyperbolic evil empire phrase of the day the fanatics want to throw out. There is no doubt that some less than helpful folks exist in the corners of Microsoft, but can you honestly throw out those sorts of silly accusations and paint the entire company with the same broad stroke? Can you give concrete evidence that the company is driven by nefarious goals without any effort inside the company to right past wrongs? Can you honestly look me straight in the face and make those claims, instead of admitting that there are a tiny few intransigents in Microsoft who are not signing on to some very fundamental, amazing, positive changes the company is making as a whole?

No?

Then STFU, calm down, and get an honest, civil discourse going again. Leave off the self-aggrandizement, the condescending manifestos, and the attacks. Start up a conversation with folks like the MVC team, who are actively pulling in community input. Look up the folks at Microsoft like Sara Ford and the CodePlex geeks who are trying to empower the community. Work with the evangelists like Drew Robbins and Jason Olson who are driving content to be more real world. Hook up with the Visual Studio team who spent hours picking the brains of MVPs at the summit in an attempt to figure out how best to get community input to drive Visual Studio's feature set.

Does that sound like a bunch of dishonest, evil-minded folks? Not in my mind. (No clue how to try and get this same level of involvement from the Entity Framework folks. I tried in one "open spaces" session at the MVP summit and was stunned by the EF guy ignoring what I and several others were telling him.)

And oh, by the way, I'm always happy to offer up my own criticism of Microsoft when they're due it. See my comments here, or a separate post on my blog here.

Why am I so beaked about all this? I'm tired of the many, MANY good folks at Microsoft being slandered. Yeah, I used that word deliberately. I'm also tired of being condescended to or outright attacked by a very small group of folks who seem to think I and other geeks can't evaluate things and make intelligent decisions on our own. Do I need some pompous manifesto to tell me that NHibernate is better than the Entity Framework? NO! I need rational, detailed discussion on the topic.

Unfortunately, rational discussion seems too far a stretch. Bellware once even wrote a blog post demeaning folks choosing certain Microsoft technologies as performing "Dependent Driven Design" because they hostage to paying family bills and therefore making design choices to benefit Microsoft sales and pad their own pockets. I'd point you to his blog post on that topic, but Bellware deleted his entire blog because he was narked about something. Yeah, that's a mature thing to do.

If you are outside this entire train wreck of an argument and are reading some of these overly zealous conversations then you need to step back and consider what the goal of these one-way rants are. Do folks who spread this hyperbole honestly expect that it will solve anything? Is this utter lack of respect how these folks treat those who have differing viewpoints?

Maybe Bellware and the other folks spewing poison should follow a fundamental tenet of Open Space conferences: Vote With Your Feet.

If those few hyperbolic folks honestly feel that Microsoft is a corrupt, evil, morally bankrupt entity then they should have the courage to live up to the standards they profess and go find work in a different domain. Go off and write Ruby on the LAMP platform. There are a bunch of amazingly cool cats in that area. Why not go hit some Java work instead of .NET? There are a bunch of wicked smart folks in that domain, too. Are those folks still holding their MVP awards from Microsoft? Give 'em up, dudes, and let pass the related business networks (read "increased pipeline and/or salary") that goes along with that award, otherwise you're beholden and corrupt yourself. (I don't really think that, but you see my point.)

Let me be crystal clear on something: I am in awe of the technical chops of Bellware. That man passed more brilliant ideas through his lower intestines last week than I will have the rest of the year. He's brilliant in engineering and design, he's clued in on philosophy (and not just software), and it sounds like he's all over the right kind of processes. I'm just sick of prima donnas. I put up with this kind of crap during the many years I spent busting my ass to get great at competitive volleyball while watching all the folks with amazing natural talent spend more effort snarking and deriding others instead of working to lift up the team. That sucks and it's one of the few things I get really, really pissed about. (Plus Bellware called me an "arbitrary dick" on Twitter and he hurt my feelings so there.)

So what's the point of this long, somewhat rambling post? Has Jim gone further around the bend than some of the zealots? No, I'm just hoping someone who is trying to make a rational decision about various things from Microsoft may stumble across my blog before running in to the EF VONC or some other similarly toned rant.

[1] Do not for one moment think I lump all Alt.NET folks or Entity Framework Vote of No Confidence signatories together as one group of zealots. I'm talking about a tiny subset of this group.

UPDATE: To be clear. Bellware didn't just delete one ranting blog post, he deleted his entire blog. That really sucks, because he had a lot of great stuff in there.

NHibernate Entities Not Loading ID Values When Read From The DB

2008-07-07T10:16:00.001-05:00

Problem: Your entities aren't loading up their ID properties when you do a find/read/whatever. Other values for the entities load fine, but not the IDs.

Answer: Check the casing of your properties in your business objects and your mapping files.

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" 
                   default-access="field.camelcase">
<id column="groupid" name="GroupID" >
  <generator class ="identity" />
</id>

Note the disconnect between the "default-access" attrib of the mapping element and the naming convention in id element's "name" attrib. Ooops. Either change the default-access or the casing of the name attrib:

<id column="groupid" name="GroupId" >
  <generator class ="identity" />
</id>

More on naming strategies in the NHib dox.

New Book: Agile Adoption Patterns

2008-07-02T22:55:00.001-05:00

I got a copy of Amr Elssamadisy's Agile Adoption Patterns in the mail today. I'm excited to have received this for two reasons. 0) I loves me some Agile, B) I was one of several technical reviewers of this book, Finally) it's a well-done book. (Yes, I said two and that's three. It's been one of those days and I'm relaxing with a lovely bit of Caol Ila Islay Scotch as I write this. Gimme a break.)

Elssamadisy's book is in tough, tough company. How can you compete in the same space as amazing works like Subramaniam and Hunt's Practices of an Agile Developer or Shore and Warden's The Art of Agile Development? Those are tough, tough classics to go against when trying to explain how teams/companies should adopt agile practices.

Amr pulls it off by organizing his material in a fresh form which I found very useful. He hits many of the same points as other works on Agile (smells, process, team empowerment, practices, etc.), but emphasizes the business value of each point. For example, his chapter on User Story lays out the case that user stories are simple documents in their initial draft. The value comes from developers having conversations to flesh out the details and implementation of the story. Product utility is improved, and development costs are reduced.

This same approach is carried on throughout the book, making it very clear what specific benefits you can find from each practice. Additionally, each practice or chapter follows a nice recipe-like format. Start off with business value, move on to a sketch describing the practice, follow up with context of the practice and forces impacting it, then look to why you'd want the particular practice, adoption details, and a bit on the practice's cons and variations.

The book starts out with a high-level overview of agile, then moves on to specific patterns/practices. Each pattern is a short, separate chapter with about 40 patterns in total. The style of the book is clear, concise, and it's nicely produced.

Another great point about the book is Elssamadisy's ongoing assertion that you don't need to adopt all of the practices. Rather, find the pain points you have in your environment and look to implement only the patterns which will ease that pain. This pragmatic approach to agile adoption is a refreshing view in a world where some Agile fanatics insist you must adopt every single practice or you're not doing Agile. (A fanaticism I emphatically disagree with.)

Overall I think it's a solid addition to the Agile section of your bookshelf. It's not a replacement for things like Subramaniam's or Shore's works; it's a solid addition to them.

Of course, I'm somewhat biased, having been a tech reviewer on it...

CodeReviews Using SlickEdit Tools

2008-06-25T21:13:00.001-05:00

The guys at SlickEdit make a great set of tools for devs, both standalone and VS plugins. Scott Hackett wrote a really interesting post on using SlickEdit to do a code review. It's a pretty good read and shows a nice way to use the tools to help narrow down who wrote what code.

There are a number of ways to skin the code review cat; this is a nice option and worth the read.

(Reminder disclaimer: I got SlickEdit tools for free because they advertise on The Lounge. I wrote about my thoughts on SlickEdit in an earlier post.)

Virtual Server Admin Page Error 400

2008-06-25T12:15:00.001-05:00

Problem: The Virtual Server admin page (:1024/VirtualServer/VSWebApp.exe">http://<hostname>:1024/VirtualServer/VSWebApp.exe?) on a multi-homed host system isn't accessible if one network card goes down. You get lovely HTTP Error 400 pages.

Solution: Check that the IIS Virtual Server site isn't bound to one specific network adapter. IIS manager -> Web Sites -> Virtual Server -> Properties ->IP Address. You can bind the site to one specific IP address, or simply select "(All Unassigned)" in which case you're not dependent on one NIC.

Yay.

404.3 Errors for WCF Services

2008-06-24T14:17:00.001-05:00

Today I ran into 404.3 errors when trying to hit a .svc file on my recently re-imaged system. I beat my head against my console chasing IIS setup configuration, directory rights, and a number of other things.

Finally I ran across David Waddleton's post detailing a solution. Whew. Back moving forward again.

Culture, Productivity, Environment

2008-06-24T12:20:00.001-05:00

I'm re-reading a few of my favorite older blog posts and reading a few new ones. A couple great articles are worth passing on links to:

Steve McConnell's Measuring Productivity of Individual Programmers. Avoid stupidity like lines of code, and don't focus on just one measurement.
Steve McConnell's How to Scale Up Quickly. Offshoring doesn't work, keeping the quality is terribly difficult, keeping the culture even harder.
Joel Spolskey's The 12 Steps to Better Code. Way back in 2000, just after Al Gore invented and implemented the Internet, Joel wrote a nice post on things some folks were already discussing. Critical things for you and your team.
Scott Hanselman's Sharpen the Saw for Developers. Getting management support for ongoing training at a consulting company can be like pulling teeth. With a tow cable. Look to Scott's post for some good ideas he's invented and consolidated from other places.
All of Sara Ford's Tip of the Day and Did you know... series. I read 'em all again just now. No, really.
Josh Holmes's series on good presentations.

There you go. Just a few of my favorites.

Book Review: C# In Depth

2008-06-22T05:46:00.001-05:00

C# in Depth by Jon Skeet, pub. Manning Press, ISBN 1933988363.

This book is a tremendous work for understanding how the most important features of the C# language work. Skeet's been a prolific poster in the C# forums on MSDN for some years now, providing answers, tips and tricks, and in-depth advice to a large number of forum visitors. This book wraps up his great knowledge of the inner workings of C# and hands it over to readers in a well-written, concise, usable book.

Skeet uses a very nice formula for the features of C# 2 and 3: he starts with demonstrating solutions to practical problems in C# 1 then shows the progression of that same solution through C# 2 and C# 3. His walk through of the evolution of delegates through 1, 2, and 3 is a perfect example of this: start with the very wordy, somewhat clunky handling in C# 1 and end up with C# 3's lamba expressions.

One of the many fine things about this book is Skeet's ability to clearly cover complex topics like Lambdas and expression trees at exactly the right level. Readers will be able to pick up the power, complexity, and benefits of language features because Skeet's kept the examples practical and the text conversational. With potentially complex topics it's too easy for authors to fall into trivial examples, or dive into overly academic discussions; Skeet does neither. He also does a terrific job of covering the cons of particular issues -- something I'm a big fan of since it helps me make informed decisions.

Part of the book's success is Skeet's solid focus on the book's topics. He stays directed on to language features and doesn't digress into software engineering or construction. As a result, in roughly 360 concise pages he's able to hit all the major goodies like generics, delegates/lambdas, nullable types, extension methods, and LINQ. He closes the book with a nicely laid out, thoughtful discussion of C# 3's benefits and its possible future.

This is a great book for understanding how some of the more fundamental features of C# are implemented, and how to best use them. This book definitely belongs on your bookshelf, right next to Bill Wagner's Effective C# and More Effective C# .

(I'd love to see Wagner and Skeet in a room full of VB6 programmers, diving into a deep discussion of anonymous methods, expression trees, and lambdas. Watching all the VB6ers heads explode would be great entertainment.)

Test Execution Problem in VS2008

2008-06-18T05:00:00.001-05:00

A nasty bug slipped through the cracks in VS2008's test execution engine. The problem is rooted in the whole test deployment concept in Visual Studio 2005 and 2008 where all assemblies are copied to a folder underneath the TestResults folder, then executed from there.

I think this is a silly, overly complex way to execute tests, and it's particularly a problem in VS2008 because the test runner doesn't execute with that folder as its base path. A bug in VS2008 causes the AppDomain.CurrentDomain.BaseDirectory property to be set to C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE instead of the proper subfolder under TestResults.

There's some good detail and a possible fix in this MSDN post. Unfortunately, this doesn't work in my environment because the resolver's assembly path property value ("Public Assemblies;Private Assemblies") also gets appended to the path, further borking things up for me.

I'm moderately narked about the bug with the BaseDirectory slipping through, but I can understand it. Bugs happen, they get fixed. Hopefully there's a workaround for the bug while a real fix is being created.

I'm more narked about the underlying decision to have tests run from a location different than the project's build directory. The overall concept is brittle and has too many moving parts. I have to fool around with DeploymentItem attributes in code, I have to fool around with Deployment Item settings in the test configuration.

The idea of a TestResults folder is great if it were limited to, like, holding results. Reports, working files, etc., would all be appropriate for that folder. Copying all the binary bits and test support files to that folder, then running everything from that target isn't the way a real unit test framework would do it.

Unfortunately, this bug is a complete show-stopper for me because I can't work around it. The specific issue for my current project, based on VS2005, is a crapload of tests reliant on our NHibernate infrastructure. NHibernate's Cfg.Configure() command, invoked with no parameters, attempts to load the hibernate.cfg.xml file from the current folder of execution. Sure, you can specify a directory path to load that file from, but I'd have to do significant amounts of code ugliness to alter that input path based on production, test, dev environments.

I'm waiting on more help from Microsoft on this bug, but for now it means we can't proceed with moving up to VS2008 for this phase of the project. I'm bummed.

VS2005 -> VS2008 Conversion Wizard Runs Every Time

2008-06-15T15:24:00.001-05:00

I'm working through a few minor nits with a moderately sized solution (23 projects) that I've just converted from VS2005 to VS2008. One nit is the conversion wizard runs every time I open the solution. Irritating.

Answer found after trolling through some MSDN posts: Test projects appear to have a few hitches during the conversion process, one of which is the FileUpgradeFlags element in the .csproj file failing to properly update. This causes the wizard to re-run every time you open the solution containing the project.

To fix, find the element <FileUpgradeFlags>. It will probably look like

Remove the zero in the element content, leaving an empty element:

Do this for every test project in your solution. Save 'em all, re-open the solution and you should see no conversion wizard. Yay!

(Original MSDN post here.)

Now if I could just get MS Test to play nicely with my hibernate.cfg.xml files in the MS Test deployed location. I continue to search for a rational explanation of why MS Test insists on copying all binaries to a location separate from the build location in order to run its tests, forcing you to deal with "DeploymentItem" attributes and test configuration shenanigans. I've run in to a number of PITA issues with this separate-but-equal concept, and I'm having a hard time understanding the reasoning for creating a second environment that's not treated the same as the solutions' build environment. Brittle, complex, and more moving parts than necessary.

Yet another reason for preferring MBUnit for a test framework that helps, not hinders, all the testing I like to do.

Shout Out: More Effective C# Rough Cuts Available

2008-06-15T14:21:00.001-05:00

Bill Wagner's Effective C# is one of the books you absolutely need to have living on your bookshelf if you're working in .NET. Bill's book is crucial to understanding how certain things in .NET and C# work, and it's full of great examples on why you need to do things in a particular fashion. He goes in to exactly the right level of detail to make you understand things like the as/is keywords, and why you really need to think hard about how to implement equality checking.

Effective C# covered C# 1 with just a nod to 2.0, so it's good to hear Bill's nearing completion of his work More Effective C#, updated for all the goodness of C# 2.0 and 3.0. You can pre-order through Amazon, and it's also available on Rough Cuts where you can get read the chapters as they're going through the editing process.

I'm really looking forward to getting a copy of this when the dead tree version comes out in November. (Hey, maybe a birthday present for myself!)

Meme: How I Got Started Programming

2008-06-10T00:12:00.001-05:00

Tim whacked me with his post, so here goes.

How old were you when you started programming?

High school, 1979. Age of 16 or so. Radio Shack TRS-80 with a cassette tape drive for its storage. Not quite punch cards, but damned close. A buddy whose parents had gobs of money bought him one. (A tape drive, for cryin' out loud! They must have been rich!) He and I were in a D&D group together, so naturally a geeky computer attracted us.

How did you get started in programming?

I went enlisted in the Air Force in the general electronics field. I could have ended up stringing telephone cables, but got lucky and landed a position in school for repairing massive aircraft radar systems. I got even luckier by landing a slot for doing inflight repair, fulfilling a dream of flying I'd had since I was a kid and my dad used to take me out flying over rice fields in central California. I digress. At tech school in Biloxi, Mississippi, I got the chance to start programming 6502 processors using octal assembly code. A complete PITA, but it rekindled the interest I'd found from the TRS-80 years earlier.

I got my first real computer a year or so later when I hocked the new aluminum wheels on my '67 convertible Camaro in order to buy an Apple //e computer complete with 32K of memory and a 64K video card. Man, that was the cat's ass! (I see Wingfield had a 128K expansion card. He must have been living the high life, I tell you.)

I progressed to dropping in a Non-Maskable Interrupt card so I could hack into various wargames that were kicking my then bony ass. I eventually did such crazy stuff like soldering together EPROMs onto a single socket with a DIP switch so I could toggle between the //e and ][+ BIOS sets. I hung around a guy who wrote a voice driver for his modem to have his computer call up folks at random times, say "Asshole", and hang up. Somewhere along the line I wrote some code that manually moved my 5.25" floppy drive's head around.

That interest slowly progressed as I was posted to Anchorage, Alaska, where I bought a 286 system from Radio Shack and started fooling around with Borland Turbo Pascal, then Turbo C++. I eventually bought a generic 386 system from some company that went out of business the week after I bought the box. So much for tech support.

The Air Force was kind enough to pay for 75% of my schooling while I was active duty, so I started taking night school courses at a branch of Chapman University (then just "College"). I hit Pascal, more assembler, threw up through one Cobol course, and did some C++.

All that was just some background until I left the Air Force, wandered 'bout for a number of years, and eventually worked my way into cutting code for a living. More or less.

What was your first language?

Whatever the variant of BASIC on that TRS-80.

What was the first real program you wrote?

Tough to nail that one down. I remember starting one on the TRS-80 which was supposed to compute catapult damage to a castle wall (D&D, remember?), but I can't remember if we finished it. Most likely it was some octal exercise on the 6502 in tech school.

What languages have you used since you started programming?

Surprisingly, not as many as some others: BASIC, AppleSoft BASIC, Pascal, Cobol, Assembly on a number of different procs, C++, Perl, Java, C#. Suffered through Lisp just enough to be able to configure JDEE when I was doing Java work.

What was your first professional programming gig?

I did some writing of Perl modules for managing servers and accounts when I was a network admin, but that's utils, not cutting code. My first "real" programming gig was as part of a team working on tools to convert SGML to HTML and XML. (Yes, kiddies, let old fart Jim tell you about when you needed a PhD to understand stupid markup made when single characters counted so everything was implicit, not explicit. Try figuring out an implied element closing when you're five layers deep. Obviously I'm still scarred.)

I only wrote code around the edges of that, so maybe maybe my first gig was actually writing tools to strip out metadata from DTED terrain data files and stuff all that in a database for use by a really cool system designed to figure out where bad guys hide so you can more easily find them and blow them up. I wrote some code around the edges of that one, too, as well as built tools to create database schemas in Sybase 11 and Oracle 7 for the system's underlying datastores.

If you knew then what you know now, would you have started programming?

Hell yes! I love what I do! I wish I could have done more of this over the years, but I've had a somewhat eclectic career due to following my wife around for her military assignments. (Germany, Alaska, Washington DC. It's not been bad...)

If there is one thing you learned along the way that you would tell new developers, what would it be?

Learn to learn, don't just learn technology. What you knew five years ago is laughable now, and what you knew last year likely isn't a higher on the scale.

One more thing: Learn to have the confidence to say 1) "I don't know" and 2) "Man, that code I wrote last year/last week/this morning really sucks. But I've learned how to write better code, so I'll do better."

#1's never been a factor for me because I follow with "But I can find out.".

#2 has only just started to get somewhat easier after reading blogs or hearing podcasts from folks like Atwood, Ching, Miller, Haack, and a bunch of other industry leaders. If those guys can be up front about their weaknesses then why should the rest of us not be?

What's the most fun you've ever had ... programming?

I'm torn between two things. First off, watching the head of a hard drive move back and forth as you're stepping through some driver code you've written really is cool. SOOO much of what we do is nebulous, which I think is part of the reason we like writing unit tests: a green indicator comes on. Seeing your code make something physically move is just plain wicked cool. That bit of fun was, uh, many years ago but I still remember it vividly. (I also remember having to repair the armature after some bad code...)

The second bit of fun would be a space of a couple months after I'd joined Quick Solutions last year. I came on board with the expectation from my boss that I'd quickly jump into a leadership role and help drive business, lead teams, write offerings, etc. But... for my first couple months I just got to sit my kiester in a chair and code. It had been YEARS since I'd been able to have no responsibilities but write tests, write code, geek out with other smart folks. One of the most refreshing times of my life, and exactly what I needed after coming out of a less than optimal situation.

Passing on the love (or, tag, you're it)

Shout Out: XNA and Robotics Studio Event, 19 June in Cincy

2008-06-07T22:30:00.001-05:00

Mike Wood and the gang at the Cincinnati .NET User Group are putting on an XNA and Robotics Studio event on 19 June at 6pm. The event will be presented by Microsoft's Bill Steele.

Bill, if you don't know him, is a certifiable nut who does all sorts of crazy things like run MSDN events in the Heartland region, play around with Robotics Studio, write games in XNA, and has invented a system for displaying small aircraft's flight information on the virtual surface created by the spinning propeller blades.

Seriously, Bill's a wicked smart, passionate guy who will definitely entertain and educate you. Make it a point to stop by on the 19th if you're at all interested!

Playing with SlickEdit

2008-06-02T15:40:00.001-05:00

The folks at SlickEdit provided copies of their cool Visual Studio tools to folks like myself who are members of The Lounge.

Being a tool geek I couldn't resist installing it and fooling around a bit. I've not spent a whole lot of time with the tools, but have already found some cool bits. The window below shows a cool documentation preview in MSDN style, a nice compliment to what I get from ReSharper's Ctrl-Q. There's also a nice regex evaluator which can generate code for you to paste in as needed.

The "Quick Profiling" bits require you to get some trace handling in your code, so I'm not sure how far I'll go with that, but it may be an interesting thing to experiment around with.

There's also a very nice comparison tool as part of the Versioning Toolbox. There's some interesting visual sugar for version graphs, history, and visualizations. The graphs are pretty cool, and the list of providers is very competent: SVN, CVS, TFS 2005/2008, and VSS (barf).

Perhaps one of the best widgets in the versioning toolbox is the DIFFzilla window:

This is nearly as good as my favorite comparison tool Beyond Compare 2. Love that directory compare feature, and you can quickly get file comparisons by double-clicking a set of the files in this window.

Overall I like what I see so far. While I've got access to other tools which fit a lot of these needs, it's really nice to have all this wrapped inside Visual Studio.

Save The Date: Open Spaces Mini-Conf 9 July

2008-05-30T09:01:00.001-05:00

Mike Wood and I are organizing an open spaces event on 9 July at Max Training's Mason facility. The event's still being fleshed out, but we're looking at running from 6pm to 9pm. Max has a crapload of space in their Mason facility, so we ought to be able to run five or six concurrent discussion groups.

Stay tuned for more details!

ANTS Profiler 4 EAP

2008-05-27T11:07:00.001-05:00

I spent an hour or so working with a couple folks from Red Gate this morning to run through the latest build of their ANTS Profiler v4.0.

ANTS 4 is still in EAP (download latest bits here), but I was awfully impressed with the state it's in. I downloaded the bits, installed it, ran a quick session on a monster WinForms app I've worked on in the past, and quickly got down to the guts of some possible performance issues. The UI's nicely done, and I was very, very impressed with the app's responsiveness. I'd all but given up on ANTS 3 and dotTrace because of nearly unusable performance while trying to profile a couple apps.

ANTS 4 still has a way to go. There are some bugs running around, and some UI tweaks need to take place, but overall I liked what I saw with this version. You ought to go have a look at it if you're interested in an easy to use profiler.

<disclaimer>I get some software from Red Gate for free because of my MVP status. That doesn't stop me from criticizing if needed.</disclaimer>

Recap of Cincy .NET User Group Panel Discussion

2008-05-20T23:11:00.001-05:00

The great gang at the Cincinnati .NET User Group invited me to participate in a panel discussion at their meeting tonight. I was honored to be up front of the group with Tim Apke and Ed Sumerfield, both two sharp guys with much more technical experience than me. All three of us have, as Mike Wood put it "a long history in IT" which I think was Mike's nice way of saying all of us are old farts.

The discussion was very free form and hit a lot of great topics ranging from specialization or generalization to estimation accuracy to workplace culture. Dealing with new technology was big one, as was questions about breadth of experience (outside of the strictly technical domain). The value of certifications was bandied about with a mild consensus seeming to form around them being good in the proper context: use 'em if you need to prove your chops early in your career, but don't overly fixate on them.

Hearing Tim's and Ed's perspectives along with those of the audience was a great experience. Tim and Ed are wicked smart and have some great insight into how to steer one's career along. Tim was emphatic about taking ownership of your own career. In a sidebar after the meeting he compared taking care of your career to taking care of your car. You keep your car's tires in good shape, change the oil, and give the vehicle a tune up on occasion. Same concept applies to your career. Ed also impressed the hell out of me with a number of things, not the least of which were his closing comments which was a short haiku along the lines of "own your path" but he said it way more better.

One of the regulars there (forgot your last name, Jamie -- sorry!) hit me with the last question of the evening and asked how I manage to balance work, community involvement, book writing, and time with the family. That one hit very, very close to home and got me choked up in a major way -- not what I would have preferred for my last question of the evening, but there you have it. I don't always do a great job of work/life balance, but I've made some tough choices in my career to favor family over work. I've passed up great opportunities, I've struggled with sub-optimal part-time positions, and I've left a high paying job to be unemployed at home in order to take care of the kids. My career would be in a much, much different spot had I chosen career over family.

The cons of those decisions are that I'm not some internationally recognized expert traveling around the world talking at TechEd Barcelona or running some wicked cool project in Dubai, nor am I billing out at $500 per hour while working at iDesign or some similar firm. The pros of those decisions are that I got stay at home with my daughter and son while they grew up, and I'm not traveling three or four weeks of each month while my wife and kids live their lives without seeing me. (Another con: costs of therapy for two kids when they hit teen years and figure out how screwed up they are after having had me as their primary caregiver...)

So to those of you who thought I got emotional about that question, you're right. It's really at the core of who I am, even if I don't get it right as often as I should. (That's me, too, BTW.)

Actually, forget all that. It was really allergies. Sorry.

In any case, the panel discussion at the group was an excellent evening. I hope attendees got something useful out of it!

Dealing With Technical Debt

2008-05-19T11:02:00.001-05:00

All projects acquire technical debt in one fashion or another, and in varying quantities. I've been looking at a couple past projects to identify areas in need of some debt repayment should the projects move into their next phases.

Apropos, then, that I ran across a great post from Steve McConnell on technical debt. I particularly like his sections on communicating about technical debt and debt safety. Be sure to follow Steve's links to Ward Cunningham's and Martin Fowler's articles.

Good reading!