Widgets July 2010

The End of the Chow Line

By Nick at July 29, 2010 12:55
Filed Under: Leadership

There is a very strong and steadfast rule in the United States Marine Corps:  Officers go to the end of the chow line.  No self-respecting Marine officer would ever think about getting in the chow line ahead of his troops.  He’ll make sure that every single guy, from the lowest Private up to his own Lieutenants get fed before he takes a bite.  It’s only right – rank hath its privileges, but rank also ensures that the men are taken care of before he is.

This is a tradition as old as the Marines.  One of the primary responsibilities of a leader is to see to the “health and welfare” of those under him.  The needs of the leader should be secondary to the needs of the troops.  Troops that see you at the end of the chow line know that you are placing them above yourself.  They’ll follow you. They know that if you are wise enough to let them eat first, you are wise enough to take care of them in other areas. Officers that “pull rank” and barge to the front are saying “I’m more important and I don’t care about you.”.  People don’t want to follow that kind of “leader”.

This same attitude can – and should – translate over to the “regular” world.  Do you have a better, more powerful computer than your guys?  Did you take the first widescreen monitor for yourself?  Do you order in sandwiches for the executive team when they meet over lunch, but don’t do the same for your team who work evenings and weekends?

A leader should ensure that his team has the best equipment.  As a manager, you are mainly doing email and web surfing, with maybe the occasional spreadsheet.  For those of you in the software development business, your developers are doing builds, running complex IDE’s and debuggers, etc.  That is, they are doing the things that require processing horsepower.  If you are taking the hot new machines and the big monitors because “I’m the boss”, well, you are jumping the chow line.  The productivity of your team, not to mention the morale boost from seeing that you put their needs above yours, are well worth you working with an adequate machine. 

So you want to be a good leader and have people follow you and be part of the team?  Get at the end of the chow line.

Getting a Router in Another Room

By Nick at July 27, 2010 07:19
Filed Under: Tech Stuff

If you are like me, you have some form of high-speed internet coming into your house. You probably have Cable or DSL or something else, and then a “main” router where there the Internet comes from “out there” to “in here”.  You probably then have it served up with a wireless router.  Me?  I have Comcast cable piped into a NETGEAR WNR2000 Wireless-N Router. From there, I send the wires out to three computers in the room for my wife and kids.  I then use the wireless with my notebook around  Works pretty well.

But I have an office upstairs, and I wanted to put a server up there as well as a notebook on a desk for my use.  That’s two computers.  Now the notebook has a wireless care built in, but the server doesn’t, and I loathed the idea of putting a wireless card in a desktop.  I could run a wire up through the house, but what a pain in the butt.  So I needed to figure out how to get my wireless signal up to a router in my office.

I went to Best Buy and I got a Linksys Bridge.  It was a bit tricky to set up, but I did, and it worked pretty well.  It was somewhat intermittent, but I was able to have  switch up in my office with connectivity to any number of machines. 

But then, out of nowhere, the thing stopped working.  It just bricked itself.  No lights, no power, no nothing. Great.  So, off to Best Buy again, with a determination not buy that Linksys Bridge again.  So the nice sales gal there pointed me to a NetGear Gaming router that is basically a wireless bridge.  I guess that these things are very popular for gaming consoles so they market them mostly to gamers.  So I’m slowly walking out, and this other guy comes up to me and says “That will work for what you want, but I can show you something that is faster and more reliable”. 

Well, I don’t know about you, but I am into faster and more reliable, so I followed him, and he showed me this:

I was a bit hesitant at first, as it seemed a bit strange to pump my connection through my household power lines and the box explicitly calls it an “XBox 360” kit (that gaming thing again), but the guy said it works perfectly for a regular network and that he’d personally take my return if it didn’t work exactly like I wanted.

Well, as far as I can tell, he’ll never see me again. This thing worked like a charm. It was pathetically easy to install – network cable out of my router, into device, which I plugged into the wall.  Then, up in the office, I plug in the other one, with a network cable out of it into my switch.  Simple, clean, and easy.  It worked immediately, and the total setup time (hardware only, no software to configure) was literally five minutes. 

