Wednesday, December 16, 2009

Favorites of 2009 (Telligent-Style)

Jana started an interesting thread on a Telligent-internal mailing list, which prompted Josh to follow up with a great blog post. The topic was four questions:

    1. What was your favorite work-related or field related or technical read for 2009 (white paper, book, etc)

    2. What was your favorite new Telligent feature for 2009?

    3. What was your favorite enhancement for Telligent products in 2009?

    4. Favorite external app/product/feature you used in 2009?

I enjoyed a bit of a retrospective over the year and came up with the following responses.

Favorite work- or field-related or technical read: Leading Lean Software Development by Tom & Mary Poppendieck. Awesome motivator for what organizations can do if they get the entire group solidly behind transforming how they build, deliver, and support/service products and services. Bob Martin’s Clean Code would be a close second, Stand Back and Deliver a solid third.

Favorite Telligent feature for 2009: I was lucky enough to work with a great group of guys (Dave, Nate, Sean) on v2 of Telligent’s web services API. They kicked ass with amazing work and evolved our web services into a solid, powerful approach for extending and writing new apps on our Telligent Evolution platform.

Favorite enhancement for Telligent products in 2009: If you’ve read my blog or Tweets much then you know I’m a Lean fanatic. My favorite enhancements for our products in 2009 are those we didn’t. Nope, that’s not a typo. Our leadership gave us some great support for rethinking how we approached development in the last four to six months. As a result, we focused hard on a lot of things behind the scenes. Features were dropped from the backlog. Features were simplified in our current codebase. Features were CUT from our codebase. As a result, we’ve ended up with an improved codebase and significantly simplified user experience. Cutting and simplifying is an absolutely glorious feeling. Lean, FTW!

Favorite external app/product/feature of 2009: Visual Studio, because while I’m not a “real” developer, writing code is a great way for me to stay engaged with things I’m very passionate about. (Testing, development practices, beautiful code.)

Friday, November 27, 2009

Book Review: Beautiful Testing

Beautiful Testing: Leading Professionals Reveal How They Improve Software, by Adam Goucher and Tim Reilly. Pub by O’Reilly, ISBN 0596159811.

This is a great book for testers, leads, and managers to read to get a better picture of where your testing process can bring value to your work. A few sections of this book didn’t get me much value, but the vast majority of the book left me frantically scratching notes and folding corners of pages over. I read the book over a weekend and came away with a large number of major additions to my QA roadmap I use at work.

Kamran Khan’s chapter on fuzz testing reinforced my ideas that choking your system with invalid parameters and input data is a tremendous way to shore up that system’s stability. I also really enjoyed Lisa Crispin’s and Alan Page’s separate chapters, both of which emphasized value-driven, sensible approaches to test automation.

If you want an amazing story around how testing can directly impact the lives of those around you, read Karen Johnson’s chapter “Software in Use.” Johnson ties a visit to an Intensive Care Unit to work she’d done on equipment in that ICU – it’s rare anyone sees that practical a link to work we do in this industry.

Other highly worthwhile chapters include the piece on Python’s development process, the overview on TDD, Mozilla’s regression testing philosophy, and others. The Python chapter, in particular, is a tremendous testament to how a rigorous testing philosophy can guarantee very solid releases even with a broad, distributed team of varying skills.

As my examples above point out, there’s a great amount of broad-stroke value in the book; however, a wealth of smaller, critical points abound in various chapters as well. Some weren’t phrased exactly like this, but I’ve taken away these other concept as well:

  • Track the source of your bugs (test plans, exploratory, developer, etc.) and pay special attention to bugs found by customers. These “escapees” point to areas to shore up in your test plan.
  • Mindmaps are a great way to brainstorm out your test plan or test areas.
  • Use small tools like fuzzers to help create your baseline input data.
  • 100% passing rates for your automated tests isn’t reasonable. Investigating 100% of your failing tests to determine whether the specific failure matters is reasonable. (I already firmly believed this, but it was nice to see in print!)
  • Using image comparison to check formatting.

This is one of the better books I’ve read this year, and it’s absolutely worth adding to your shelf.

Several Book Reviews

97 Things Every Project Manager Should Know by Barbee Davis. Published by O’Reilly. ISBN 0596804164.

This is a terrific collection of small articles on many aspects of project management and successful team leadership. There are a large number of authors involved in this work, so the articles’ voices vary, but each one is very well written and clear.

I loved Neal Ford’s and James Graham’s articles on productivity and finding good individuals, and William Mills’ Meetings Don’t Write Code certainly fit right in with my core philosophy.

The book’s very easy to read and has a lot of valuable insight. Highly recommended!


Elements of Programming by Alexander Stepanov and Paul McJones. Pub by Addison Wesley. ISBN 032163537X.

Serious approaches to algorithms for the hardcore computer science geek. Heavy on math, low on applicability for me and my line of work – but I’m sure lots of folks will find it very useful. Lots of concise, in-depth discussion of foundational knowledge, and plenty of exercises to help evolve your skills.

The tone’s exceedingly dry and academic, and I got very tired of the authors repeated assertions that you need to be using a “real programming language such as C++.” Guess all the value-providing projects I’ve helped roll out in Perl, Java, C#, and other languages haven’t counted.

That said, this is a wonderful book for those interested in raising their skills in hardcore algorithms.


The CSS Anthology, 3rd ed by Rachel Andrew. Pub by Sitepoint, ISBN 0980576806

It’s Sitepoint, it’s CSS, it’s pure goodness in full color. Another amazing book from Sitepoint that is clear, concise, example-driven, and highly useful. I love how many of the topics are written in a before/after or progressive style. It’s a great mix between a cookbook and tutorial approach.

There’s enough content here to make this book useful to CSS novices or advanced folks.


The Manga Guide to Calculus, Hiroyuki Kojima, et. al. Pub by No Starch Press, ISBN 1593271948.

The Manga Guide to Molecular Biology, by Takemura Masaharu, et. al Pub by No Starch Press, ISBN 1593272022.

Both these books follow the same great approach as the Manga Guide to Physics I reviewed some time ago: Break a complex idea down in to small pieces, clearly explain it with practical examples, and use the fun Manga comic style to wrap the entire concept in a great story.

I never took calculus in high school or college, yet I was able to get through the Guide and come out at the end with a pretty fair understanding of it. Moreover, I actually enjoyed the learning journey!

My nine year-old daughter loves these books and always reads through them after I’m done. She’s not coming away from the books with great knowledge of the concepts, but she’s finding them interesting, fun, and is less intimidated with the subjects. I think that’s a big win because these guides are laying some good ground work for her to come back to later.

Friday, November 20, 2009

Displaying the Document Properties Toolbar in Office Documents

The Document Property bar in Office 2007 is handy, particularly if you’re working with SharePoint document libraries and have added some custom columns. Those show up as nifty properties in your document, like so:

Unfortunately, if you close the property bar it’s not very intuitive on how to get it open again. Use Office | Prepare | Document Properties to get it back. Yeah, that Properties command is under “Prepare.” UI Fail, but there you have it.

(Posted because I continually forget how to get the properties bar back.)

Monday, November 16, 2009

Automate Activation/Deactivation of SharePoint Features

Click, wait, click, click, wait, click, wait, wait, click, wait, … Life as someone working with SharePoint development when you’re trying to update features you’re working on or testing. It sucks.

Here’s a little Watir on Ruby script to ease your pain. You can launch this from the command line with a “-a” or “-d” arg to activate or deactivate. Edit the @siteroot and @*Features variables to match your needs.

This uses some XPath-fu to find the Activate or Deactivate button for the feature named in the two *Features variables.

No, it’s not pretty. Yes, there are <x> different more betterer ways it could be done. It skinned the cat I needed skinned and I’m happy.

UPDATED: Refactored it a bit.

require 'watir'
require 'optparse'

@siteroot = "http://w2k3rs/"
@collectionFeatures = [ "Telligent Enterprise Menu Items",
            "Telligent Enterprise WebParts"]
@siteFeatures = ["SharePoint Integration for Telligent Enterprise",
            "Telligent Enterprise Search Replacement for WSS v3" ]

$options = {}

opts = OptionParser.new 
opts.banner = "Usage: SpiFeatures [$options]"
    
$options[:activate] = false
opts.on( "-a", "--activate", "Activate SharePoint Integration" ) do
    $options[:activate] = true
end
$options[:deactivate] = false
opts.on( "-d", "--deactivate", "Deactivate SharePoint Integration" ) do
    $options[:deactivate] = true
end
opts.parse(ARGV)    
   

$action = "Activate" if $options[:activate]
$action = "Deactivate" if $options[:deactivate]

$browser = Watir::Browser.start @siteroot + "/_layouts/ManageFeatures.aspx?Scope=Site"
$browser.speed = :fast

def toggle_feature(feature)
    $browser.button(:xpath, 
        "//table[@class='ms-propertysheet']//table//table//tr[td[h3[contains(.,'" + 
        feature +
        "')]]]/../../../..//input[@value='" + 
        $action + "']").click
    if $options[:deactivate] then 
        $browser.link(:text, "Deactivate this feature").click 
    end
