I am a Microsoft Certified Solution Developer (MCSD.) Seeing as some of the folks at work are looking to get their certifications, I spent some time today reviewing possible tracks to upgrade my credential to Microsoft Certified Technology Specialist (MCTS) or Microsoft Certified Professional Developer (MCPD.)  I was happy to discover that I am eligible to upgrade my MCSD credential with the option of one or two exams.

If you (like me) are an MCSD, you can earn certifications in MCTS: .NET Framework 2.0 Web Applications, MCTS: .NET Framework 2.0 Windows Applications, MCTS: .NET Framework 2.0 Distributed Applications, and MCPD: Enterprise Applications Developer on Visual Studio 2005 by passing Exam 70–554 and Exam 70–553. 

Alternatively, you can receive your MCPD: Enterprise Applications Developer by passing a single exam, Exam 70–554, but you will need to earn your MCPD: Web Developer and MCPD: Windows Developer certifications first. This option is certainly the faster track if you have already satisfied the two prerequisite certifications (which I have not.) 

You will note the exams called out above are geared around Visual Studio 2005 and the .NET Framework 2.0.  There are also equivalent MCTS and MCPD certifications for Visual Studio 2008 and the .NET Framework 3.5.  I’ve been inside of VS 2008 and .NET Framework 3.5 for some time now so I may just test my skills against the latest and greatest.  It seemed to make sense but you never know.

It’s been over 4 years since I last tested.  If anyone has advice or feedback, I would love to hear it — even if it’s merely "good luck."  

I am relatively new to the Test Driven Development (TDD) scene.  Though I have read up on the subject (specifically Test Driven: TDD and Acceptance TDD for Java Developers by Lasse Koskela), my only hands-on experience is limited to a single, 3-month project where I was the lone developer.  All other information gathered on the subject has been through blog entries, podcasts, ramblings and the occasional demo in the office.  Though I believe I have a good understanding of TDD methodologies, I am far from putting this, dare I say, knowledge to practice.  Good practice, that is…

A spike is a term associated with TDD.  A spike is nothing more than quick coding exercise which validates or invalidates an assumption.  Lasse Koskela says it more eloquently:

A spike is a short experiment with the purpose of familiarizing ourselves with the technology, tools, algorithms, and so forth, that we need for solving the problem at hand.  A spike is  a way to make an unknown known — at least to a point where we know whether it’s worth continuing to dig that way or whether we should start looking for another way.

If you are familiar with TDD concepts, you know that spikes offer no value with it comes to testability, maintainability, etc.  They are merely quick prototypes which I find immensely helpful but should not be considered the focal point of TDD.  Well, my first crack at TDD resulted in roughly 70% spikes and 30% actual tests.  Not too good.

There is no doubt in my mind that I always had the best intension to test-code-refactor, but I wasn’t yet familiar enough with TDD to know I was way off course. There was also no one around to put me on the right track (or keep me honest.) Putting my ego aside, I know I could have used some hand-holding when I was starting off with TDD.

Test Driven Development is a discipline.  Like many other disciplines, TDD requires a teacher, student and practice.  The teacher offers instruction and ensures the discipline is practiced correctly.  The good student gathers knowledge and implements under watchful guidance.  In my opinion, TDD is therefore a seemingly good fit for a team which embraces an Agile approach, collaboration, rapid development and testability.   I’m not saying the lone developer with no prior experience with TDD is not capable of learning TDD on their own. I know some are.  I know guys who have done it.  Simply, I am stating that TDD seems most accessible to the mentored developer working with team members who previously adopted the methodology.  To put it another way, I bet Test Driven Development concepts are best learned through practical, hands-on example.

I haven’t given up on TDD yet.  Who wants to hold my hand?

I can’t possibly count the number of times the beautiful "Firefix has stopped working" message has popped up over the past two weeks. 

Sometimes, when the coding gods are smiling down on me, I am lucky enough to get the Restore Session / Start New Session prompt after I "Close program" and relaunch.  The majority of the time, however, I just keep getting the "Firefox has stopped working" message until I reboot my machine — a task I try to avoid in the middle of the work day.  I don’t know about you but I find it difficult to code when my computer is offline. 

