Mark Freedman’s Blog

Archive for the ‘Development’ Category

Between handling response issues, we’ve continued our NUnit exploration.

From what I’ve been reading, it appears that using NUnit without the intention of TDD is like using Visual Studio without enabling Intellisense. Why bother?

I started by reading a few articles, such as Getting started with TDD , by Steve Smith. I also read a good one by Roy Osherove, and he states in his Test-driven development with NUnit - Introduction article, there are three bulletpoints for doing TDD:

1. Make a test that fails
2. Make it work
3. For every new feature, go to step 1

Now, that seems rather simple, but the hard part is figuring out what tests to write , and if you’re testing existing code, should you refactor it in order to enable proper testability.

The concept that seems to be hardest for people starting out in TDD to grasp is the whole concept of writing a test that fails even before attempting to write the code that implements the feature being tested. But if you think about it, it’s a pretty common iterative approach to things.

The first example in Roy’s article shows that you do this by trying to instantiate an object from an as-of-yet non-existent class. You can’t get much more basic than this. That’s an easy one to get to pass, and it’s a bit of a high getting that test to turn green. Now you feel like you’re on your way.

---

Roy’s article is a great intro, but the main goal I’m trying to accomplish is to decide HOW to introduce NUnit and TDD to a development team, so I’m continuing to research how other teams have done this.

We’ve answered our first two questions from the prior article , and decided not to learn by incorporating tests into our existing systems, mainly due to the comment made in my previous article that we need to assume that current systems are "clean".

Due to scheduling conflicts, we also answered question 4 (should we have the team work together on a single system so we can all learn together, etc.). We’re experimenting on our own with samples that come with NUnit, plus our own small examples. As we work on future projects, we’ll build on that by generating tests for new code, and creating tests for modified code. We also recognize that refactoring will probably be in order to make existing code more testable, so we have to be mindful of including this into our estimates. Convincing management shouldn’t be too difficult, since they already feel the pain of too many bugs getting into QA, and are realizing the up-front time investment is worth it.

We’re still discussing question 3, the introduction of mocking. We’re leaning towards building our own mock objects on an as-needed basis at first, and we’ll look at third party mocking tools later on.

We’ve also taken a look at TestDriven.net , which provides some basic integration into Visual Studio. The best part of this tool that we’ve seen so far is the included nCover utility, which helps us to see what code we may have missed writing tests for. The jury is still out for us on the entire TestDriven.net tool, since nCover is available separately, but some people swear by the whole package.

Well, on with my best practices investigation for introducing NUnit and TDD…

Update
I’ve updated some of the points below, based on some of the comments I received, including points about when to answer questions, the appropriateness of jokes, and following through after the presentation.

Last night, I attended a terrific Speaker Idol event at the NYC .NET Developer’s Group at the Microsoft office in NYC. It’s one of the formats I mentioned in my post about user group meeting ideas.

This was the first user group meeting I’ve attended since I helped start a couple, and it was really nice to focus more on learning rather than coordinating. I had three main motivations for attending this meeting:

1. I wanted to finally attend a meeting rather than run one.
2. I wanted to see how a Speaker Idol event is run, in order to run one ourselves.
3. I wanted to see what it takes as a speaker, so perhaps I could try it myself one day.

I feel like I met these goals. First of all, attending these in NYC always gives me a rush of energy. I love going to the city, because it’s so amazingly alive and vibrant. It gives me the feeling of being able to accomplish anything. And there’s nothing like a warm summer night in the city that never sleeps.

And the second and third goals were accomplished with flying colors. Although I tried to make this a non-working event, I couldn’t help myself. I spent the entire night taking copious notes. And although this was the first Speaker Idol event I’ve ever attended, and it’s the only one I can base my observations on, I think it came off great. I think it can serve as a model for future events, so I put together a list of guidelines from this experience.

Although I haven’t presented at user groups yet, I’ve had similar experiences. My tips are a combination of those, of comments from last night’s judges, and of my observations from this and other user group meetings.

Great job done by Stephen Forte, Andrew Brust, Peter Laudati, Bill Zach, and all the speakers and judges!

Basic Rules