end

@collectionFeatures.each do |@feature|
    toggle_feature(@feature)
end

$browser.goto(@siteroot + "/_layouts/ManageFeatures.aspx")

@siteFeatures.each do |@feature|
    toggle_feature(@feature)
end

$browser.close

Monday, November 02, 2009

CodeMash 2010 Registration Open!

Registration for CodeMash 2010 is open!

Of course I’m biased, but I think the sessions we’ve got this year are better than ever, and the list of PreCompiler sessions is simply insane.

Keynoters for this year’s conference are Mary Poppendieck, Hank Janssen, and one more amazing guy we’ll be announcing shortly.

Early bird pricing is $175, good through 30 November after which it jumps to $220. The PreCompiler is $75. The Kalahari is offering its usual amazing value prices of $88 for a “Hut” room. This means you can stay three nights, hit the PreCompiler and the full conference, all for less than $600. I don’t think you can find any better value for a conference; certainly not any national level conference!

Go to CodeMash. Just do it.

Wednesday, October 28, 2009

Another Free Event: MS Dogfood II Conference

The good folks at Microsoft’s Columbus office are putting on the second annual Dogfood conference. It’s a FREE two-day event loaded with content on Silverlight, WPF, SharePoint, SQL Server, Exchange, Azure, F#, Windows 7, and loads of other neat stuff.

The conference runs 12-13 November at Microsoft’s Columbus office.

Check out the conference’s agenda and register! (Note that you have to register for both days separately!)

Friday, October 16, 2009

CodeMash Sessions are Live!

If you’re not following CodeMash on Twitter, you may have missed the announcement that the session list for CodeMash 2010 is up.

The selection committee received 450 submissions this year and had an insanely hard time working through them. All 450 were terrific submissions. The committee came up with an awesome lineup!

Registration for CodeMash will open up shortly, and it will go quickly, so be ready to jump and get in line!

Monday, October 05, 2009

Writing a Good Session Abstract

If you’ve got a great idea for a conference session, you absolutely have to spend time getting your abstract right before you submit it. Your abstracts really need to pitch to two separate audiences: the selection committee and the attendees themselves. Work hard to explain the value folks will get from your session.

Here are some thoughts based on my experience writing a few abstracts.

  • Align your content with the event. Is your session even a good fit for the event you’re submitting it to? I’ve only submitted to one national conference, and I had to really twist around my submissions to make them seemingly fit with the conference. They didn’t. I didn’t get selected. One of the organizers (a good pal) specifically called out the lack of fit as the reason other organizers weren’t interested.
  • Avoid overly broad sessions. “Introduction to .NET 3.5” or “Testing is Great!” might be interesting, but generally speaking they’re way too broad to get much value out of in a 60 or 75 minute session. Focus down on some specific items. Instead of a broad testing talk, narrow it to some tools, like Selenium, or mock or unit test frameworks. Speak to something specific in those.
  • Titles matter. Really. Cool titles like “I am MOSS Tester! And You Can Too!” sound nifty, but they’re often going to lose the selection committees and attendees. Sure, make your title catchy, but make sure it showcases what your session’s about.
  • Explain what attendees will get out of the session. Make it clear what your attendees will learn during your session. “You’ll leave this session with a handle on ways to smooth out your project’s environment” or “This session will show you a great system for boosting customer collaboration and increasing your code’s quality” are good examples.
  • Give examples of what’s discussed. Let attendees know what you’ll be talking about. “This highly interactive session will show you three specific tips: improve your estimation, use a daily standup to keep a close focus on your progress, and work in retrospectives.“ This helps the selection committee understand if the content fits in, and it helps potential attendees see they should be skipping that bogus session on Drag and Drop Driven Development to attend your presentation.
  • Show some prior feedback on the session. Have you given this talk before? If so, try and collect some feedback on the presentation. Twitter’s given me some awesome blurbage I reference in my abstracts. “’I think I've learned more about Fitnesse from Jim than anyone else. :-)  It was a great talk -- standing room only.’ Michael Eaton, http://is.gd/2ounG” Items like that, particularly ones you can hit via live URLs, give you immense credibility.
  • Write a concise abstract. The one paragraph of your abstract is like the one spoon tasters get at a chili competition. This is hard to do. You need to work really hard on making the one paragraph highly impactful. Fall right back to your elementary school fundamentals: introduction, body, conclusion. Set a hook with a great opening: “Bugs. Crashes. Malfunctions. Complete meltdowns. We run into difficulties in our work each and every day.” Follow that on with the value propositions to attendees and examples of what’s covered. Finish up with a great closer that will make your attendees’ mouths water, figuratively, at least.
  • Write a coherent abstract. I’ve been on a number of content selection committees, and I see most CodeMash submissions even though I’m not on its selection committee. I’m always amazed at the handful of unreadable, muddled, flat out awful submissions we get. Spend time to make sure your submission is clear. Don’t bother submitting if you won’t take this step. Tough love, but it’s true: incoherent submissions are nearly always immediately dropped from consideration.
  • Edit, re-edit, then get it reviewed. Write the draft, step away from it, come back and edit it later. Several times. Get the abstract out to your colleagues and friends for their feedback. Iterate through this several times.

Your speaker bio is every bit as important as your abstract, particularly if you’re not well-known by the content selection committee. Writing a great bio is a topic for another post, likely by someone else because I’m contrarian and non-conformist with my bios. Just do me one favor: make sure your bio isn’t longer than your submission…

Here’s an example of one of my abstracts. Feel free to borrow, copy, or outright steal it and adapt it as you need.

Title: Leadership 101

Abstract: It doesn’t matter what point you’re at in your career, you need to understand some fundamentals about good leadership. If you’re well into your career you need to know how to get the most out of your teams. If you’re just starting then you need to learn what good leadership looks like – and how to help ensure you’re getting the leadership you and your colleagues need to succeed. In this session you’ll learn basic concepts about respect, responsibility, communication, and teamwork, based on experience drawn from Jim’s years of serving in the military, playing competitive sports, and working in a wide range of jobs.

Feedback:

I knew Jim Holmes was a good speaker, but holy crap. That's a great way to start a day.” Joe O’Brien, http://is.gd/2ovna

“Jim Holmes is a fantastic speaker... Audience is completely engaged in his Leadership 101 talk at #erubycon” Raju Gandhi, http://is.gd/2ovxN

Tuesday, September 29, 2009

Running an Event on the Cheap

I’ve been a part of teams organizing a pretty good number of developer community events here in the Heartland over the last few years. I’ve helped with medium-sized Code Camps / Days of .NET hosting 150 - 200 people across four tracks and I’ve helped with much larger events like CodeMash, where 550 people attend seven tracks plus open spaces.

While those events are really rewarding, they take a significant amount of time and effort to put on. You generally need several people working as a tight team to pull these off. You need a big venue, you need audio visual support, you need food, and you need significant sponsor support to pay for all that. Many times you’re hostage to your venue’s catering services, which means you’ll be paying high costs for mediocre (at best!) food. (Thank God for the Kalahari, where the venue’s food is actually really good.)

Twice in the last year I’ve been part of great events which were a snap to put on: the .NET University last November and the Software Engineering 101 last week. Both these events filled the room (90+ people) and were a great success. Where CodeMash generally has well over $100,000 go through the cash register, metaphorically speaking, both .NET U and SWE101 were put on for less than $500 each.