As a result, IE became my default browser today because I simply do not have the time to debug the issue.  I’ll miss you firebug…

I’m a fan of Pandora Radio.  I really love the product and I complete dig the simplicity and slickness of their Adobe Flash GUI…with one exception.  I have an issue with the play/pause control. 

Pandora has chosen to recognize the current state of a song (playing, paused) by highlighting the associated button.  The image to the right, for example, shows the display when a song is playing.  Makes sense, eh?  Well, yes, this strategy makes complete sense until you consider how users are going to interact with the application. 

Quick.  Let’s list every possible action a user may take while a song is playing.  Pause the song, forward to the next song or adjust the volume.  That’s it.  What action will the user absolutely not take?  The user won’t play a song which is already playing.  Never.  It just doesn’t make sense.  However, since the buttons serve a multiple purpose (display state and trigger actions), the user is presented with a prominent, highlighted, active play button when they wish to pause a song.  Even worse, the pause button appears to be disabled.  If the UI could speak, it would be screaming at the user, "The song is playing?  Clicking the play button is your only option!"

I’m of the opinion that Pandora’s choice of button highlighting and "multi-purposeness" confuses things.  Is it just me or is this simple interface too simple?  Consider user interaction.

I suspect every blogger aspires to publish original content.  Unfortunately, in a world where original thoughts/ideas no longer exist, this is virtually impossible.

Maybe I am making this up, but I think it is only a matter of time before thoughts are appropriately republished.  It’s like fashion.  This year’s hip style was trendy in one form or another years ago.  The style was literally worn out, then put on a shelf until someone came along and decided to put a form of those super "new" pants back on.  Like the clothes we wear (the music we listen to, the TV we watch), thoughts become fresh and new if enough time passes. You may have noticed this phenomenon recently when blog and podcast conversations turned to topics like whether or not developers should learn C or whether or not developers should still be using stored procedures.  

There’s also plenty of really great content which didn’t get enough looks the first time around, didn’t rank high in Google and, as far as I am concerned, is basically lost for ever.  Earlier today, for example, I was trying to track down some information. I knew the blog and the general topic. Actually, I remembered specific text but I still couldn’t find the post in the sea of information.  Lost forever. One of the reasons good content gets lost in the shuffle is the fact that there is very literally too much information available to us. It is information overload thanks to all of the non-stop blogging/Twittering/video-making/podcasting/book-writing folks in the tech community.

Again, I believe every blogger aspires to publish original content.  I know I have always been concerned with writing about things which have already been said, but does this attitude make sense considering how much information deserves more attention or even a second chance?  Having only started to read/write blog posts about two years ago, I, for one, have missed a lot and I sure am thankful that good content tends to echoes since most of the online debates are news to me.  Everything is cyclical and the good topics are noteworthy each time around.  Do you think good information bears repeating? 

I’m going to wrap with three unoriginal thoughts:

1. A Suggestion: To all of the folks contributing to the information overload, get back to work! And by "work," I mean your real jobs. I can’t keep up with you. Can anybody?
2. A Recommendation:  The stackoverflow podcast is excellent.  It is a great, hardly-ever-on-topic, unscripted, one-hour, weekly dialogue between two industry enthusiasts, Jeff Atwood and Joel Spolsky, about their new stackoverflow.com endeavor.  It’s truly enjoyable.  You will laugh.  You will cry.  You should listen in. 
3. A Quick Story: I listened to Stackoverflow podcast #7 last night.  This was a delinquent listen as it was recorded on 5/27.  Part of the discussion revolved around OpenID which prompted Joel to play the role of a future stackoverflow user and setup an account.  The registration process was easy although Joel struggled to interpret the characters displayed in the MyOpenID CAPTCHA. He went as far as to comment about the CAPTCHA audio display.  So, I reviewed my archived posts this morning and I wrote about that exact topic on 6/10.  Hearing the words coming out of Joel’s mouth last night made my stomach sink as I technically posted unoriginal content about two weeks after it was presented in the podcast.  By no means am I saying the CAPTCHA observations are really great topics, but I guess I am still concerned with writing about things which have already been said.  If this post speaks to anyone, I hope it is me.