• Approximately five speakers should present (there were six last night).
• Each speaker gets 10 minutes to do their main presentation.
• There are four judges who are recognized leaders in the community, to give this legitimacy.
• During the presentations, the MC (Stephen Forte, for last night’s event) gives a silent two minute warning signal.
• The MC then gives a cut sign, signaling to the speaker that they have 20 seconds to wrap up.
• Once the presentation is complete, two minutes are alloted for a Q & A session with the audience.
• This is followed by a judge commenting session which lasts from three to five total minutes, rotating through the judges who comment on the presentation style (NOT the content). Sort of like American Idol. For each presenter, the comments are started by the next judge in rotation.
• At the end of the competition, bring all the participants to the front for a final round of applause, and announce the winners.
• There are three winners. At last night’s meeting, first place won an Xbox, second and third place won versions of Windows Vista.

Moderator Tips

A Speaker Idol event is similar to a mini code camp, where you’re pretty much going crazy trying to get equipment set up and tested. It was pretty hectic last night, with people downloading codecs, using borrowed laptops, etc. More about this in the Speaker Tips section, below.

• Have someone else handle the food. You’ll be too busy coordinating everything else with the speakers and judges, so try to get a sponsor to handle that. This was what the group did last night, and all it cost was about 10 minutes of a (deathly dull) sponsor presentation at the start of the session. Once you’ve seen one recruiter presentation, you’ve seen them all. They were sincere, but c’mon recruiters — use a little imagination. I don’t care how many clients and consultants you have. Tell me how you could help my career… anyway, that cries for another post…
• You may need to be the liaison between a speaker and the supplier of a solution if their presentation isn’t working on their own equipment. Set aside some time for this. It was a bit of a scramble last night, so I’d recommend requiring the speakers show up an hour before the session for setup and testing. Things will always get a little crazy, and a bit of luck is always involved, but this will increase the chances of success.
• I’m not sure how the presenter order was decided, but there’s a definite advantage that increases with each speaker. You could either have a random drawing, or use the reverse order of who volunteers to participate. Since most of us are so busy these days, I’d prefer a random selection.
• A quick 20 second intro of each speaker would eliminate the need for them to do more than a ten second "hello" at the beginning of their presentation. Most people are uncomfortable introducing themselves anyway, so it may keep them more at ease to start their presentation if they don’t have to concern themselves with that. They can just display a simple info slide at the start, while they introduce the topic.
• Clarify to the audience and speakers that for these types of presentations, especially with a dedicated Q & A period, almost all questions should be deflected for that period. The only time a question should be addressed during the body of the 10 minute presentation is if it’s critical for the direction of the rest of the presentation.

Speaker Tips

Do the three "P"s: Prepare, Practice, and Present. I’m sure I’ve heard that phrase before, but I’m not sure who to credit…

Preparation

• Tailor your presentation for 10 minutes (and I’d shoot for 8 to play it safe ).
• Be aware of whether your presentation is more of a discussion topic or a presentation, and prepare the style and flow based upon that. Make sure you structure the presentation to have a strong start, middle, and end. At the start, do the quick hit to get the audience engaged, and tell them what you’ll be talking about. Next, dive in and talk about it. Finally, quickly summarize with a couple of key conclusive points.
• Go for impact from the start, whether it’s through humor or a one liner that clearly sets the stage for the presentation.
• Slides should be minimal, and only used as cue cards for what you’re going to say.
• Since this is a 10 minute presentation, only pick a couple of key points to elaborate on — one positive and one negative, if possible.
• If your presentation calls for a comparison between two or more options, use visuals to compare. In a 10 minute window, you’ll need to get the point across quickly, so visuals work best for this.
• Use a large font size. The obvious reasons go without saying. But less obviously, it turns code into more of a quick-hitting visual.
• Don’t use blue font on a black background. It’s virtually impossible to read without straining. I’d actually recommend sticking with the default white background. A lot of developers seem to favor a black background these days, but although that may work well on your desktop, it doesn’t translate well to the large screen.
• Use very simple demos. If you can get your point across with a single visual, or just a tiny code snippet, then you can succeed in a 10 minute slot. Review your code several times as you prepare, stripping out everything you can, while still making it relevant. This is a common theme for writing, also.
• Plan the Q & A session, anticipating the types of questions you may get. You may need to balance leaving out a point or two in order to open up the possibility of a couple of good questions, but at the same time, don’t leave out critical info during the main presentation which will only leave your audience in a cliffhanger.