Here are a few concepts you can use if you’re interested in putting on an event without the tremendous work of a larger event.

  • Leverage your community. First and foremost, you need great contacts in your community to pull these off. Build those contacts, because you’ll be looking to them to help with content, venues, marketing, and finding sponsors.
  • Have a clear vision on the event’s goals. Keep a very narrow focus on what you want to present. One track. Period. Think hard about the audience you’re targeting. We specifically targeted .NET U to folks who were not involved in the community. We blogged and spoke to user groups: “This event isn’t for you – but tell your colleague that’s never been to a community event.”
  • Content is King. Hand pick great speakers to deliver topics lining up with your event’s goals. Make sure they’re on board with the vision and clearly understand what you want them to deliver. Getting their suggestions on what to deliver is fine, but make sure they first understand what the event is trying to do. Remember, one track. You’ll only need four to six speakers.
  • Get a clear schedule early on. Get your schedule nailed down before you press forward. Times, presenters, descriptive titles, short and clear abstracts.
  • Find a free venue. You absolutely can’t do one of these events if you have to pay for a venue. Look to your local Microsoft office, look to community colleges, check with your local business community, check with local training companies. Drive home the idea you’re putting on a free event to improve the skills of your local developer community.
  • Find free AV resources. You need one projector and one screen. If it’s a larger venue you may need two projectors and two screens synched together. Check with community members to see if they have gear they can borrow from their companies. Check with your MS reps. Check with local training companies.
  • Avoid venue catering costs. Many venues with catering services look to make their money not on renting the facility, but by charging you $14 per head for an awful box lunch. Instead…
  • Bring in food and drinks. Line up bagels and coffee from Panera or some place similar. Panera delivers, so that was a big win for me. I paid $300-ish for coffee and bagels for 100 folks. I ran to Target and picked up another $150 of sodas, water, and snacks. (Funyons, FTW!)
  • Skip lunch. Look to a venue with several restaurant/fast food choices near by, then clearly indicate to your audience that they’re on their own for lunch. Leave one hour in your schedule to support folks getting out and back. Attendees of a free event won’t mind running out to get their own food as long as you make it clear from the start.
  • Find a couple sponsors. Reach out to companies that are already involved in your community. You need $500 to support an event for 100 geeks. It’s simple to make a pitch asking for $250 from two companies. Don’t let sponsors come and take over your event, but make sure they get some exposure via logos on slides and frequent mentions during the event.
  • Skip recording. Recording sessions sucks, plain and simple. It’s a hassle, there’s a lot of moving parts, you need special gear, it interferes with presenters, it never turns out as well as you’d hoped, it… The list goes on and on. We’ve tried for years to get recording working at various events, and it’s always been a complete PITA for one reason or another. Skip it.  (Note: If someone with a history of success volunteers to do this, then by all means take them up on it. Just don’t let the recording come anywhere near injecting friction into your speakers’ gigs, or the audience’s ability to get great content.)
  • Find a registration system. Look to something like Microsoft’s community registration system, Microsoft Group Events. Look to Meetup.com. Look to something similar. DO NOT WRITE YOUR OWN SYSTEM.
  • Pimp the event. Get your schedule up on blogs. Get the word out to your own community contacts. If you’re in the .NET world, make sure your Microsoft Developer Evangelists help you spread the word. Reach out to your local business and educational communities. Hit up local media.
  • Expect drop off. Free weekend events have drop off rates of up to 40%. Free weekday events often see over 20% drop off. Accept it. It’s not you. Well, maybe you do need different deodorant.

This list isn’t all that long, is it? It’s all common sense. You can do a great event on the cheap. You can have a whole lot of folks learn some great content and come away all excited and motivated to improve their environments. You can do this without giving yourself an ulcer and losing sleep. Honest.

Go do a neat event. Get people fired up.

Then do more.

Thursday, September 24, 2009

Software Engineering 101 Conference Wrap Up

Wow. 90 or so folks showed up yesterday for an amazing event: the Software Engineering 101 Conference. Everyone seemed pretty fired up, energetic, and happy at the end of the day after hearing Leon, Scott, and Jon cover some great topics.

We went through Object Oriented Programming basics, SOLID software design, code metrics, and production debugging. All these were fundamentals[1] for an afternoon of test driven development in a hands-on workshop environment. Leon, Scott, and Jon delivered some great content and really got the attendees engaged before proceeding into the afternoon workshop.

The afternoon workshop was really, REALLY fun to observe. There was a tremendous amount of energy going on in the room as folks paired to solve the problem given them: part of the rules engine for Greed from the Ruby Koans.

One interesting thing really struck me: how quickly all the attendees jumped in together and got productive in pairs. Pair programming freaks a lot of people out for a number of reasons, so it’s sometimes hard (at least in my corners of the .NET world) to sell.  We never even gave the attendees a choice. We told them in several pre-conference mails that the afternoon would be pairing. Leon fired off the workshop with “Get ready to pair.” Not once did we open the door for folks to work by themselves, and I think it really paid off.

We’re looking at some possibilities for repeating this conference, perhaps even as an online/live session. More news on that if anything comes of it.

This was an awesome day for me, and I’m really thankful that Leon, Scott, and Jon jumped on board when I pinged them. I couldn’t have gotten three better presenters in the Heartland, and that’s sayin’ something because the Heartland kicks every other region’s assets for speakers.

One last thing: many thanks to EdgeCase and Cardinal Solutions for jumping in with sponsorship funds. We were able to get food, drinks, and snacks for the attendees, all courtesy of Joe and Jeff. Many thanks also to Microsoft and Brian Prince for opening up the venue to us.

[1] I had someone remark that Scott’s Production Debugging presentation wasn’t on the same content line as the OOP, SOLID, metrics, and TDD sessions. They were right. BUT! I pulled in Scott because A) his session has a tremendous amount of fundamental material in it, B) He’s an awesome presenter, and C) I wanted to see it and I got to pick the conference’s content. :)

Tuesday, September 22, 2009

Leading from the Front

In my Leadership 101 talk I really harp on the importance of leading from the front, particularly as you get higher up in an organization. I illustrate this with a story of the battle of the Somme in France in World War I. The allied generals were so far from the front they didn’t know about flooding which made it impossible to cross the battlefield in any effective manner. Tens of thousands of casualties resulted in the first day of what turned in to a long campaign. All because the generals lead from the rear, where the environment was completely different.

I just don’t understand “leaders” of an organization who don’t take the time to learn the details of the environment their organizations operate in. How can you lead if you don’t know your environment, your clients, your company, or your people?

The Dayton Daily news had a great article in its Sunday paper on executives and upper level management at Miami Valley Hospital here in Dayton who are terrifically engaged and at the front. Leaders there do four hours of “rounds” a week at the hospital – as doctors do rounds to visit their patients, executives and management do rounds to visit their workers. They also interact with their customers – the hospital’s patients.

This is a terrific practice that keeps the hospital’s leadership in touch with the pulse of their workers and the hospital’s patients. The article, plus its two companions here and here, highlight the great benefits the entire hospital is seeing because of these policies.

Making this sort of effort ensures leaders understand the environment their people are working in. Leading from the front ensures leaders understand the environment the company creates for its customers. Leading from the front ensures leaders are keeping open lines of communication to workers and customers, and are seeing things about their company first hand.

It doesn’t matter if you’re leading a huge company of 70,000, a small company of 150, or a team of three. You’re jeopardizing your success if you’re not consistently and frequently getting out to interact with clients and workers.

Lead from the front. The benefits are amazing.

Wednesday, September 16, 2009

Upcoming Speaking Gigs

I’ve got a couple speaking engagements coming up over the next two months:

  • 23 Sept: Software Engineering 101 Conference. I’m helping organize it and am giving a short grok on tools for monitoring code complexity.
  • 24 Sept: I’m teaming up with Justin Kohnen to talk at the Dayton .NET Developers Group. We’re covering a few of the shiny toys in .NET 4.0 and Visual Studio 2010. It’s also the culmination of our membership drive!
  • 13 Nov: I’m very flattered that I got selected to talk at the Tyson Developer Conference. This is my first speaking gig outside the Heartland district, aside from showing off some cool prototype cockpit systems to a bunch of hung over A-10 pilots in Las Vegas years ago. I’ll be giving three talks there: Leadership 101, Three Tips to Improve Your Process, and Acceptance Testing with Selenium and Cucumber. I’m awfully excited about the opportunity to speak there! (And big props to Phil Japikse who hooked me up.)

Be sure to look me up if you’re at any of those events!

(And if you’re looking for speakers at one of your events, I’d be happy to send you my current list of abstracts, if’n you’re interested.)

music note Now listening to "Polaris" by Jimmy Eat World

Busted “Contact Me” Link Fixed

Doh! I missed the mail that my 2idi wasn’t providing my contact service any more, so the “Contact Me” link on my sidebar hasn’t worked for, uh, more than a couple days.

It’s fixed now, and you can use 1id.com’s service to get in touch with me.

Sorry for the goof, and thanks to the reader who let me know about it!

music note Now listening to "All Too Well" by The Kingpins

Sunday, September 13, 2009

Book Review: Living Green, The Missing Manual

Living Green, the Missing Manual by Nancy Conner, pub by O’Reilly, ISBN 0596801726.

This book can be preachy and a bit breathless in some of its content, but it’s really a fascinating and educational read.

Conner works hard to cover a lot of topics and gives you material on everything from the chemicals you may not know about in your home to alternate and renewable energy sources. Along the way she also covers raising a green family (I raised two kids via cloth diapers and was happy to see them covered), building/remodeling, eating green, responsible shopping, and a number of other topics.

A number of topics were thrown out without enough evidence of whether or not there’s really a basis for concern (the impact of volatile organic compounds offgassing from foam in furniture or dryboard markers, for example), but generally Connor does a very nice job of giving you a good background on the topics she’s writing about. There are also a lot of resources referenced in the book so you’re able to go look at more material from one side of the story, at least.

While there’s a chapter dedicated to “Reduce, Reuse, Recycle,” Brown seems to carry that theme through the book. I don’t know if that was intentional or not, but I found it very helpful to consistently find small reminders of those principles in many of the book’s topics. I’m a proponent of reducing the number of things around me and trying to reuse as much as possible – but I’m nowhere near as good at it as I’d like to be.

Overall I enjoyed the book and found it very useful.

music note Now listening to "Alive" by Off-Kilter

Wednesday, September 09, 2009

Great Discussion Podcast on Deep Fried Bytes