My customer recently asked me if my current coding assignment is difficult.  I believe his exact question was, "On a scale of 1 to 10, how technically difficult is this project?"  If you have been in the software development business for more than 2 hours, you know this is a loaded question.  Quickly reply with "It’s highly technical and super hard" and you may be perceived as being over-your-head or even incompetent.  If you say "It’s super easy" the customer may wish to speed up the product delivery or wonder why your code hasn’t been delivered already.  Say anything in between and, well, your client may think you’re keeping something from them.

Fortunately for me, I’ve built up a good working relationship with my client (who’s a very reasonable guy) and I have gained trust through regular status and deliverables.  We’re both happy with the current state of the project and therefore I took the question as he merely being curious.  I have given the benefit of the doubt and I don’t believe the question was loaded at all.  Time will tell…

Notwithstanding, as uncomfortable as the question is when coming from your customer, project manager or project lead, it is still a great question to ask yourself.  A number of factors should play into your answer but I’m willing to bet there’s an aspect of your effort which factors in the most.  For example, my biggest factor is the sheer number of components.  If you have worked with me for any duration of time, I hope you know I keep my architecture as simple as possible at all costs.  My ego doesn’t like it but my tiny brain and my clients tend to thank me for it.  Though I whole-heartedly stick by the architecture I’ve put in place for my current effort, it is made up of a dizzying number of components — certainly more components than the typical, single-developer, 3-month assignment. Specifically, I am hosting a web application, web service and a SQL 2005 DB.  I am also distributing a Windows application, Windows service and a third party application to client machine’s using custom installers.  The web site features online order/purchasing and reports using Adobe Flex.  All development (other than Flex) is using .NET 3.5 Framework and I’ve opted to use WPF for the Windows application.  With the exception of Flex (which I’m hoping goes away soon) and WPF, it’s all stuff I’ve done before although it has been an awfully long time since I built a desktop application.  Each piece of this puzzle isn’t overly difficult on it’s own, but collectively I think this solution is quite complex.  If I could, I would dumb it down, but I can’t.  I simply have to acknowledge the complexity and mitigate what I perceive as a risk.

So, on a scale of 1 to 10, how technically difficult is your project?  If it’s high, is there anything you can do about it or are you kind of "stuck" like me?

I vividly recall creating my Windows Live account and wondering how many folks are able to guess the 8 character CAPTCHA on the first attempt. I swear the CAPTCHA presented to me looked like random scribbles in a box. I did take screen shots but they seemed to have disappeared just like my patience on the day of signup.

Yesterday, I revisited the page and came up with the following examples. I don’t think these samples are THAT bad, but can you decipher any of characters strings with 100% confidence? I doubt anyone can and I think this feat is well-known to be impossible.

Have a look at all the help one gets. For one, the “8 character” hint helps a lot. And if you are still stumped, a new CAPTCHA can be requested until one becomes answerable. And if that fails, take a whack at the audio version in order to validate being human.

Coding Horror had a nice write up on CAPTCHA Effectiveness a while back. The claim was that even the most basic, most ineffective form of CAPTCHA, “naive CAPTCHA” where the CAPTCHA term is the same every single time, stops 99.9% of content span.

Granted, these statements were written before Coding Horror had 103K subscribers. I suspect this was well before Coding Horror needed to be overly concerned with telling computers and humans apart, but I think the sentiment that CAPTCHA doesn’t need to overly inconvenience the user to be highly effective still applies.

I am not opposed to extreme CAPTCHA — especially when hints are provided — but the extra clicks and guesses bugs me enough to go into a useless rant about Y’s, I’s and J’s…

I started using the TextMate Theme for Visual Studio a week ago.  This afternoon I switched back to the default VS theme and nearly threw up. It’s really flipping plain to the point of being ugly. All the same, I looked at the white screen for less than a minute and I reinstalled TextMate.  I didn’t even strike a key.  I just rolled back.  I guess the default theme is no longer my default theme.