So far, it’s working great.  I now want to find out if I can buy one of these things and use it in yet another room.  That would be even cooler, as we have a renter who’d really appreciate that.

All in all, a purchase that I’m really happy with.

Another Use for Unit Testing

By Nick at July 26, 2010 03:56
Filed Under: Software Development

Okay, what do bugs an unit testing have to do with each other?  Well, a lot, usually.  The first answer is that you use unit testing to prevent writing bugs in the first place.  You can also use unit testing to find bugs after code has been written.  But there is another connection that you may not have thought of:  writing a unit test for every bug you find.

Here’s how the process should go:

  1. A bug report comes in.
  2. Your QA guy reviews the report, verifies that it is indeed a bug
  3. Your QA guy writes a unit test that reveals the bug.  In other words, this test should be a test that you’d expect to pass if the bug weren’t there, but because the bug is there, it fails.  A way to approach writing the test is to write a negative test case, but actually use CheckTrue instead of CheckFalse.  You can change it later when the test starts passing.
  4. Along the way, if he sees other tests that he might write, he should do so.  If they are known/expected to pass, great.  If some other tests reveal bugs, those bugs should be logged and the process started again for that bug.
  5. The test name should include include the bug number for easy identification.  The bug report should be updated to include a reference to the test that reveals that bug.  This way, the whole system is self-referential.
  6. The know failing unit test should be included among the list of tests that are, well, known failures.  In other words, your testing system should be fine with these tests failing, and actually notify you only when they don’t  fail.  That is, “failure” is the known, acceptable state.

Now at this point you have something.  You have a good solid bug report that has been validated.  You have a test that proves the bug exists.  You’ve added it to a collection of tests that do the same.  These tests all fail, and you know that they are “”supposed to fail”.  You can safely ignore those tests for now.

That last part may seem a bit strange.  Why happily ignore a bunch of failing tests? Aren’t failing tests bad?

You probably have guessed already – you are waiting for those tests to pass. You know those tests fail, and you are tracking them to know when they actually pass.  Your developers will fix the bug, and then suddenly the test will pass, you’ll know the bug was fixed.  And shoot,  sometimes the test  will start passing without the developer explicitly fixing the bug.  That’s an extra bonus when that happens.

Now at this point you really have something.  Once the test starts passing, you know for sure that that the bug is fixed without any more work.  You can move that test over to the regular test suite, and it becomes a regression test.  If that bug appears again, you’ll know it right away. 

Now, not al bugs can have clean, simple unit tests associated with them – UI bugs come immediately to mind, but my recommendation is this:  To as large a degree as possible, never accept a bug that doesn’t have an associated unit test that “reveals” the said bug.  Enforcing this rule will have a lot of good benefits:

  • Bug reports become easier to write because very often they merely need to be the test itself with a short description. 
  • The developer will know that bugs that come his way are really bugs, and can be easily reproduced and fixed. 
  • Working on the fix gets a lot easier because the developer just needs to debug the failing test case and make it pass. No need for a long list of steps to follow to recreate the bug
  • Your QA team will be engaged in the development process at a higher level.  They’ll be writing code within your frameworks and applications, giving them a deeper understanding of the codebase they are testing. Heck, it will even help groom them to move to the R&D team.
  • You will know that a bug has been fixed without any need for further testing.
  • You’ll find out when a bug is incidentally fixed as a result of other changes.  (This should be examined a bit to make sure it’s for real, but it’s a nice surprise when it happens)
  • You’ll have a built in regression test to make sure that if the bug pops up again, you’ll know right away.

And what development team wouldn’t want all of that to happen?

Book: Starvation Lake by Bryan Gruley

By Nick at July 25, 2010 13:29
Filed Under: Book Review

I just got finished reading Starvation Lake by Bryan Gruley.  A lot of mysteries are very formulaic and methodical.  Starvation Lake is not one of those mysteries.  Instead, it a very well written tale, spun with care.  Small details that you think nothing of at the time come into play later.  Gruley weaves the present and the past together to draw a story that  puts you firmly into the small town of Starvation Lake, Michigan.  Augustus “Gus” Carpenter is the Assistant Editor on the local paper and hockey goalie for his team in the local men’s league.  He’s also the guy who years ago let the state championship game get away, disappointing the whole town.  When his beloved and long dead coach’s snowmobile washes up on a lake different from the one where he supposedly drowns, the question begin.  By the time it is over, you know everyone in town, how they were affected by the stunning loss from years ago, and how they were affected by the mysterious coach. 