During devLink a few folks from the region’s community were gabbing about a variety of topics, including burnout, motivation, FUD, and a number of other topics.

Keith Elder pulled out his recording gear and ended up capturing some really interesting commentary from a lot of people. You can listen to the podcast on Keith and Woody’s Deep Fried Bytes site. (They’re also on iTunes, so go subscribe if you haven’t already!)

There’s some tongue in cheek references to this being a group therapy session for Leon, but the discussion’s really so much more than that. A number of the community’s most active members offer up gems of wisdom on a wide range of topics.

It was fun to participate in the discussion, and it was fun to listen to. (Much more so than the DNR show which gave me heartburn enough to write about elsewhere…)

music note Now listening to "Date of Rebirth" by Origa

Friday, August 28, 2009

Plz Use Yur Brain. KTHXBAI (DNR #476)

Last Saturday I was lucky enough to participate on a devLink discussion panel on “Has Software Development Gotten Too Complex?” The panel was hosted by, and recorded for, Dot Net Rocks and posted early this AM as show #476. The panelists were Billy Hollis, Kathleen Dollard, Josh Holmes, and me.

We spent a bit of time talking over various topics, then opened up for audience questions. Some of the questions and comments were pretty interesting, particularly those around the vast increase in power we’ve seen through advancements in our technology. We’re far, FAR removed from the days of having to do minutia infrastructure work (as opposed to choosing to do that when we have no other choice).

There was also a very weird undercurrent that quite frankly brought me down. We heard complaints about FrontPage hitting its end of lifecycle, we heard laments about the confusing amount of choices for technologies, we heard complaints about Microsoft “forcing us to use three ‘servers’ for all our applications,” we heard complaints about the lack of plain Notepad-based examples.

The Twitterverse had lots to say on the topic, some supportive, some negative, some exhausted. “DNR” means lots of things, so that results page has lots of chaff. Regardless, read through it.

Here’s some tough love from Jim, folks. God/evolution/whatever built an amazing piece of equipment in your body: a brain. Moreover, that brain has a wonderful, but far too underutilized ability called Critical Thought. Use your brain and Critical Thought. Use them to solve problems. Use them to decide how to stand out above your competition. Use them to figure out how to crush your enemies, see them driven before you, and to hear the lamentation of their women.

Yes, many things in our industry can seem overwhelming at times, but you know what? You are utterly, absolutely capable of dealing with all this. Moreover, you’re likely capable of not just dealing with it, but succeeding – but only if you’re willing to invest in yourself for the long haul.

The harsh reality of our industry is that the vast majority of folks in it aren’t concerned with improving themselves, so just the fact that you’re reading this blog, or attending conferences like CodeMash or devLink means you’ve got a great start.

Take that start and run with it. Get involved with a local user group. Hit more conferences. Expand the list on your regular blogroll. Work hard at your place of employment to carve out time for regular training sessions – and I’m talking on a weekly basis. Lunch and learns are a powerful way for you to ensure you’re keeping in touch with the changes in the industry.

Oh, by the way, I’m not just talking the hard technology issues of what you build, I’m talking about you learning to improve how you build software. Learn about testing. Learn about the *DD du jour. Learn how to improve your processes.

Jesse Liberty wrote a nice blog response with some of his ideas. I enjoy Jesse’s writings and presentations immensely, but I have one huge issue with his suggestions: his ideas are all 100% Microsoft-centric. That’s OK, but we as problem solvers absolutely cannot limit ourselves to using only what Microsoft provides. For example, if you’re evaluating what data access strategy to use, then you’d darn well better not limit yourself to looking at LinqToSql or Entity Framework. You’d better include the much more mature alternatives like NHibernate, SubSonic, or rolling in some variant of the ActiveRecord concept. Furthermore, you’d better be asking hard questions about how any examples or “best practices” coming out of Microsoft fit in to your particular environment.

Use your brain, folks. Turn your discouragement into an opportunity to improve your ability to stand out from the others. Turn that into an opportunity to help your company or organization differentiate itself.

(I’ve written and re-written this post a number of times since coming home from devLink and the panel. I’m still not satisfied with it, but here it is. The lack of clarity in this post is a sign of how conflicted I am about the episode. Sorry, but it is what it is.)

music note Now listening to "Hare Krisna" by Thievery Corporation

Thursday, August 27, 2009

Manually Killing Terminal Service Connections

Problem: You’re trying to RDP to a remote server and you get the message “The terminal server has exceeded the maximum number of allowed connections.” You need to be able to examine current open sessions and kill unused ones.

Solution: Open a command prompt from an account with admin privileges. Use the ‘query’ command to find out who has sessions open on the target system:

C:\Users\jholmes>query session /server:myserver
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 console                                     0  Conn    wdcon
 rdp-tcp                                 65536  Listen  rdpwd
                   schambers                 1  Disc    rdpwd
                   schambers                 2  Disc    rdpwd

We can easily see that someone’s hogging up the sole two allowed connections by logging on, then killing the RDP session while still connected. Nervy.

No matter, I can fix that quite easily with the ‘reset’ command:

C:\Users\jholmes>reset session 1 /server:myserver

This kills the session Now I’m able to RDP on to the server without being blocked by someone who wasn’t cleaning up after themselves…

Tuesday, August 25, 2009

Don’t Move the Table

Last weekend I was at devLink in Nashville. On Thursday I was trying to finish up some work and looked for a quiet spot, so I headed to the then-empty room where Open Spaces would be held the following two days. The room was a chapel at the venue’s campus; a great quiet spot where I could try to focus and get some things done. The room had lots of windows letting in beautiful natural light, and there was a wonderful high, vaulted ceiling with some nice decorative architecture. In short, a great place to get some undisturbed work done.

Up at the front of the chapel was a table with two signs taped on it:

Interesting. I wondered about the rationale behind the signs, but I was in a hurry to get some work done, so I sat down in a different corner and tried to finish up my tasks. In between productive sprints of work, my brain kept coming back to the signs. “Why?” I wondered.

Eventually, I began to think about how others might react to the sign. Being ever-interested in how my community hommies react to various things, I even went so far as to mention the sign to a few folks the next day.

“Hey, the table in the Open Spaces room has a sign that says to not move the table,” I mentioned.

One friend said “The sign says not to move it? I’M MOVING THE DAMN TABLE!”

Another pal said “If I need that space I’m moving the table.”

A third simply said “OK, so we won’t move it.”

All three reactions were somewhat interesting, because none of the three asked “Why’s the sign there?” My first friend, being somewhat wonderfully contrarian in nature, was going to move the table simply because he’d been told not to. The second was going to move the table if he needed the space. The third just agreed to deal with the limitation and move on.

Bear with me, because there’s actually a point here.

Flash back to Thursday and my quiet working time in the chapel. After an hour or so, two workmen came in to the chapel and went over to the area by the table. They were discussing some painting that had to happen, so I sort of tuned them out. My ears perked up, however, when I heard them mention a water leak which had caused significant damage to the structure. It turns out they’d had issues with parts of the extremely high ceiling falling down onto the floor.

The table was placed on that exact spot to block people from standing or sitting there. The “Do not move this table” sign was intended to ensure nobody was injured by falling debris.

One could sit around and argue that the sign was badly written, leaving out critical information (“Sit here and you will DIE!”), or that something else should have been used to block off that area. (Police tape, orange snow fence, flashing lights, Albanian dwarf mimes)

Those arguments are missing the point. The sign made perfect sense to those who wrote it and there was a darn good reason for the sign being there.

We constantly run in to similar situations with the folks we’re building software for. What seems an utter mystery to us is utterly clear to our clients, customers, stakeholders, whoever. Moreover, sometimes there’s something really important behind those things that seem, to us, stupid and incomprehensible. We’re outsiders, and we’re missing the critical context.

Spend the time asking “Why?” with those whose problems you’re trying to solve.

You may save yourself getting schwacked on the head with debris.

Friday, August 21, 2009

Save The Date! Software Engineering 101 on 9/23/09

UPDATE! Registration is open here.

A few great speakers and I are working to put on a unique event on Wednesday, 9/23: Software Engineering 101.

This is a one-day, FREE event targeted to help you build your skills in how you build software. This isn’t about learning the basics of Silverlight, WPF, or </insert_new_tech_of_day>. Rather, this conference will help you understand how to build software that’s better designed, more maintainable, and more testable. We’ll spend the morning on fundamentals around object-oriented programming, the SOLID principles, and a few other important skills. The afternoon will be a hands-on Test Driven Development workshop putting those skills to use.

Here’s what we’ve got on the agenda:

Time Session Speaker
8:15 – 8:20 Intro  
8:20 – 9:30 Principles of Object Oriented Programming  
9:35 – 10:45 SOLID Jon Kruger
11:00 – 11:15 Understanding Code Metrics Jim Holmes
11:20 – 12:30 Production Debugging Scott Walker
12:30 – 1:30 Lunch  
1:30 – 5:00 Hands on Test Driven Development Leon Gersing and others
5:00 – 5:15 Closing remarks  

The event will be at Microsoft’s office near Polaris Parkway in Columbus. I’m working on sponsorships to pay for light food and drink, but that may or may not pan out. Lunch will likely not be provided, but we’ll take an hour so folks can get out to eat at one of the many places in Polaris.

You likely have noticed this event’s on a weekday. I purposely targeted a work day because lots of community folks already give up significant amounts of their weekend time – plus I’m interested in seeing if we can reach out to a new set of attendees who might not otherwise be able to attend.

I’ll have a registration site up shortly, so stay tuned for details on how to sign up.

In the meantime, spread the word and block off Wednesday, 9/23/09 on your calendars!

Tuesday, August 18, 2009

Two Book Reviews

Here are reviews for two books I’ve recently run through.

Stand Back and Deliver by Pollyanna Pixton, et. al. Pub by Addison Wesley, ISBN 0321572882.

This is absolutely one of the best career-shaping books I’ve read, ever. It’s concise, it’s easy to read, and it’s chock full of some seriously vital things you need to get solid in your head as part of successful software delivery.

I found a wide range of great wisdom in this book, some things which were new, and some which were things I'd let slip. There's insight on teams, personnel, risk management, and lots of other goodies. It's all laid out in short, well-written chapters authored by folks who've been around the block a number of times.

While all of the book was extremely helpful, perhaps one of the most valuable things I found was their “Purpose Alignment Model,” (PAM) a simple quad chart with market differentiation on the Y axis and mission criticality on the X. The quads break down in to categories of Who Cares, Partner, Parity, and Differentiating. The authors walk the reader through clear, powerful exercises to help you focus on making decisions that will help you succeed at differentiating you and your company from your competitors – but retaining some focus on things you need to stay in parity with them.

I found all the discussion around the PAM highly stimulating because it fits so well with my fundamental beliefs in being adamant and aggressive about Lean software development. The section on Context Leadership Model is probably just as important: it helps you assess a project’s uncertainty and complexity. Again, the authors do a tremendous job showing you utterly practical, real-world applications of this.

I can’t recommend this book enough if you’re at all interested in improving how you decide what to build, and how you go about it.


The Myths of Security by John Viega, pub by O’Reilly, ISBN 0596523025.

This is a wonderfully contrarian view to much of the information we are fed regarding security. Viega brings a much-needed skeptical view to many of the things we as consumers and workers in the IT industry are fed. He skewers everything from antivirus to identity theft and takes a lot of effort to lay out his propositions around how bad guys are driven by money.

I got a bit weary of the not-quite-shilling for McAffee, the company Viega works for, and there were a couple technical howlers (a server-side application which required 200 servers simply “because it was written in Java”). Those irritants aside, it really is a great read which, whether you agree with his points or not, should make you re-evaluate how you look at security.

Books which make you think are always a Good Thing.

Monday, August 17, 2009

Slides & Thoughts From devLink

I gave my “Three Tips to Improve Your Process” talk at devLink last week. You can find the deck here.

Thanks to the folks who attended! There was a great turnout and I got some great questions from the audience. I’ve already slightly tweaked my deck to reflect some of those questions. Feedback, FTW!

Once again, John Kellar and his crew put on a fantastic conference, and once again, I spent the majority of my time hanging out with my friends in the Open Spaces sessions. (Can we please stop calling it “Open Spaces Technology” already?) I did catch two great “regular” sessions, one being Bryan Hunter’s Lean Workshop and the other Rick Kierner’s TDD in SharePoint.

I also got a much needed lift from a couple close friends who gave me some good feedback and tough love. Plus, I got to sit on a Dot Net Rocks panel discussion with some neat folks. (Separate post on that soon.)

The 12-hour round trip drive was greatly sped by having Leon in the car and I’m fairly sure we solved sixty or eighty problems including the Golbach conjecture, the Higgs mechanism, and a host of other pressing problems. Culture change in people who actively resist change thwarted us, but we did finally figure out we need to stop giving those people power over us.

Overall, it was an awesome trip. I’m looking forward to returning to devLink again next year. After all, it is the region’s second best conference. (We all know what the region’s best conference is!)

Monday, August 10, 2009

eRubyCon Slides & Summary

I was at eRubyCon this last week, courtesy of Joe O’Brien and the great folks at EdgeCase who invited me to speak.

This was my first conference outside the .NET arena in years (excluding CodeMash) and I’m kicking myself for not doing this more often. I got some great insights on different ways to solve problems, and I met some amazing folks who inspired me to get to work on fixing a few things in my life that need addressing. I also got fired up about a few neat tools and some changes to our environment at work. (CodeMash is awesome for this, but as an organizer I get little or no time to actually participate in it.)

I gave my Leadership 101 talk as the first session of day 2. This is the second time I’ve given this talk, but it was in a completely different format than the 20 minute talk I gave at KalamazooX. KalX was amazing (and I hope I get invited back there!), but the longer format of eRubyCon gave me a chance to flesh out a few points. I also mixed in some examples from my background to lend some detail and color.

I always feel weird talking to a crowd about leadership because I don’t pretend to be a master of it, but the audience there was wonderful to speak to, and I got some nice feedback.

The slide deck is my usual funky style: 14 slides total, two pictures, one number, and (aside from the opening quote) six words total, three of which are repeats. There are even a couple blank slides just because. The deck’s here and there are some notes on it, but the best resource is really the Leadership 101 blog series that inspired the talk.

eRubyCon has been one of the best conferences I’ve ever been to. I’m definitely attending next year regardless of whether or not I’m on the speaking docket. It was an awesome weekend!

Tuesday, July 28, 2009

Looking for a QA Job? Come Work for Telligent!

UPDATED: It’s now December, 2010 and I’ve got another open position on my team! Everything below still applies. Contact info is at the bottom, or use the link on the blog’s sidebar. I’d love to talk with you if you’re interested!

Telligent is expanding our QA/testing team and we’re starting the process of looking for passionate, detail-oriented folks who might be a fit for the team. You’ll be working for me in my new role as the QA Team Lead, and you’ll be testing our neat products like Telligent Community, Telligent Enterprise, Telligent Analytics, plus a host of cool add-ons like our Mail Gateway and SharePoint integration products.

I don’t have a formal job description yet, but frankly, most job descriptions stink or don’t match reality.  Here’s my unofficial, completely unapproved description of what you’ll be doing:

  • Working hand-in-hand with our Product team to create testable acceptance criteria for each new work item (feature, user story, bug ticket).
  • Developing automated test suites using a number of tools like Selenium, Watir, Cucumber, and Visual Studio’s web test.
  • Creating, updating, and executing test plans for all our products.
  • Creating and updating matrices for supported platforms, then executing test plans against those. (You’ll be helping stand up and maintain those platforms in various virtualization environments.)
  • Working hard to exercise the systems through exploratory testing.

Below are some of the tools we’re using or exploring in our QA work right now. I’m all over using any tool that will bring value to our work, so if there’s something you’ve had success with then let me know.

  • UI testing: Selenium, Watir, possibly VS web test
  • Languages: C#, Ruby
  • Other cool toys: Cucumber, PowerShell

What you’ll need to bring to the table:

  • A detail-oriented mindset.
  • Passion about improving quality.
  • Passion about improving yourself – what else are you doing other than reading my blog?
  • Excellent communication skills in e-mail, written documentation, and verbally.
  • Critical thought. Talk to me about how you approach problems.
  • Patience and a pragmatic outlook. I plan on changing the world, but it will be a long haul. We’ll lose occasional battles but the war will be won. Fill in other over-used clichés here.

Notice I didn’t mention much about specific skills? What you’ve got in your head and heart are far more important to me. That said, it would be helpful, but not required, if you’ve got some exposure to the following:

  • Software development experience. Something .NET-ish best, other languages are fine too.
  • Experience with SQL Server 2005 and/or SQL Server 2008. (Exposure to SQL of any type helpful.)
  • Understanding of software development lifecycle.
  • Exposure to Lean and Agile development. (If you’ve decided neither of those disciplines are of value then please look elsewhere for an environment that will make you happy. I’m emphatic about both and you won’t be a good fit if you’ve looked Lean and Agile over and don’t care for them.)
  • Previous experience in a QA role.

Telligent’s located in Dallas, but we have remote workers scattered all over the country and a few overseas as well. I’m happy to work with remote folks, but you’ll need to demonstrate that you’re able to be productive from a home office.

You’ll be working for me, so you may want to do a little digging around the blogosphere, Twitter, and the region’s dev community to see if that’s for you or not. I’m strong coffee with strong opinions that I’m happy to change when a well-thought debate is put forth. I care deeply about my work and I care even more deeply about my teams. Look up some folks who’ve worked for me or with me and get their opinions. (Steve, James, Brian, Todd, Nate, Sean, Dave, Leon) I didn’t ask them if it was OK, but I think you’ll get varied, honest feedback from them. 

Still interested? Drop me an e-mail with your resume: JHolmes AT Telligent DOT com. Feel free to drop me a note via the contact link on the blog’s sidebar, too.

Tuesday, July 21, 2009

Is Software Engineering Dead? (Process, not Construction)

Tom DeMarco, author of the seminal book Peopleware has written a short, interesting article Software Engineering, An Idea Whose Time has Come and Gone?

DeMarco’s article is really around engineering as it refers to controlling the process of creating software, not the actual software construction itself. The article’s short and doesn’t start any in-depth discussion, but the general point is awfully good: working too hard to control the process of software construction is a bad thing. A great quote from the article:

For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

We can’t use this as an excuse for being sloppy with our clients’ time or money, be those clients internal or external. That said, the points DeMarco makes line right up with my own beliefs:

  • As an industry, we suck at estimation. Badly. The problems we solve are similar, but nearly always different from each other.  We make little or no effort to keep a good history of our estimates’ accuracy, nor do we do much to train folks on estimating.
  • Because estimation is a time sink, use velocity for projecting project pace and what you can build within the client’s budget. (Get your work item granularity small, though!)
  • Value is delivered to clients by creating software, not managing the project. Project management’s critical, but it needs to be a light hand. Oversight and correction versus harsh controls. (That means you’d damned well better spend a lot of time building great teams that are good enough to manage themselves, by the way.)
  • Value is delivered to clients by being flexible enough to change what you’re building in order to meet the clients’ changing environment. (Or the clients’ evolving needs as their understanding of the business problem evolves.)

DeMarco’s article is way too short, and I really wish he’d provided more detail on the metrics and measurements he’s decrying – but I think there’s some good conversation starters there.

Monday, July 20, 2009

Upcoming Speaking Gigs

I’ve got a number of upcoming speaking gigs through September:

Let me know if you’re going to be around for any of those meetings!

Friday, July 17, 2009

Book Review: Beautiful Security

Beautiful Security, ed. by Andy Oram and John Vega, ISBN 0596527489, published by O’Reilly.

Like O’Reilly’s Beautiful Teams, this book’s a series of essays by industry experts, this time focused on security. The various authors do a great job of covering topics from social engineering to forcing firms to focus on security. The chapters are all well-written, although a few do better jobs of keeping the material interesting and flowing.

You’ll find plenty of security-related history in the book. Phil Zimmerman’s chapter on PGP’s Web Of Trust is one example. Pieter Zatko’s discussion of his work on the LH0phtCrack is another. Both stories help expose mindsets which, sadly, haven’t changed a whole lot.

Security, as with testing or overall quality, is at its most fundamental roots a culture issue. Not every story focuses on this aspect, but pointing out bad culture is a common theme through many of the chapters. Zatko’s discussion of “Learned Helplessness,” John McManus’s Security by Design, and Jim Routh’s Forcing Firms to Focus are all great reads on this line. Many of the stories correctly emphasize that security isn’t just about someone hacking code – it’s a much broader issue.

As with any good security book, there’s plenty of well-done content which will likely scare you in to re-thinking how you and your company approach security. Beautiful Security can help you identify practices, problems, and mindsets which leave you, your company, or your clients at risk.

Overall it’s a very useful, highly readable book on a critical subject.

Thursday, July 16, 2009

Book Review: The Nomadic Developer

The Nomadic Developer by Aaron Erickson, published by Addison Wesley. ISBN 0-321-60639-6.

If you’re in the software consulting business, or considering going in to the consulting business, then you really, really need to read this book. It’s chock full of things too many consultants don’t stop to think about before joining consulting firms, or don’t pay attention to once they’re in.

Erickson does a great job covering critical issues like why one would consider going in to consulting, culture profiles of typical consulting companies, critical business aspects of consultancies, and a number of other things I wish I’d known before joining a couple of consulting firms I’ve worked for. Erickson’s writing style is clear, concise, and entertaining. He’s also pulled in a number of “annotators” who provide excellent counterpoints and additional insights throughout the book.  There’s also one chapter of short articles by experienced consultants like Ted Neward and Bruce Eckel.

While all of the book is highly useful to readers in the consulting line of work, several topics stood out:

  • Understanding critical concepts like sales pipelines, revenue, and margins
  • Learning how to ask questions during an interview, and learning which questions to ask
  • Figuring out how to survive and thrive at a client and at your consulting company

This book isn’t just for folks in the consulting line of business, it’s also good for independents. Moreover, the career, business, and interviewing advice are great reads for anyone, regardless of the sector they work in.

Wednesday, July 01, 2009

Book Review: The Manga Guide to Physics

The Manga Guide to Physicsby Hideo Nitta and Keita Takatsu. Published by No Starch Press, ISBN-10: 1593271964.

This book is an awfully fun, highly educational read. My last involvement with physics was 30 years ago in high school when I sat in the back row of Mr. Davis’s classroom with my best friend Ernie Fatta. I was more interested in trying to flirt with the pretty girl who sat near us, plus math wasn’t my strong suit, so I didn’t get much out of the course. Go figure.

This book uses a story line to expose readers to fundamental physics concepts like Newton’s Laws of Motion, vectors of force, and kinetic energy. A patient physics geek walks the main character through the concepts using practical demonstrations with tennis balls, bodies, etc.

All the concepts are laid out in very clear fashion, and the examples are really spot on and understandable. There’s math involved, but it’s kept at an understandable level and is presented in very short, progressive steps.

This was a really enjoyable read – and it was even educational. I loved the format and I really appreciated the effort and thought that went into laying out the material in such a clear fashion.

There’s an entire series of these Manga Guides covering everything from molecular biology to databases. If the others are as good as this one then I’d be happy to read them too!

Book Review: The Economics of Iterative Software Development

The Economics of Iterative Software Development, by Walker Royce, et. al., published by Addison-Wesley, ISBN 0321509358.

This is a lean book (small size, only 170 pages) which attempts to help managers and decision makers move to iterative approaches over waterfall.  The book’s well written and has some good, thought-provoking discussion in it.

You won’t find discussions of specific methodologies in this book, but you will find repeated emphasis on critical concepts like delivering running systems over useless documentation (not ignoring documentation, mind you, but delivering the right amount of it). Doing the right amount of planning at the project’s start is also emphasized: avoiding over-architecting and big design up front.

It struck me that much of the authors’ definition of “iterative” development is subtly scattered around the book. It’s not always In Your Face, and that’s actually OK because you’re able to better focus on their deeper points.

The economics part of the book’s title comes through some good discussion on ensuring you’re delivering business value, plus an entire section on measuring your project’s success. There’s good discussion in those sections to help you understand opportunity cost (if I do this, what else am I unable to do?), net present value, and a great example on prioritizing features based on their value to the business.

Some things in the book are a little vague for my tastes, but the authors did a nice job of keeping the book brief, concise, and on target.

Overall it’s a very good, useful read.

Thursday, June 11, 2009

Slides Posted for “Three Tips to Improve Your Process”

Last night I gave my “Three Tips to Improve Your Process” talk at at the Cincinnati Software Process Improvement Network (SPIN). There were some very good discussion-provoking questions – always good for me tuning up my talk for the next time!

The latest iteration of my deck can be found here.

Books I mentioned in the talk:

Thanks to the great folks at SPIN for letting me talk!

Monday, June 08, 2009

Book Review: Beautiful Teams

Beautiful Teams, by Andrew Stellman & Jennifer Greene. Published by O’Reilly, ISBN 0596518021.

This book’s a good read and a nice addition to your bookshelf, although its uneven writing style and fractured voice detract from some great tidbits.

Beautiful Teams is a collection of interviews and essays by various folks in and around the software industry.  Each chapter is a great interview with folks like Steve McConnell or Scott Ambler, or an essay-like article from Mike Cohn or Corey Doctorow. Chapters are slotted into broad sections dealing with individuals, goals, practices, obstacles, and music – as in how parallels can be drawn between musicians in a band and members of software teams.

The uneven writing style and fractured voice can be somewhat expected since each author wrote their own articles, but tighter editing could have really polished up the chapters and made the book more cohesive. The tone of many of the articles made it seem they were drawn directly from the authors’ blogs – another point for having had some tighter editing. I also wished that each chapter had an introduction/bio about the author. While these people are supposed industry leaders, there were quite a few authors I wasn’t familiar with, so I was left wondering what their accomplishments were that made them a target to get in the book.

Complaints aside, I got very good value from reading the book. The wisdom in several articles around dealing with team dynamics was exceedingly useful, and I also found it good backup to read industry leaders pointing out it’s important to move poor performers or negative influences off teams.

Several chapters really stood out for me: Grady Booch’s interview on creating team cultures, James Grenning’s article on implementing extreme programming (XP) in a heavily bureaucratic shop during XP’s early days, and Steve McConnell’s interview about improving team skills, morale, and practices.

Booch’s interview really struck home due to his discussion of working on geographically distributed teams. I’m a remote worker and am far away from everyone I work with at Telligent, so this was particularly interesting to me.  Booch’s comments on the importance of trust between team members and dealing with cultural issues really struck home – he emphasized that technology isn’t the limiting factor on poor-performing distributed teams.

Greening’s experience pushing for change was a great read. The tone and style are clunky, but the content’s gold. Greening was learning XP in its earliest days and worked hard to get an XP team going on a project in a very tight-laced, policy-ridden company. The number one takeaway from me from this article was something I’m already a huge believer in: culture change will utterly fail if you don’t have management and leadership that actively supports the change.

I’ve yet to read anything from Steve McConnell that wasn’t ridden with great wisdom, and his interview in this book certainly kept that tradition.  His points on helping establish a team identity were highly useful. I loved his commentary on the asinine failure (my words) of companies to budget funds for team and morale building. It makes no sense that companies will spend millions on payroll, yet do nothing to build and grow team morale.

Overall I’ve really enjoyed reading this book. It’s one of the few I’ll keep around on my bookshelf.

Thursday, May 14, 2009

Book Review: Making Things Happen

Making Things Happen: Mastering Project Management by Scott Berkun, pub. O’Reilly, ISBN 0596517718.

This book’s been enjoyable and useful to read. There are some sections which didn’t give me a lot of value, and I think some hard trimming to shorten the book’s length would have been useful, but overall it’s been a positive addition to my bookshelf.

I don’t line up 100% with Berkun’s approach to project management – he seems to be  heavy on loading up on extensive documentation up front, and he’s seemingly tepid about specs being a conversation vehicle between stakeholders and developers. I’m adamant that specs need to evolve with the stakeholders, analysts, devs, testers, and other team members being active participants in the process.

Those nits aside, I got great value out of a number of Berkun’s chapters, particularly those around leadership and trust, decision making, and recovering when things go wrong. He’s also got exercises at the end of each chapter which help get thought-provoking juices flowing.  Additionally, there’s a lot of small, useful details in this book as well, ranging from writing good e-mails to advice on running meetings.

Overall it’s been a good read and I’d happily recommend it.

Tuesday, May 12, 2009

Book Review: Implementing Automated Software Testing

Implementing Automated Software Testing by Elfriede Dustin, Thom Carrett, Bernie Gauf. Addison-Wesley. ISBN 0321580516.

This book isn’t for everyone, but everyone can get some value out of it. What I mean by that rather confusing statement is that folks working in Agile environments will likely want to throw the book across the room while folks in more bureaucratic environments like CMMI or other waterfall environments will likely get a great deal of value from the book.

I’m an Agile fanatic and I had a difficult time dealing with book’s approach which emphasizes spending large amounts of time creating documentation such as requirements traceability matrixes, detailed test plans, etc. My preferred approach is to have testers working side-by-side as part of a team, creating specifications from user stories/requirements and moving those right in to automated test suites via tools like Selenium, Cucumber, or RSpec.

That said, I did indeed get some good value from the book. I found the discussions on making hard evaluations on what to test very worthwhile reading: teams can easily vaporize large amounts of time creating large suites of brittle, unmaintainable automated tests. This book has several really good chapters on using business cases to drive return on investment (ROI) decisions for testing, understanding automated test pitfalls, and adjusting your testing as you progress through your project.

Additionally, one of the book’s high points was on building the test team: “Put the Right People on the Project – Know the Skill Sets Required.” This is a great chapter which emphasizes starting the search by focusing on how to interview test team members – and how those testers’ skills are greatly different than other members of the team.

The book’s very academic, dry tone makes for some difficult reading, and few concrete examples are used until very late in the book. Having spent a large number of years either in the DOD or working for DOD contractors, it quickly became apparent that much of the book seemed targeted to folks working in those environments – too many dry acronyms are scattered through the book, adding to the difficulty in reading.

The lack of examples using real tools frustrated me. While the appendices contain some examples of comparing various tools, the book doesn’t actually show how a real world testing environment would use those tools. One appendix, eight or nine pages in length, is touted as a “Case Study” but falls short, in my opinion.

Overall it’s a decent book. The dry tone and lack of real environments is balanced out by the excellent coverage of team skills and emphasis on selecting how and what you test.

Friday, May 08, 2009

.NET Work in Frederick, MD

Normally I don’t use my blog as a venue for job postings, but this one’s for a rather unique opportunity.

My wife works for Syracuse Research Corporation, a great company based out of, wait for it, Syracuse, NY. The company targets support and research work for the Department of Defense, and I’ve really, REALLY liked what I’ve seen for their culture, leadership, and employee support. If you’ve read my blog much then you may know how critically important those three things are to me.

They currently have an opening for a .NET person in Frederick, Maryland. The position requires a Top Secret/SCI clearance, so it’s a tough billet to fill.

If you’re in that area, or are willing to relocate, I’d encourage you to have a look at the job’s description. If you’re interested, contact me (see link on sidebar) and I can put you in touch with the right folks.

Friday, May 01, 2009

Dayton Code & Coffee, Tuesday 5/5

Following the neat idea of the Columbus Code & Coffee, Chris Schroll, Derek Hubbard, and I are going to meet up at the Panera Bread at Fairfield Commons on Tuesday, 5/5, at 8:00 am.

We’re thinking of working through some of the Ruby Koans from the geeks at EdgeCase, or maybe having a look at Sean Chambers’ SOLID stuff out on Git.

Stop by if you’re interested in gabbing about code or pairing up. Don’t worry about your skill level – just bring some interest!

Remote Retrospectives with Twiddla

I’m a big fan of retrospectives for teams. Retrospectives smooth out bumps in your team’s environment and it gives everyone a sense they’ve had a chance to air their gripes – or offer up praises, even!

Retrospectives for remote teams can be tough, simply because so much value for retrospectives is gained through the interaction of folks in a room. At Telligent the team I’m on is four guys scattered between Ohio and Florida. While I’d really like an excuse to travel down to see Sean near Jacksonville, that won’t quite work.

At yesterday’s retrospective we gave a shot at using Twiddla as a retrospective board. Twiddla, coupled with Tokbox for video/audio, turned out to be a great no-friction solution as a place to put our Good/Bad/Confusing topics. It was also stupid easy to move those topics around as we did our organization phase.

The red/yellow/green dots were my addition after we’d moved and voted on things – I realized that we didn’t have a way to remember which topics were in which category. (Green for good/Red for bad/Yellow for confusing) I think next retrospective we’ll simply preface each topic with G/B/C to keep those straight.

We had a great retrospective, and it was in part because we found a tool that didn’t get in the way. Low-friction, usable tools, FTW!

Wednesday, April 29, 2009

Challenge to MS Evangelists: Real Examples. Tests, Even

For some time I’ve been giving Jeff Blankenburg, our region’s Microsoft Developer Evangelist, a good-natured ribbing over the lack of tests or real-world architectures or design in his demos. This isn’t just a problem I have with Jeff, it’s a problem I have with our community of speakers in general, both inside and outside Microsoft.

Here’s the gist of my gripe: Our industry’s in an awful place right now regarding how we use the tools/platforms/whatever that Microsoft delivers. Don’t believe me? Brush up on software design patterns and practices (read Uncle Bob’s Clean Code or Bill Wagner’s Effective C# or McConnell’s Code Complete), then take another look at how you write your own code. Go look at various open source projects. Look at the examples and guidance that come out of Microsoft. Rethink how the last 100-level “Intro to <X>” session you saw was presented.

Take a look at a number of those and maybe you’ll see my point: We’ve got way too many examples and demos from way too many smart folks and groups which show zero tests or awful implementation practices. The 100-level introductory presentations we see at way too many user groups and code camps do nothing to help us software engineers decide HOW we should implement something.

Changing this situation requires a concerted, long-term effort on many parts:

  • User group leaders and conference organizers should start demanding this of folks presenting at their events
  • Speakers need to step up to the plate and speak to the real world sharp edges of implementing the latest, greatest tool or technology
  • Attendees at these events need to lose their apathy and get engaged. Demand better from speakers: “How would you test that? How does that fit in a real implementation? What lessons have you learned from solving problems with this?”

I understand the perceived difficulty of trying to get a topic introduced in a clear, understandable fashion while trying to show that topic’s real world implementation. Too bad. Step up to the plate and re-think how you’re doing your presentations. Scale back scope. Rethink how you demo things. This issue can and must be solved.

As part of this, I want to offer up a challenge to Microsoft evangelists anywhere, not just Heartland, who are presenting to companies, user groups, or events: step up to the plate. Speak to how the tools, frameworks, or whatever need to fit into the real world. Show tests. Show the hard edges. Encourage your audiences to use critical thought in fitting these technologies into their environments.

Why am I singling out MS Evangelists? Simple. Scalability. MS Evangelists speak to a huge number of folks in any given month. That’s their job.  I do four, maybe six presentations in a year (mostly because I suck, but that’s beside the point). Jeff Blankenburg  did seven gigs last month and 20 over the previous three.

Like it or not, what comes out of Redmond is too often taken as gospel. Bad examples or demos which show zero tests or have everything including data access wrapped up in a code behind are far too prevalent.  This isn’t anywhere near Microsoft’s fault – folks who blindly take those examples as gospel are failing to use any critical thought.  I’ve had long discussions with my pal Leon about this, and we even drew poor Mike Wood into the discussion when he was trapped in a car with me and Leon for nine or ten hours on the way to and from the Kalamazoo X conference last weekend.

Here’s the meat and potatoes of my challenge: I’m willing to step up to the plate with something on my side: Cold, hard cash. During the months of May, June, and July, I’m offering to donate my entire monthly discretionary spending budget of $200 to charities of your choice if you’ll meet my challenge.  Here are the rules:

  • Present at an event, company, or user group
  • Show a demo which includes unit, integration, or feature tests
  • Show a demo where you lay out real-world implementations with a solid architecture
  • Discuss pros and cons of the technology you’re presenting on

Do that, then mail me (contact info on right sidebar) a summary of your talk.  I’ll write out a check for $20 to your favorite charity.  I’ll do that each time until I’ve spent all my discretionary allowance for that month. That’s ALL my blow money for the next three months I’m putting on the line. No saving for the new home server I need. No beers after my .NET user group meetings. No purchases of MP3s from Amazon.com. No purchasing coffee beans to roast once I run through my remaining stash of unroasted beans.

Terms and conditions: Don’t be a nitpicker. Assert.IsTrue(true); isn’t the kind of test I’m talking about!  Make a solid effort to at least show some good tests. I don’t expect perfection, but I do expect a good shot.  No more than three contributions per evangelist per month.

Don’t get started on how this is only one tiny piece of the puzzle, or how we shouldn’t rely on Microsoft to do all our thinking for us, or … <insert_fave_argument_here>. I’m all over all those issues.  However, changing our .NET industry will take time. This is just one small kick in the rear to try and get that change happening a bit faster.

Wednesday, April 22, 2009

Nice Acceptance Test Framework: Cucumber

I’ve spent some time over the last month fooling around with using Cucumber to write some acceptance tests for bits and pieces of the next version of Community Server. Cucumber’s great advantage is its lovely expressive grammar – a clear grammar for testing is critical to my view because it helps ensure developers, analysts, and the customer are all on the same page with how the system should behave.

For instance, we need to ensure a role has the appropriate permissions set for it. In this case, the Site Members role, by default, has 25 separate permissions assigned to it:

I could write up a Selenium test to navigate through all this and do individual assertElementPresent or some variant on each one of those, but that would be time consuming and frankly, the test report wouldn’t be all that clear, even if I used good names for the Selenium test suite and individual cases like I do for other tests:

Flip this around. Imagine that the person owning the feature can write a simple text file with contents like this:

Feature: Default Member Permissions in a Public Open Group
  In order to ensure the system is properly secured
  As a site administrator
  I want to check that roles are assigned 
    the correct default permissions for Public Open Groups
  
  Scenario: Check default permissions for the Members role
    Given I created the PermTest group as a Public Open group
    When I examine the Members role for the PermTest group
    Then the total number of Granted Permissions should be 25
    Then Granted Permissions should include Blog - Create Comments
    And Granted Permissions should include Blog - Read Posts
    And Granted Permissions should include Forum - Attach Files Locally
    And Granted Permissions should include Forum - Attach Files Remotely
    And Granted Permissions should include Forum - Create New Threads
    And Granted Permissions should include Forum - Post Replies

That snippet clearly states the goal of the Feature, plus it gives an exact scenario to test with a specific Given/When/Then set of conditions.

I can use Cucumber to run that clear language snippet through a framework and run tests against each of the “Then” conditions laid out above. (Code below) I’ll get a nice output with familiar colors (red, green) for the state of my conditions:

To me, this is just huge. I’ve got a specification written by someone who understands WHAT the system is supposed to do and HOW it’s supposed to behave. I can do a number of very cool things with that spec. First off, it can and should live in the source control repository where updates can be versioned. Secondly, I might be able to link to that item in source control from whatever project management tool I’m using – why duplicate that text in a project system when I can pull it straight in from Subversion, Git, etc. ? Finally, that expressive language is a thing of beauty for crossing the communication/understanding barriers between devs and feature owners/stakeholders.

My level of excitement around this is very, very high, in case you haven’t figured that out already.

Here’s the details of the implementation behind that spec above.  First off, you obviously need the Cucumber framework. Secondly, you’ll need Ruby.  There’s some C# examples in Cucumber, but I’ve not fooled with C# yet.

The spec above is written in plain text and saved as “MemberInAPublicOpenGroup.feature” in a unique folder.  We’re going to use Watir to handle this test, so in a folder called “support” we’ll need to have an “env.rb” file which is responsible for firing up our Watir IE instance and doing a bit of work:

require 'spec/expectations'
 
#require 'firewatir'
#Browser = FireWatir::Firefox
require 'watir'
Browser = Watir::IE
 
# "before all"
browser = Browser.new
 
Before do
  @browser = browser
  @browser.speed=:zippy #for Watir with IE only. Also try :fast
end
 
# "after all"
After do
  @browser.link(:text, "Log Out").click
  @browser.close
end

Note that I’ve got two lines referencing Firewatir commented out. I’m able to easily switch back and forth between browsers without altering my test code!

Cucumber expects the actual implementation code to follow that convention: step_definitions\<FeatureName>_steps.rb. We’ll write the actual test code in a file called “MemberInAPublicGroup_steps.rb.”

require 'spec/expectations'
 
Given /I created the PermTest group as a Public Open group/ do
    @browser.goto "http://localhost/csfunctionaltests"
    @browser.link(:text, "Sign in").click
    @browser.text_field(:id, "ctl00_bcr_ctl03_ctl07_username").set("admin")
    @browser.text_field(:id, "ctl00_bcr_ctl03_ctl07_password").set("pa$$word")
    @browser.button(:id, "ctl00_bcr_ctl03_ctl07_loginButton").click
    @browser.link(:text, "Control Panel").click
    @browser.link(:text, "Group Administration").click    
end
 
When 'I examine the (.*) role for the PermTest group' do |roleName|
    @browser.link(:text, "Dashboard").click
    @browser.link(:text, "Group Administration").click
    @browser.link(:xpath, "//div[@id='Common']/div[3]/div/table/tbody/tr/td[1]/div/table/tbody/tr[2]/td/strong/a").click
    
    
    @browser.span(:xpath, "//span[text()='PermTest']").click
    @browser.button(:xpath, "//input[@value='Edit']").click
    @browser.link(:text, "Permissions").click
    @browser.select_list(:id, "ctl00_ctl00_ctl00_OuterTaskRegion_TaskRegion_TaskRegion_TaskRegion_ctl02_ctl02_GroupRoles_RoleList").select(roleName)
end
 
Then /^the total number of Granted Permissions should be (\d+)$/ do |numGrantedPermissions|
    selectListItems = @browser.select_list(:id, "ctl00_ctl00_ctl00_OuterTaskRegion_TaskRegion_TaskRegion_TaskRegion_ctl02_ctl02_GroupRoles_listGrantedPermissions").getAllContents.length
    selectListItems.should == numGrantedPermissions.to_i
    
end
 
Then /^Granted Permissions should include (.*)$/ do |permissionName|
    @browser.element_by_xpath("//select[@id='ctl00_ctl00_ctl00_OuterTaskRegion_TaskRegion_TaskRegion_TaskRegion_ctl02_ctl02_GroupRoles_listGrantedPermissions']/option[text()='" +permissionName+ "']").should_not be_nil
 
end

The main parts here are the blocks for Given, When, and Then. Cucumber looks for those blocks, then grabs the regular expressions after those keywords. Matching blocks are executed and asserts/expectations are checked. Passing expectations means the item is written back to the screen in green; failures in red.

Keep something in mind here: This particular _step and feature is using Watir to test at the UI level. There’s no reason whatsoever that you couldn’t use this tool for testing at the integration or even unit level. Joe O’Brien, wicked smart guy driving EdgeCase around, said via Twitter that they’re using Cucumber at all sorts of different levels in their testing.

There are some cons to consider: you can still have an implementation disconnect if the dev writing the _steps file does something wrong. If you’re at the UI level then you’re also hostage to the pains of Selenium, Watir, Firewatir, etc. I continue to run into troubles with timing, but I’m working around those.

One tip: When you’re first starting out, add a line in your scenario which should fail. When you run the feature through Cucumber you ought to see a red line. If not, you’ve goofed up something in your step implementation. I learned this the hard way…

Use something like this

Scenario: Check default permissions for the Members role
  Given I created the PermTest group as a Public Open group
  When I examine the Members role for the PermTest group
  Then the total number of Granted Permissions should be 25
  Then Granted Permissions should include Blog - Create Comments
  And Granted Permissions should include Blog - Read Posts
...
  And Granted Permissions should include THIS SHOULD FAIL

to generate this:

This has saved me some time after some initial self-inflicted wounds.

I’m still evaluating this, and I’ve not wrapped it into any automated builds or CI reporting process. I’ll pass on updates as we continue to explore this.

Subscribe (RSS)

The Leadership Journey