I have never used an alternate theme before. In fact, not too long ago, I used to resent looking at code which wasn’t being shown under the default (read: most common) theme. I have gone as far as to ask developers to read their code to me (you know who you are) because their theme was too busy and/or simply didn’t agree with me.  Unfamiliar themes are a distraction — at least they are to me.  In my opinion, all presentations (code reviews included) should be done using the default theme as to not take away from the information being presented.

Coincidentally, it took me a couple of hours to get used to the TextMate theme. I suppose having watched all of the MVC Storefront presentations which use TextMate rather than the default theme (oh, the irony) instigated and most likely helped me with the transition.

It is quick and easy to switch between themes (Tools > Import and Export Settings…).  Even if you are sharing your code or presenting often, I would encourage you to sample something new.  If you are like me, you may find an alternate theme gives your code some personality, possibly provides a little creative inspiration or simply lessens the strain on your eyes (I know the default white background can get a little blurry for me at the end of the day.) 

Give an alternate theme a try and let me know what you think.

I very recently posted about using SubSonic to generate my DAL and SSMS Tool Pack to generate the complementing stored procedures.  In response to the post, Jon Galloway asked a great question in the comments:

Thanks for the pointer to SSMS Tool Packs. It looks really interesting. One thing I’m having trouble picturing is the overlap between the two [SubSonic and SSMS Tool Pack]. Once you have a DAL, what do you need CRUD routines for? Bulk operations, or something that’s a result of the existing architecture?

For those familiar with SubSonic you can appreciate Jon’s question.  Since SubSonic’s generated DAL provides you with CRUD methods and easily allows you build resulting parameterized queries, you are no longer dependent upon having compiled routines sitting in the database. 

Almost on queue, Caffeinated Coder recently a great article on why one should "Just Say No to Manual CRUD" which provide a list of resources which present good counter arguments against the conventional stored proc wisdom.

So, why the heck am I still using stored procedures?

If I were to be honest, the number one reason I’m sticking with SPs is they are familiar and they provide me with a sense of comfort.  Most of my uneasiness with "embedding" data access into the application code is tied to deployment and maintenance.  For example, I like to have multiple "outs" when it comes to rollbacks and I like to keep emergency fixes as isolated as possible. Since stored procedures could be considered more atomic than even the most lightweight DLL, I can update a live application by altering a single stored procedure with more confidence than copying/replacing application file(s.)  Assuming you have a single database and a web application running on multiple web servers, in my opinion, the stored procedure update is best solution since time to implement is low, risk is minimal and downtime is eliminated. 

I had a good follow up conversation with Jon about all of this last week and the bottom-line is that one needs to put the right architecture in place based on their coding, deployment and maintenance needs.  I am currently sticking with stored procedures but this approach isn’t necessarily right for everyone. 

I woke up this morning (whew) wondering what percentage of the development community is privileged enough to deploy their own stuff.  I wonder because I think I’m out of touch in this area.  Over the past 6 or so years I’ve been handing off installation/deployment duties to other groups.  My development teams and I were very involved in the release of our applications — sometimes to the point of executing the installation ourselves — but 95% of the time the actual server/network setup fell outside of our responsibility.  With my new position, things are very different.  Now, I’m pretty much responsible for everything and anything. 

Last week, I setup a new web site.  This task included everything from registering the domain to getting the various instances of the site (for example, dev.site.com and qa.site.com) mapped to different IPs.  It was a "fun" exercise as it’s been forever since I needed to do this sort of thing.   In fact, it didn’t go super-smoothly the first time around as the host company didn’t apply the IP mapping appropriately.  Anyhow, I shared my woes with the former colleague and their response was something along the lines of "you know so much more about that stuff than I do." 

As it turns out, it was the Host Header Names reference which threw my colleague.  If you are in the same boat, Microsoft Internet Information Services (IIS) allows you to map multiple web sites with the same port number to a single IP address by using a feature called Host Header Names. By assigning a unique host header name to each web site, this feature allows you to map more than one web site to an IP address.  Knowing about Host Header Names can come in handy — especially if someone else isn’t always going to be doing your dirty work.