Presentation Style

• Project. You don’t want people straining to hear you, especially when you only have 10 minutes to state your case.
• Face the room. If you don’t face the room, your voice will just bounce off the wall behind you, and that ain’t gonna help with projecting.
• Rotate facing each side of the audience. This will help engage the entire audience.
• Don’t read directly from the slides, or repeat them word for word as if memorized. This becomes very robotic.
• Setting the slide show on automatic timer may be a novel way to keep you focused on your flow and time constraints, but it could be a distraction if you have to keep stepping back to a previous slide.
• If you’re natural at it, inject humor, especially at the start. It helps build rapport. Jabs at users are always good for a laugh in front of tech groups. But if it isn’t your normal modus operandi, don’t force it, because it will be obvious that it’s being used as a gimmick.
• Be aware of your audience. As I mentioned above, jokes about users are ok if your audience is a tech group, but don’t joke about topics and subjects that may offend your audience. If you feel any discomfort when about to tell a joke, trust your instinct and play it safe. Very little can take the air completely out of a presentation than a misguided attempt at humor.
• Show enthusiasm for your subject matter. If you can’t show enthusiasm for 10 minutes, you’re speaking on the wrong topic for you.
• When notified of the two minute warning, or 20 second wrap-up, don’t acknowledge it. It ruins the flow, and disengages your audience.
• Avoid silence, but don’t fill it with hemming and hawing ("um"s). Practice in front of mock audiences (or the mirror) is key. If you need to take a few moments to do something on the screen, at least explain what you’re doing while doing it.
• Don’t trail off or mumble when you speak. This is another variation of hemming and hawing, and people begin thinking they may be missing some important info.
• Be energetic. Watch someone like Stephen Forte when he speaks. He can make accounting sound exciting (sorry accountants ). We live in a fast moving, "MTV" world, and it takes a lot of animation to keep our attention.
• Stand in front of the podium. Stepping behind (for reading notes, etc.) only serves to disengage your audience. This is why you need to do the three Ps. You don’t want to sound as if you’re reading from a book. Show us you know your topic. You want to project credibility.
• Make eye contact with the audience. You can pick a handful of people (one from each side of the audience) to feel like you’re speaking one on one. I’ve heard a related recommendation for writing. Imagine that your audience is one person — a friend of yours.
• When things screw up, self deprecation goes a long way. The audience can relate to screw ups.
• Be honest. If you really don’t know the answer to something, say so. Otherwise, you risk the credibility of your entire presentation.

Presentation Content

• Make your intro of yourself and your company extremely short (if needed at all — see moderator tips, above). You can show a simple intro slide while you introduce the topic, in case people really want to know. Don’t be offended that we came here for the topic, and not necessarily for you.
• Explain why you’re presenting the topic, and what business reasons there are for it.
• Asking for a show of hands initiates interaction with the audience, but don’t leave it at that. Otherwise it just seems gimmicky.
• Use personal insight when discussing examples and experiences. This helps the audience identify with you and the topic you’re trying to convey. Otherwise, you may as well be reading facts out of a textbook.
• Never make comments or state opinions without following up with "why". "Why" is really the most important type of question you can answer. And the specific "what" and "how" always follow the "why".
• Have the demos open and ready BEFORE starting the presentation. Nothing leads to those empty spaces more than waiting for Visual Studio or PowerPoint and associated project files to open. You only have 10 minutes, and time always seems to run away quicker while waiting for these to open.
• Get to code as soon as possible. For a technical audience, getting to the meat is key for keeping us engaged.
• Switch to full screen mode when showing code (SHIFT-ALT-ENTER). Popping panels are a major distraction.
• Display your resources slide during your 20 second wrap-up and into the Q & A. The judges mentioned to leave it up there after speaking to it, but I wouldn’t even recommend speaking to it. It wastes valuable time, and your audience expects to see this at the end anyway, so it’s obvious.
• Use the regions feature in your code examples to make it easier to focus on small snippets.
• When discussing unknown technologies, give quick, one-line intros. It may help to show an analogy to technology your audience is familiar with. For example, EJB to .NET Enterprise Services. It may not be exact (like my example?), but it’ll give us the proper context.