If you want a mystery that has as much literary flavor as suspense, I’d recommend it.

Flotsam and Jetsam #3

By Nick at July 23, 2010 15:02
Filed Under: Flotsam and Jetsam
  • A number of you have noted that the Computer History Museum (which has both online content and a physical building up in Silicon Valley) has released the original Pascal source code for one of the seminal Macintosh applications, MacPaint.  I remember that application well – my dad had it on his original Macintosh.  I also have a strong memory of the graphic of the geisha for some reason.
  • I’ve stared using Thunderbird for my email address, and I really like it.  (I used Outlook at all of my previous jobs….) and it has this cool feature that I’ve never seen before that can use keywords from your post to remind you that you haven’t attached a file when you said you had.  We’ve all done that one.  That has probably been around on other mail clients, but I confess to never having seen it.
  • I now have a public CV at StackOverflow.  And let me add that this is about the 34th time I’ve typed in my resume.  Okay, that’s a few too many times, but it feels like it.  Business idea: A central resume location that employers can just pull from.  LinkedIn, I’m looking at you.
  • If you are interested in HTML 5 (and you can include me in that group), you might find this tutorial interesting. It’s an interesting project – Be sure to read the “Did You Know” note at the bottom of the Table of Contents.

Credit Where Credit is Due

By Nick at July 23, 2010 02:54
Filed Under: Leadership

When I was in the Navy, a large part of my job was to provide daily briefings to a senior officer.  Very often that senior officer was of flag rank (an Admiral or a General).  It is the job of intelligence guys to keep an eye on things and make sure that the decision makers had the latest information.  That usually took the form of a daily briefing.  Intelligence is a 24/7 business, and so I would have a team working overnight to prepare a briefing every morning at, say 0700.  I usually ended up giving the briefings, because the average enlisted guy doesn’t want to stand up in front of the “big brass”. 

Now, this is a leadership “two-fer”.   First, you get to take credit with your team for “taking the bullet” and being the one to stand up in front of the man, give the briefing and fielding the hard questions.  Second, you can use this as an opportunity for giving credit where credit is due.

Few things can be more frustrating for a team than when the boss takes all the credit for the team’s work.  This has happened to you, I’ll bet.  You come up with an idea.  The idea is shot down.  And then two weeks later, your boss repeats that idea right back to you as if he thought it up.  Or you find out later that he told his boss your idea as if it were his own.  Good leaders have strong egos and don’t need to steal ideas. Instead, if they pass the idea up the chain, they go out of their way to give you credit for it.

Thus when giving those morning briefings, I never passed up an opportunity to give credit where credit was due.  I often tried to work in phrases like “As a result of the excellent analysis done by Petty Officer Johnstone….” or “I don’t know, General, but I know that Chief Lyle has the answer.”    This went a long way.  My team (who was sitting in the back of the room) could see clearly that I knew they were doing good work and that I didn’t want to take credit for what they had done. 

Some people might hesitate to do this because they think that they look bad if they don’t know everything themselves.  Nothing could be further from the truth.  The most effective leaders are the ones that nurture and develop effective people.  By giving credit where credit is due, you show that your entire team (led by you, remember) is up to the task.  Your team sees that their work is appreciated and recognized.  They see their boss standing up for them and promoting them. This engenders loyalty, trust, and more hard work.

That’s a win for everyone.


By Nick at July 21, 2010 16:09
Filed Under: Leadership

One of the things that I want to do on this blog is to talk about leadership.

I’ve had a lot of experience with leadership.  I was an officer in the US Navy for twelve years, and as such I had many opportunities to both lead and be led.  I’ve also been both an observer and an actual leader and manager in the software business. In both worlds, I’ve seen how critical good leadership is, and how easy it is to be terrible at it.