Back to my point: I was still a bit surprised by my buddy’s response, but then I thought it through.  In order to develop a .NET web site, one doesn’t even need to open IIS. Not ever. Not since 2.0 at least. And once the basic setup (domain registering, DNS entries, IIS configuration) is in place on the destination server, a .NET web site can be deployed through a mere file copy.  If you aren’t involved in the initial setup/install, a developer doesn’t need to know how to do anything other than how to code and copy files in order to maintain/enhance a live site.  Is it possible that a developer can get along perfectly well without having to know anything about web site deployment?

Are you involved in your company’s project estimation process? If so, let’s pretend. Let’s pretend that your company has internal constraints which makes estimating rather difficult. For example, let’s say you were required to completed all of your 2008 estimates towards the end of 2007 despite the fact that very few requirements were known. Don’t get me wrong. There were a few requirements but they were very high-level or what I would equate to a vision document or merely a great idea someone thought up while taking their morning shower. Of course, no one should expect these estimates to be all that accurate, but just for fun, let’s pretend that some felt they would be good enough to use as a basis to determine the entire budget for 2008. Kind of scary, eh? Well, I’m familiar with such a process and it is really scary and frustrating and, in my opinion, a tough way to end and start a year. You do learn to deal and make the best of it though.

It goes without saying but estimation is an art. It is hard enough if you have all relevant information at your fingertips. The thing is we rarely do have everything we need. Now, I recognize the provide example is a little to the extreme, but it happens. Believe me, it happens. Again, you do learn to deal and make the best of it though. But what if one wanted to improve on the process summarized above? What could be done?

I think the first step is determine the key factors in providing a good estimate which I believe included the following:

• You Need Good Requirements: Good requirements have the greatest impact on an estimate. As requirements become more complete and detailed, estimates become more accurate and our confidence increases. Period.
• You Need An Appropriate Estimator: Estimators should be chosen based on their understanding of the requirements, their knowledge of technology and possible solutions and their past estimating experience. The decision of whom should estimate one’s projects should not be taken lightly.
• You Need To Know The Implementer: To provide a good estimate, it isn’t really necessary to know who will be performing the work, but since no two developers have the same skill set or experience, knowledge of the implementer can help firm up an estimate considerably. If nothing else, you need to know the candidate’s assumed skill set and domain knowledge.

It should be noted that we often think that timeline and/or budget have an affect on our estimates. This is only true because these factors affect scope, which in turn affect requirements, which are ultimately reflected in the estimate.

Once the key factors are identified (maybe there’s more than listed above), a better process needs to be defined. Assuming the company absolutely has to continue estimating and budgeting for the upcoming year prior to having solid requirements, I would suggest breaking the estimation process into three stages in order to continually firm up one’s numbers as additional information is provided:

• SWAG: This high-level estimate is based on the limited requirements offered in the project request. Since this estimate is typically provided by management, and is based on few requirements, it should come along with a fairly low confidence level. Unfortunately, the allocated budget is tied to these estimates. Since none of individual estimates will be accurate, the best case scenario is to end up with estimates balancing themselves out. In other words, for every over-estimated effort there will an under-estimated effort. If the majority of efforts are under-estimate, you are screwed. If the majority are over-estimated, you are bound to have some awesome launch parties.
• Detailed Estimate: This estimate can be produced once detailed requirements are offered. This requirements would come in the form of a BRD or FSD. Who produces this estimate? People with knowledge of the product and the technologies who will hopefully be involved with the project until it is released. This estimate becomes the foundation of the project plan and is the basis of all staffing requests.
• Developer Validation: Once development assignments are distributed, each developer will validate the provided estimate against his/her associated tasks. Adjustments to the project plan and staff plan will be made if necessary.

In theory, one should expect estimates to change as scope or staff fluctuates — if we follow the steps above.