After the Presentation

Many people attend these presentation for the educational value, in order to keep up with what’s happening in their field, and they make a significant time commitment to attend your presentation. Whatever your motivation for speaking, the reputation you earn is based upon more than your session. How you follow through also counts in a big way.

• For speakers of any type of presentation: please try to make yourself available, at least through email, for any follow-up questions attendees may have. Due to the nature of presentations, there are almost always outstanding questions that cannot necessarily be answered or even anticipated during the presentation, so you should always expect questions after the event.
• It’s also a good idea to provide the organizers of these events with presentation material and supplements to post on the organization’s website, to help with the follow-on.

I anticipated such an event to be a lot of fun, and it exceeded my expectations. I’m sure it was nerve wracking for the speakers and the moderators, but like my experience with the code camp, I’m sure it was well worth it. I’ll use this post as a guideline for when my group runs a similar event, and hopefully others will find this useful, even though I’m basing it upon limited personal experience. If you have anything to add or suggest, please comment.

My team is taking a dedicated look at NUnit over the next week or so, in order to figure out how to incorporate it into the culture.

I feel sort of guilty spending so much dedicated time on this educational task, because I’m so used to spending my days firefighting, managing, and troubleshooting. But this should be part of an Architect’s job, so I’m trying to ignore this uncalled for guilt emotion.

We have two main motivations for investigating unit testing. One is the desire to decrease the number of bugs found during the QA process. The other is our move towards continuous integration. I’d love to eventually get to TDD, but that’s a longer term goal.

Also, although Visual Studio 2008 has built-in testing in most SKUs (as opposed to what VS 2005 did), we decided to go with the de facto standard of NUnit. Besides, I understand there’s an integration option for VS, anyway.

The initial questions we’ll be looking to answer is the following:

1. Should we learn it by adding tests to existing systems?
2. Should we just add it to new projects or to enhancements / fixes for existing projects? On this episode of .NET Rocks!, one suggestion was to assume that existing systems in production are clean, so just create tests when needed.
3. Should we introduce mocking at this point? Or is it too much to tackle at the same time. But if not, how can we really be creating "unit" tests if we retain dependencies?
4. Should we have the team work together on a single system so we can all learn together, or should the team start by learning from the NUnit samples and reading the definitive book on the subject?

One of the first things I did was google for how others are approaching this problem. I found a lot of articles, so I have a bunch of reading ahead of me.

I’ll be posting links to those, and whatever else I learn, in the upcoming days.

When it comes to estimating, developers live in an idealistic world. Despite repeated experiences of constant interruptions causing projects to overrun estimates, developers tend to look at subsequent projects with wishful thinking.

It’s strange. Most developers associate so much pain with the last minute rush to deadlines, you’d think they’d surely tack time onto their next estimate. Developers absolutely loathe the following required and unavoidable tasks that occur almost every day:

• Interruptions by managers
• Interruptions by other developers
• Bug fix requests by QA
• Status meetings (Scrum and other)
• Design meetings (theirs and their teammates’ — ok, they usually find some enjoyment and challenge in these)
• Deployment meetings
• Code Reviews
• Etc. (does “etc.” warrant a bullet?)

Yet, with so many of these cutting into their daily attempts for focused development, you’d think they’d take these into account when estimating the next project. Developers dream of a world where they could lock themselves alone in a room for days, with coffee and junk food, and just code…

(taking a break to dream… niiice…)

…and nothing will ever kill that dream, no matter the pain of what they’ve just been through. It’s an admirable stubbornness and idealistic mindset, but it just ain’t realistic.

Developers, (developers, developers,) if you can’t convince yourself that you’ll be doing more than coding, for your next estimate pretend that you’re working at least 30% less than a full week. Just pretend you’ll only be working 25 to 30 hours per week. Now how long will it take you to complete the project?

Of course, the next thing to tackle is the complaints about interruptions, even after proper estimates…