I’ve been led by some great leaders and by some really bad leaders. Since I knew that I would some day be leading people, I spent a lot of time thinking on and contemplating leadership – you can hardly be an officer in the Navy without doing so.  Paradoxically, it is the bad leaders that taught me the most about leadership and what it means to be an effective leader.  By seeing (and suffering under) the actions of a poor leader – these things generally fell into the category of caring more about themselves than their people – gave me a strong sense of “I’m never going to do that!”, which then, in turn, helped me to figure out what the right thing to do is.  Don’t get me wrong, I’ve served under some fine leaders and emulating them is something I try to do, but it is the leaders that weren’t good at leading that really taught me the most. 

Now I’m not claiming to be a great leader – I don’t think that’s the case. But I do think that I’ve had a modicum of success as one, and I think that I have a few nuggets of wisdom to pass on to you fine people.  I’ll be drawing on a lot of my military experiences as well as those in the software industry to share my thoughts.

So pursuant to that,  I’ve created a “Leadership” category here in the blog, and you can follow that tag here if you want.  I won’t be blogging exclusively about Leadership – you might be surprised to find out that I have a lot to say about a lot of things (shocking, I know) --  but I do have a lot of thoughts on the matter that I feel compelled to share.

Flotsam and Jetsam #2

By Nick at July 21, 2010 14:37
Filed Under: Flotsam and Jetsam
  • I’ve added a page that discusses this blog and how I put it together.  And since I’m not above shameless hucksterism, please feel free to click on the referral link to DiscountASP.NET and get me a referral fee.  
  • The first time I remember seeing a URL in a TV commercial was around 1996 for Toyota. How about you?
  • There are so many applications out there that produce the most amazingly craptastic HTML, I can hardly believe it.  MS Word, I’m looking at you.  But you aren’t the only one.
  • Also added my StackOverflow Flair.  Had to tweak it a bit because the bottom was being cut off. Couldn’t quite figure out what in my CSS file was affecting it.  You, too, can get yourself some cool StackOverflow flair
  • Some of you noted that my disclaimer made even less sense than I intended for it to.  I re-read it, and by-golly, you guys were right.  So I fixed it, and now it makes exactly as little sense as I want it to.

Flotsam and Jetsam #1

By Nick at July 19, 2010 15:58
Filed Under: Flotsam and Jetsam
  • So, this is the posting category where I’ll put miscellaneous little items.  Those of you who have followed my blog in the past know that I like to do this.
  • There is an ulterior motive here: I’m post this with Windows Live Writer, so I guess if you can read this, it worked.
  • I also wanted you to know that I posted my resume on the site.  You can look at via the link over there on the right. 
  • I note with sadness that it sure didn’t take long for comment spam to show up.  I’ll have to get on that.
  • As I noted, I’ve tried to personally thank each and every one of  you that has sent along a kind work or a note of encouragement. If I missed you, I’m sorry.  And I’m also grateful.

Thanks To Everyone

By Nick at July 18, 2010 15:19
Filed Under: General, Personal

This has been a tough week -- but I guess that isn't surprising as being "let go" from your job on a Monday morning will make any week tough.  

But two things happened that made it all a lot better.  

First, my former co-workers had a farewell lunch for me a the (in?)famous Cafe Carlos.  I was quite touched and honored that over 40 people -- including practically all of the R&D and QA teams, were there.  With all humility, I must say it was the biggest farewell lunch I'd seen since I was there.  It was quite flattering.  

The other thing that happened was an almost overwhelming out-pouring of kind words and well wishes to my post in the (in?)famous Delphi Non-Technical forum.  I tried very hard to say thanks to ever single person who posted there -- if I missed you I am sorry.  

I am quite sincere when I say that these two things touched me deeply and humbled me greatly.  As I said in my post, I've lived, breathed, eaten, and slept Delphi for at least the last 15 years, and it is quite nice to feel so appreciated. 

Thanks again to you all who have wished me well in the newsgroups, email, and in person.  I truly appreciate it, and it makes going through this tough time a lot easier.  Thanks.

First Post

By Nick at July 15, 2010 19:35
Filed Under: General

Hello World!

My Book

A Pithy Quote for You

"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid."    –  Albert Einstein

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.