In no way is this high-level plan a silver bullet. It isn’t necessarily realistic for all shops as I, for one, can’t remember the last time I was asked to estimate a project AFTER I received firmed up requirements and I can’t think of a single case where scope didn’t change between a project’s inception and its end. I guess that’s why estimation is an art. You must leverage whatever process you currently have in place, search hard for few facts and then provide your best guestimate all the while knowing that things may very well change tomorrow. I do believe if one respects the key factors and overall process above, there’s a better chance of success than if these core ideas are disregarded.

Best of luck with your next estimate. By the way, what did I miss?

You may have noticed the recent attention given to TDD and whether it has been proven effective or not.  I think the entire “conversation” is great.  I appreciate everyone’s position primarily because the parties appear to be presenting their opinions and the interpreted facts with open minds.  If I were to take sides, though, I think I would be in favor of the “Not” argument mostly for the reasons I commented about on a recent post by Jon Galloway:

You know, it is pretty easy to read the popular blogs (especially the ones which make references to “alpha” programmers) and think their way is the right way.  I take a lot of pride in [dev stuff], but if I hadn’t been in this business for a while, what-every-developer-must-know type posts could really get me off track.

Please do not interpret this as a knock on the “popular blogs.” I like them a lot, but what I love is the fact that Jacob Proffitt took the time to challenge the TDD effectiveness evidence.  It isn’t for a lack of trust, it’s just that as developers it is our job to question everything.  Equally, it is our job to validate everything. 

I literally just wrapped up a meeting with one of my lead developers.  We are just over a week away from rolling Version 2 of an application to our Production environment and today — one day after our final QA release — he discovers where Version 1 of the product lives and what it is *really* doing.  Why did it take so long to find out the real story?  Well, he (really we, I am equally responsible) trusted documentation and what past developers shared with him…and now we are in a bit of a pickle. If only we verified earlier. Fortunately, this kind of thing doesn’t happen often, but I’d be willing to bet that something questionable crosses each of our paths every single day. 

Back to the TDD effectiveness conversation. Here’s my semi-confirmation bias story as it relates to TDD… 

I worked at a shop where fingers were pointed towards Development no matter what the technical issue.  The web server lost connectivity to the app server.  Database XYZ hasn’t been backed up for 8 weeks. The L Drive has only 97KB available.  Two new defects were just introduced into the Production Environment after four months of testing.  A third party web site is down.  Quick, call the Developers.  Don’t call Networking.  Don’t call the DBAs.  Don’t call the NT Admins, the QA group or the third party site owners.  Call the Developers.  Maybe you are familiar with such a place?  Anyhow, since Development clearly had to straighten up its act, we needed to provide evidence (there’s that word again) that we were putting more care into our code and validating our applications prior to release.  Thus, TDD was introduced to my shop.  We found the perfect guinea pig project — an Enterprise Messaging System (read: glorified email engine.)  It was simply a service which sat around waiting to complete requests issued by a handful of web applications.  For this app, we did true TDD as we actually wrote the tests before the code.  All the tests passed and we rolled the service to QA and, lo and behold, not a single defect was logged against the Enterprise Messaging System.  It was deemed perfect. The greatness of TDD was soon shared at the quarterly IS meeting using the first-ever defect free application as evidence of its brilliance.  I think those who pushed for TDD were hoisted on shoulders and paraded around the conference room as Development had finally had gotten their sh*t together. 

If truth be told, instead of praise and congratulations, everyone should have been asking a whole bunch of questions.  Was TDD really the reason for the bug free code — directly or even indirectly?  Was a superior product released because time was taken to validate all of the tests?  Perhaps merely taking the time to write the tests before coding gave Development a needed boost?  Well, these questions certainly couldn’t be proven either way.  What about the zero defect count providing evidence that TDD was our saving grace?  Very simply, there was no relationship between TDD and bug free software at all.  In fact, the service had bugs, but no one other than the developers knew it.  All bugs were logged against the calling web apps (as testers couldn’t interpret the difference between a web app failure and a service failure) and fixes were applied to the service unbeknownst to the folks looking for the last great Development hope.  It was all a matter of sharing only the information which supported Development’s case as well as stretching the truth a bit. 

If you look hard enough this stuff happens every day whether it be accidental or intentional.  Though it is exhausting, it isn’t a bad idea to question everything — or not.  The choice is yours.

