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.)

Now listening to "Hare Krisna" by Thievery Corporation

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…

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.

Registration Open for SWE 101 Conference!

Go sign up now for the Software Engineering 101 conference.

What is the SWE 101 conference? Go read my previous post on it!

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!

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.

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!)

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!