I have a friend who has been involved in multiple reorgs over the past couple of years. He used to say “change is good” with enthusiasm and some conviction, but now he merely speaks those words under his breath in a feeble attempt to convince himself it is so. My friend chooses to think that the changes are made with the best intentions and for valid reason. He also chooses to think the changes must be for the better good and if a mere engineer could only see the “big picture” they would agree.

Yet the reorgs have become discouraging. He has said that one reorg is survivable — even welcomed. A second reorg is bearable yet questioned. A third reorg is laughable. Additional changes are, well, the joke’s over. Of course, it would be naive of my friend to think a business — any business — can survive without some element of change, but to his point, continuous change to roles, responsibilities and reporting structures can not be made without a cost.

When it comes right down to it, there are a number of factors which should be highly considered when mixing the personnel pot. For example, how much weight should team chemistry get? I mean, the team building, the earned trust, the relationships…it will be lost quite literally overnight. How about continuity and stability? How long does it take to get comfortable with your boss or your boss with you? All of the conversations on expectation setting, career planning and personal growth need to start back at scratch. It’s doesn’t say much for job stability, or job satisfaction, for that matter. Then there is the knowledge lost? How about when all of the application knowledge goes along with a person who has been assigned to other things? Somewhat devastating, I suppose. And when you shuffle around players someone ultimately has to do an awful lot of learning before they are a positive contributor in their new role. That can be a pretty big hit when an existing team members need to pick up the slack until the newbie is up and running. This list goes on and on…

Maybe breaking apart teams, swapping managers, disrupting continuity, weakening stability and losing knowledge is a small price to pay when you have a positive, end goal in mind. My friend isn’t sure, but he’s choosing to think that way…for now.

Jon Galloway is determined to write three posts a week.  I think it is a great goal — one which I wish I could meet. This past weekend, he wrote about “aspiring to be the dumbest person in the room” and how “more active participation in a group can lead to more information, but that new information can actually stifle further participation.” 

Well, when it came right down to it, Jon provided a list of reasons why he wasn’t blogging as consistently as he would have liked.  Rather than offering only excuses, he offered solutions or a better way of viewing the situation.  Jon did a nice job with the post.  For those of you who have been wanting to write more but haven’t, this is a good read for you. 

On a similar note, I am a firm believer in being the dumbest person in the room.  When it comes to management/leadership, only good things come from surrounding yourself with exceptional people — especially people who are smarter and more talented than you.  This can sometimes feel uncomfortable, but there’s something inherently good and responsible about managing and leading this way.  I may have provided insight into my overall attitude a while back when I encouraged readers to subscribe to my blog in order to feel smarter.  Guaranteed. 

Best of luck to Jon on his three-posts-a-week resolution.

We will occasionally pepper in a few brainteasers at the end of our interviews.  Yes, they are sometimes the you-don’t-bury-survivors type questions.  And then there’s the cube question which I have written about previously.  One of the guys on my team likes to ask “port association” questions.  He gives a port number and the candidate provides an answer.  It is kind of fun to hear “80.”  “HTTP.” “443.”  “HTTPS.” “21.” “FTP.” “789″ “Pardon me?” The other evening a co-worker was sharing a past interview experiences.  He was interviewing for a technical business analysis role and they asked him, “Is the clock on your VCR blinking?”  To this, he replied, “What is a VCR?”  Not a bad question and not a bad answer in my book.

Joel Spolsky translated uptime percentages to allowable time/year outages in today’s Five Whys article.  For example, an SLA stating something like 99.99% uptime allows for 52.59 minutes of downtime per year.  Where am I going with this?  How’s about this for an interview question: “What is the difference between 5 and 6 nines?”  This question will probably generate some interesting answers.  There will be a good number of individuals who are familiar with the term and they will be able to speak to the question.  Some might provide the difference between 99,999 and 999,999.  Others will perform the translation in their heads, give the correct answer down to the second and knock my socks off.  If you find yourself sitting in on an interview with me, look out.  This question is coming — or not.