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?

The folks I work with are wicked smart.  Go back and read that first sentence again.  This time read it like you are Ben Affleck in Good Will Hunting or one of the guys I used to play summer ball with outside of Boston. Fun right?  Anyway, the point is I work with really smart people and I like to push random characters voices into the heads of my readers. 

Tip Number 1: If you have the means, I suggest you plant yourself in a similar environment.  There’s nothing you can do to better for your career than surround yourself with talented, smart people who are passionate about their work.  It doesn’t matter if you are a junior coder, manager-type or CTO.  It’s just good sense.

The problem with my current environment is we are scattered amongst many projects, across many clients and the opportunity to collaborate doesn’t knock very often. We do have a weekly team meeting, but it generally focuses on business/management stuff.  I do find that software development talk often surfaces at lunch but arousing conversation around grass fed vs grain fed cattle is equally as likely.  There really was no venue to really talk shop and harness the collective software development knowledge of my coworkers. 

So, I suggested we start hosting Lightning Talks… The immediate response was very favorable (everybody likes to hear themselves talk, right?) and this week we held a very quick business/management team meeting and then the development staff started our first round of *modified* Lightning Talks.  I emphasis the word "modified" because we broke a rules.  Read on.  We kept things very informal and, in the spirit of lightning talks, intended to host a number of very quick quick 3-10 minute presentations.  Unfortunately, we kind of blew it with the time allotment as my two talks, one on AnkhSVN and the other on Inno Setup, took 5 minutes and then 45 minutes respectively.  All the same, everyone seemed genuinely interested in presentations and the pseudo-lightning talk concept (although you never know because I work not only with really smart people they are also very kind.)  Perhaps the best evidence of the Lightning Talk success was at least one coworker volunteered to do a presentation next week and our internal Wiki already has a section dedicated to presentation notes. 

Tip Number 2: Introduce a similar practice to your workplace.  No matter what you call the meeting, getting coworkers talking about technology is one of the best ways to get introduced to new ideas and sharpen your existing skills. 

Wish us luck on future talks.  Let’s hope my brain doesn’t get too big.

There are a few primary reasons why Windows Authentication should be considered a best practice. Since passwords aren’t visibly exposed in configuration files and credentials are not sent over the network, your systems tend to be more secure.  Additionally, password management (expiration periods, minimum lengths and account lockout after multiple invalid logon requests) becomes a heck of a lot easier. Considering the benefits, I have no issues with applications accessing SQL Server using Integrated Security, however, I think there is a big different between application access and developer access. 

Really quickly, you can setup SQL Server to run in one of two security modes: Windows Authentication or Mixed Mode.  Mixed Mode is exactly as it implies and allows users to connect using Windows NT Authentication or using SQL Server Authentication.  I’m a fan of Mixed Mode which allows for application accounts to reap the benefits of Integrated Security while allowing considerably easier SQL Auth access for developers, support personnel, etc. 

Please consider the following scenarios: 

1. An instance of SQL Server is setup in the Development Environment and it isn’t running in Mixed Mode.  This implies that one needs to be a member of the appropriate domain and have appropriate permissions in order to access the SQL Server.  Not a big deal, right?  Well, I would agree if I were a developer working onsite and the Dev Network was readily available to me. But I happen to work remotely on occasion and there isn’t an entrance point into this particular domain through VPN.  Boy, SQL Authentication sure would come in handy in this case. 
   
2. Let’s say your environments (perhaps Dev, QA and Production) are hosted in separate domains.  It would be painful to switch between domains in order to access each SQL Servers, wouldn’t it?  (I know what you are thinking, “Why would a developer need to access QA or Production?”  Special assignment.  Let’s leave it at that.)

Fortunately, there’s a workaround.  If you are me, you beg and plead and moan and request that security mode be changed (not that that’s easy.) OR you discover an even better solution in the appropriately named RunAs command which allows a user to run specific tools and programs with different permissions than the user’s current logon provides.  

The following are a few of  my favorite commands which I’ve wrapped up neatly in their own .cmd file for quick execution (you will need to update the domain and user values accordingly):

• runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe”
• runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”"
• runas /user:domain\user isqlw

This tip actually came from a wise, remote developer working in Canada who was confronted with Scenario 1 above.  Pretty neat, eh?

Over the past decade, I’ve primarily used two version control products: Visual Source Safe and Borland StarTeam.  I was “forced” into using StarTeam about 5 years ago, but having used it day-in and day-out for so long, I’ve come to recognize it as the superior of the two products (hands down.)  Through blogs and open source projects, SubVersion has gained my attention and I’m now giving it a whirl as well.  Having just installed it and TortoiseSVN (both open source) on my laptop, I thought I would walk you through my steps:

SubVersion

The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. For a full list of features, visit the site: http://subversion.tigris.org/

For Windows Installations, you may find the latest installer (svn-1.4.2-setup.exe) here - http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91. A list of other packages are here.

Just follow the installer steps.  The installation is quick and painless…

TortoiseSVN

Tortoise is a  SubVersion client, implemented as a windows shell extension. As stated on their site:

TortoiseSVN is a really easy to use Revision control / version control / source control software for Windows. Since it’s not an integration for a specific IDE you can use it with whatever development tools you like.  TortoiseSVN is free to use. You don’t need to get a loan or pay a full years salary to use it.

The image below gives you an idea of what Tortoise has to offer.  To learn more, visit http://tortoisesvn.tigris.org/. 

The latest TortoiseSVN installer (TortoiseSVN-1.4.1.7992-win32-svn-1.4.2.msi ) can be found on the downloads page - http://tortoisesvn.net/downloads. 

This installation is easy as well, but it did require a reboot. 

Getting Started

I followed this Practical Guide to SubVersion on Windows with TortoiseSVN to get myself going.  You may also find Tortoise manuals here or they are available by pressing F1 in any TortoiseSVN dialog once the product is installed. 

I won’t say the setup is very intuitive and I was happy to find a tutorial.   Most importantly, I’m really happy I have friends who have been using SubVersion/Tortoise for a while now.  In fact, I’m hoping to provide a little more insight into using SubVersion once I get the skinny from Jon Galloway next week. 

Stay tuned…

I don’t remember the exact quote.  Actually, I don’t know if she actually said it aloud, or I could just read it in her eyes, but my wife recently let me know (in her own special way) that I spend a heck of a lot of time on my computer with very little to show for it.  I’m sure I’m completely over-simplifying it, but I think it boils down to this:

I’m doing something software related roughly 100% of the time I’m on the computer.  Since software development is my livelihood, one could reasonably deduce my time spent on the computer is time spent working.  Since most people get paid for their work, it isn’t such a stretch to think I should be compensated for my time on the computer.

I’m sure that some of you are ready to get into a shouting match with my wife.  Now, let’s not judge her quite yet.  She does understand that a good number of coders (including her husband) have a love affair with their work.  Software development may pay our bills, but we also eat, sleep and breathe code and my wife knows it.  She also knows that we need to spend some of our spare time keeping up the Joneses –  learning, experimenting, creating, reading, playing outside of office hours.  She totally gets it.  She really does.  All the same, I do tend to spend an exorbitant amount of time “online” and my wife does have good reason to give me the stink-eye more often than I wish to admit.  

[ Off on a tangent, I have another blog entry in the works.  It’s about the importance of choosing an appropriate development estimator.  In the process of writing the article, I considered how estimation plays into our daily lives. For example, when my wife asks “What time are you coming home from the office today, Honey?” I tend to be overly optimistic.  When I arrive home a few hours later than expected, the stink-eye comes out.  Perhaps you have seen it as well? ]

Most recently, my wife asked why a coder would contribute to an open source project.  I fell back on the the obvious answers:  learning and enjoyment.  I knew what she was thinking, ”Well, that’s fine, but what you are really doing is coding and giving the product away for free.”  She was blunt, but she was right.  It is a little different than just goofing around on the computer “learning” and “having fun” on my spare time.  This was contributing to a legitimate development effort … for nothing.  I did mention that it was also good for networking (meeting other developers, finding future work) but I don’t think I appropriately made my point and the conversation died a quick, yet terrible, death.

Since our talk,  I have been thinking about all the other times I’ve done work for nothing. 

As I mentioned, there’s open source project contributions which, I admit, I haven’t been very involved with in the past.  There’s the dozen or so websites I’ve put together for friends and family over the years.  There’s the handful of sites for the good cause and non-profit organizations.  In some of these cases, I didn’t only do the coding, I also purchased the domain and the hosting.  There were also a couple of savvy business people who promised to make us gazillions of dollars in exchange for a beta version of the software to show the venture capitalists they have lined up.  Finally, I suppose JohnnyCoder.com could be added to to the list of “work I do for nothing” as well. 

Well, there’s a lot of debate on whether or not you can measure software development productivity.  If productivity is a measure of what you get for what you give, I guess, on a personal note, I haven’t always been productive over the years.  Now, I’m not saying it is good or bad, but I would like some additional justification for going about my “business” the way I do. 

Any thoughts? 

A couple of years back, I was tasked with compiling C# coding standards for our development department.  To be honest, I wasn’t all that excited about the assignment.  Previous attempts had been met with quite a bit of resistance and worthless debate and I wasn’t sure I really wanted to open that can of worms again.  After all, I felt that we had built a talented team of developers who saw eye-to-eye on most “technical things” so why bother getting everyone riled up? 

As you know, there are many legitimate reasons for “getting everyone riled up.”  In our case, there were two very good reasons which made my assignment somewhat mandatory:

1. We had plans to greatly expand the size of our group in the very near future and documented standards would help get the newbies up-to-speed quickly.
2. Our group’s technical roadmap was becoming more defined (heck, it was taking a turn with SOA) and there were embracing a number of technical advances such as .NET 2.0, Remoting and AJAX and we needed to ensure the existing staff on the same page. 

Ultimately, I accepted the challenge and standards were put in place with very little blood shed.  Of course, I took a few measure to ensure that mud-slinging and stone-throwing was kept to a minimum.

First, I anticipated the pain and I didn’t let it happen. To accomplish this, I guess I was a bit evasive.  I didn’t solicit any help or opinions at first.  I did endless online searches and I consulted a few books, but I avoided internal roundtable discussions. I also decided to wait until the documentation was rather polished before requesting any feedback. Once I did seek feedback, I kept participant counts low.  In fact, only a handful of our technical leaders were invited to the review before distributing before the document was distributed to the entire development group.

Second, it was established early on that there would be difference of opinion and this was okay.  Actually, it was almost encouraged, but we all (non-verbally) agreed to keep our egos out of the debate.  This ultimately lead to us coming to a common ground or simply opting to “choose our battles” and accept that we wouldn’t always get what we wanted.  This, in conjunction with everyone knowing their feedback was valued and respected, kept our conversations on track.  Also if a topic got at all heated, we quickly moved onto something else in an effort to stay focused, to keep moving forward and keep everyone happy.

Most importantly, however, we didn’t sweat the small stuff.  If you have been responsible for documenting agreed upon standards, you know what I’m talking about.  Developers tend to spend just as much time hashing out the small stuff as they do the big stuff.  When it comes to establishing your team’s coding guidelines, the devil is in the details.  The classic example is code formatting.  “Which case are we going to use? Camel or Pascal or both?”  “Is Hungarian notation really dead because there is still a lot of merit in using it for form elements?” “Should we prefix private property names with underscores?” “We will use curly braces within our if-else statements even if the conditions are only a single line, right?” “How many spaces are we going to agree to indent?  Please assure me that no one indents using spaces!  Everyone better be using the Tab key!”  There are about a million distracting, time-consuming, worthless arguments which one can have about code formatting (and other similar topics) but they provide little value. These debates can suck the life out of an initiative so beware.

I think I got lucky on my third point. To some extend, our development focus had been rapidly changing over the past few years and the individuals helping to define our standards were now interested in the big picture.  Perhaps we felt we had “better things” to discuss or maybe we had all learned from our past and we knew the danger of  “the details.”  In any case, we concentrate on the big ticket items like namespacing, data access and logging.  We traded in the time we would have given to meaningless debates and we put frameworks and templates in place.    

Whatever your reason, it is important to have standards.  Do yourself a favor.  When it comes time to defining your own, avoid the details.  Otherwise, prepare for a battle which nobody wins and nothing gets done.

What is “Rubber Ducking?” The phrase was coined by Andrew Hunt and David Thomas in the book The Pragmatic Programmer: From Journeyman to Master.  A book, by the way,  which is required reading for all coders.  In fact, it is time I reread it.  You may already be familiar with this term, but in a nutshell, the idea is that simply explaining a problem aloud often helps one come up with a solution on their own. In the words of the Pragmatic Programmer,

Place a rubber duck on your monitor and describe your problems to it. There’s something magical about stating your problems aloud that makes the solution more clear.

This is an effective approach to problem solving.  I’ve actually had a duck work by my side for years now.  He’s a good, patient, loyal duck.  Of course, you don’t need a rubber duck.  Some people use email.   In the process of meticulously documenting their problem, which will ultimately be shipped to all the smartest people they know looking for help, the solution comes to them.  Some people call a colleague into their office, point at the screen and say, “I’d like to get a second pair of eyes on this.”  The request for review comes along with a detailed overview of the problem which, in turn, begets an answer to one’s own question.  As they say in the book, it’s magical.

I stumbled upon an Interview with Hunt and Thomas which tells a bit more about rubber ducking.  It’s a quick read and it’s worth a look.

Reading your source code aloud, or explaining it to someone else, has concrete and documented value, whether in a formal setting of code inspections, peer reviews or just chatting with your cube neighbor, said Thomas. “Have you ever done this? You stare at a piece of code for an hour, debug and debug, and finally, in desperation, you pull your friend in from his cubicle. You start to explain the code and how it works, but then …” (smacking his forehead) “Oh, that’s it!”

The audience laughed again, and most of them were nodding ruefully. In fact, Thomas said, you can even resort to “rubber-ducking.” “I don’t know why it works, but it works. You put the rubber duck on top of your monitor. Then, when you’re stuck on something, you start explaining what the code does aloud to the duck.” And before you’ve finished the explanation, the solution comes to you. You smack your forehead, and politely thank the duck, he said to general laughter.

Why do I bring this up?  I am currently on a 6-week leave of absence from work spending time with my wife and new born son.  Prior to leaving the office a few weeks back, I dropped my duck off on a colleague’s desk without any advanced warning that a duck-sitter was needed.  I know the sentiment was appreciated, but I’m not positive the significance was understood.  As I mentioned earlier, you don’t need a rubber duck.  All you need is to willingly share your problems aloud.  I was this person’s rubber duck.  They always came up with the answers on their own, but not before giving me the opportunity to listen.  

I hope my duck is getting an earful right now…

We are currently going through the exercise of converting our web applications (primarily .NET web applications) from SQL Server Authentication over to Integrated Authentication.

Integrated authentication allows for SQL Server to leverage Windows NT authentication to validate SQL Server logon accounts. This allows the user to bypass the standard SQL Server logon process. With this approach, a network user can access a SQL Server database without supplying a separate logon identification or password because SQL Server obtains the user and password information from the Windows NT network security process.

Choosing integrated authentication for ASP.NET applications is a good choice because no credentials are ever stored within your connection string for your application.   Thus, security is improved.  Another reason to incorporate Integrated Authentication is to facilitate account and password policy enforcement through a domain controller.  For example, this might require passwords be recycled every 90 days.

“Integrated Authentication is not difficult to implement.”  I’ve heard this time and time again.  Actually, in an ideal scenario, this is a correct statement and the implementation requires just a few steps:

1. Set SQL Server Authentication to Mixed Mode.

2. Set identity impersonate to true and assign the username and password in the IIS.

3. Update you connection string to use one of the following variations:

    a. data source=myServer;initial catalog=myDB;Integrated Security=SSPI 
    b. server=myServer; database=myDB;Trusted_Connection=true

Easy, right?  Sure.  But what if you are converting to NT Authentication and your existing network and application(s) are not ideally setup?  In this case, there are a number of potential (read probable) gotchas. 

There are three obstacles I wish to discuss, but today I am going to focus on one of them. This issue is the most obscure and I would bet that the majority of those tasked with estimating a conversion to NT Authentication would not even consider this condition.  I’m also calling attention to this gotcha first because, in my opinion, it comes with painless and noteworthy solution.

Gotcha # 1:

Our web applications call upon a number of Windows Services.  These services should be considered legacy components.  They have been around for a while and they continue to do their job so they get little attention.  Each of these components store connection string information in the registry. 

As you have noticed, connection string formats vary based on the authentication method.

Integrated Authentication
data source=myServer;initial catalog=myDB;Integrated Security=SSPI;

SQL Server Authentication:
data source=myServer; initial catalog=myDB; user id=myUsername; password=myPassword; 

In this case, the registry held the four primary SQL Server connection parameters and the service would use the associated values to build the string on the fly.  Can you see where this is going?   Fortunately, we identified this little issue early on and we estimated time to rework the functionality, rebuild, test and redeploy the services.  This was risky since these services were rarely modified/deployed and it was going to be expensive since there were more than a dozen services which required these changes.

This was until a colleague of mine uncovered an elegant hack. [Is that an oxymoron?]  He discovered that once the Integrated Security parameter of the connection string is set to SSPI parameters such as User ID and Password are virtually ignored.  (He also found out that extra semi-colons don’t make a lick of difference either.) 

In the end, we hacked our registry entries to allow our services to build and use NT Auth compliant connection strings. 

Sample registry entries:

Resulting connection string:

datasource=myServer;integrated security=SSPI;initial catalog=myDB;user id=;password=;

This reduced risk and simplified our deployment to modifications to the registry through the execution of a single .reg script. 

Opening up the services and redeploying may have been the best solution, but this hack got the job done safely and effectively and on the cheap.  And we learned a bit more about how connection strings work.  Who knows?  This tip may help you out of a pinch someday.

Are you indexed by Google? Well, JohnnyCoder.com isn’t. Here’s the thing. The URL was submitted a while ago, but it hasn’t made a lick of difference. But I shouldn’t be surprised since Google is very up-front about how they handle submissions.

We add and update new sites to our index each time we crawl the web, and we invite you to submit your URL here. We do not add all submitted URLs to our index, and we cannot make any predictions or guarantees about when or if they will appear.

As you can see, Google doesn’t make any promises.

So, what else can I do? Well, I’ve started sending influential thoughts Google’s way. When I’m feeling particularly positive, I hold my breath and check if my site’s status has mysteriously improved. This is done by executing the following Google site search. Of course, the outcome is always the same:

Your search - site:www.johnnycoder.com - did not match any documents.
Suggestions:

• Make sure all words are spelled correctly.
• Try different keywords.
• Try more general keywords.

And as you can see, along with promises, Google doesn’t make any suggestions. (No helpful ones at least.)

I haven’t given up on Google yet. I’m sure they will start indexing my site when they are good and ready. After all, they are the search kings and they must know what they are doing. In fact, I’m sure it’s not them. It must be me and what I’m not doing. But I really didn’t know what to do so I have started to do some research. I found that most sites provide teasers. It’s helpful information, but not too helpful — if you know what I mean. The sites may say to submit your URL to Google (as I have already done.) Otherwise, their advice is to leave search engine submission and optimization to the experts and purchase their service for only $99 annually.

At least Submitside.com collected search engine “Add URL” and put them all in one place. They also recommend submitting only to the following: Google, Yahoo! and MSN. And only if you are plenty of time should one submit to these smaller engines — Rex, Infotiger, Netsearch Voyager, ExactSeek, LinkCentre, HotRate, TrueSearch, WhatsNu, LookSeek Susy (South Africa), Walhello.com, Dirs.org and Wisenut. They also list a number of engines which one should NOT bother with since many providers actually “power” others and submissions would be redundant.

Most everyone is an agreement. Submitting your site is not enough. Indexing will take up to 8 weeks (if at all) and this alone is not enough to start getting visitors. Being in the top search results depends mostly (but not only) on popularity of your site and a new site is not popular at all. So you need a different strategy.

One approach is to increase the number of links to your site from more popular sites. I suppose this could be done through the use of Technorati or by simply adding comments which link back to your site on other peoples’ blogs. Or by simply begging a popular site owner to add a reference to your site.

Arguably, the best strategy is to “buy” traffic through paid listings. This unique form of search engine advertising means that you can be guaranteed to appear in the top results for the terms you are interested in within a day or less. If you wish to build visibility quickly it is agreed that this is the way to go.

SearchEngineWatch provided a really nice breakdown of this information. They suggest that any site owner established a search engine submission budget. This is true whether you’re running a commercial web site, a hobbyist site in your own time or a site for a nonprofit organization. They suggest you first submit to Yahoo’s human-compiled directory for one year. This is a flat rate of $300 annually. They believe this provides the most bang for your buck merely because this is potentially one of the best links you can gain to influence crawlers. If you need to be listed fast, however, they suggest one use paid placement programs as well. A $50 budget for Overture (which is now Yahoo! Search Marketing) and a $25 budget for Google will last about a month. SearchEngineWatch does claim you can get listed without spending a penny, but if you want to be seen in as many places as possible, as quickly as possible, you will want to use the combination of submissions which they outlined above.

So far only about half of the articles I’ve read are even interesting, but I have learned the difference between directories (like Yahoo!) and crawlers (like Google, Ask and MSN.) And I’ve learned about paid listings like Overture and Google AdWords and I have learned a bit about how search engines work when it comes to page rankings and who feeds who. I’m learning, but not even dangerous yet. Unless someone has an extra $375 to fund my search engine submission budget?

Before you submit your next job posting, keep the end result in mind. If you are in the market for talented, interesting people who are accountable for producing quality work, you may wish to give your job listing a second look.

Haacked.com discussed the Art of the Job Post today. The article shares where the great majority of job posters miss the boat and offers tips to get back on track.

The author suggests that one should avoid the standard, monotonous outline of the potential employee’s role and responsibilities. One should not focus solely on what a candidate must provide your company, but, to the contrary, the emphasis should be on what the company has to offer.

A good job ad should not explain what hoops the candidate must jump through to join your company, it should explain why the candidate should even want to jump through those hoops in the first place.

For example, you should not be afraid to cough up information about your company’s personality and culture. After all, a good candidate is going to ask about this anyway.

Sure, many corporations seem like soulless cubicle farms in which workers are seen as mindless drones. But surely not your company, right? So why does your job posting have a tombstone all over it?

You should also “appeal to the vanity” of those seeking employment. Challenge the candidate to show how great they are. As the article states, asking the individual if they are a good problem solver conjures up the desire to prove it.

Again, your job posting should be a request for interesting, talented people — not just those who have methodically pack their resumes with the alphabet soup they think will help them land the offered position. Find these people and it is a win-win for everyone.

In my experience Haacked.com’s comments are accurate. Most job postings are bland and focus only on experience, skills and responsibilities. Heck, I’ve been involved in the hiring process for a few years now and I’m guilty of using the same cookiecutter job description template as everyone else. Shame on me, right? Well, I will give myself some credit. I do request team players with strong verbal and written communication skills and a willingness to learn. But these are only secondary criterion. First and foremost, I evaluate a candidate’s experience and it is their technical know-how which lands them a phone screening. In the end, however, it’s the “soft skills” which get the individual hired.

There’s a lot to be said about the hiring process. It can be extremely frustrating, but also unbelievably satisfying. As one can imagine, it’s crucial to get off on the right foot so mind the “Art of the Job Post.”

I’m sure there’s more to come on the topic in the future…

Have you had a chance to look at Google Code Search? It truly will help you find function definitions and sample code by giving you one place to search publicly accessible code through the use of regular expressions and language and filename filters, but this is taking a backseat to what Code Search can really do…like discover vulnerabilities in the indexed code and make you laugh.

How’s about this? Discover what coders are cursing about. Find complaints about stupid users. Realize that you aren’t the only coder who hates their job. And find out who is coding drunk or who begs forgiveness from the coding gods. This is just the fun stuff. Find “real” vulnerabilities at kottke.org.

Exception handling is extremely important, isn’t it? When it comes to testing, troubleshooting and maintenance it is paramount. Exception handling is definitely highlighted on every developers list of application technical requirements. So, why don’t all applications have proper exception handling? I have a few ideas.

The first and most likely reason is most developers (no matter how experienced) don’t have a good understanding of how to do it. This operation may seem trivial to some, but it actually takes a good amount of attention and care to do correctly. Granted, in many cases it’s perfectly fine to simply wrap the contents of a function with a “generic” try/catch block and merely bubble the exception up to its caller. Great. But what does the caller do with the exception? Nine out of ten times the caller, in turn, will also bubble the exception up (because that’s what the “pattern” does) or it swallows it. Even if a coder uses this bare bones approach, there are usually issues with the implementation. For example, there is a big difference between throw; and throw ex;. The difference is that throw; preserves the original stack trace and throw ex; truncates the stack trace below the method in which the throw ex; call is located. Most of the time, throw ex; is inappropriately. There are many other examples of poor exception handling, but here’s my favorite — the coder does everything “by the book” until it is time to display a error page and a coder reveals the exception details including secure information such as connection strings to the user. Yikes! Not understand proper exception handling can be dangerous.

The second reason is priority and timeline. Exception handling isn’t sexy and, let’s be honest, it doesn’t need to be in place before an application can be deployed. Hence, exception handling is usually pushed to the backburner — along with technical documentation. Only once the application requires future troubleshooting do we feel the pain of the missing “requirement.” Interesting enough, a colleague of mine now waits until his code base is quite stable to implement his error handling. He does this without regard for priority and timeline. He’d prefer to have his application assume unnecessary fatal errors early on it the project lifecycle rather than mask the issues through improper exception handling. All the same, timeline is still a standard developer excuse for lack of error handling.

The third reason is ego. Aren’t we all a little guilty of thinking our code can’t fail? After all, we can’t have a bunch of coders with defeatist-attitudes working on our projects. :) Without the safety net of exception handling, we are bound to write better code, right? (Of course, this argument doesn’t hold a lot of water since it would promote getting rid of the QA team if we wanted really good code.) I do think ego is a factor though, but I’m not sure to what extent.

That’s my take on exception handling. What do you think?

Code generation is not a new concept. It has been around since the first lazy, err, smart coder realized that Hello World was the foundation of Hello World Too. I’m sure they figured they had written the code twice already and the third iteration is undoubtedly around the corner so they felt somewhat obligated to automate the process.

I’ve had the opportunity to see code generation in action. I’ve seen CodeSmith leveraged to the extreme — with a single click, a completely functional three-tiered application could be built before my very eyes. It is like magic. It is super-impressive and I commend anyone willing to put time into a building the code generators because they are awesome. And there are many advantages to auto-generating code:

1. Code consistency
2. Stable, tested and bug-free code which “works first time”
3. Produced very quickly
4. Easily updatable
5. Programmers are free to concentrate on the areas of development that deserve their brainpower
6. Increased productivity
7. Learning aid — If the generated code is well written and consistent, programmers are more likely to copy the style of this code and learn from it

Does code generation make good sense to me? After all, I use it all the time. (Kind of.) You see, I tend to refactor my code and compile reusable libraries with common functions. I have templates for building custom classes and collection. I hardly ever write a routine without consulting my previous work (or the work of others) and I can’t remember the last time I started a project from scratch. I alway begin with an existing, similar project and then modify it for my needs.

As you can tell, I am a proponent of code reuse. I believe in patterns and I have no dream of reinventing the wheel. With this said, I am not a fan of code generation. Is there something wrong with me? Well, here are the disadvantages to code generation. You decide.

1. A code generator must be written and tested thoroughly before code can be generated. This task time and effort and it adds some risk since you can’t get the “real” project out the door unless the generator is production-ready.
2. Code generators really only work for specific applications with specific use cases. Code generators are best suited for admin-type applications which entail no business logic. If your application is nothing but CRUD then code-gen might be right for you.
3. There will always be some code that needs to be hand-crafted. If the code generator doesn’t allow you to “support” hand-crafted code, you’re in a tough spot.
4. Most code generators work off of an existing database schema. In most cases, a well formed databases (i.e. specific primary and foreign key names, normalization, etc) is required and generators generally do not cope well with databases that have special, “unique” design features. In addition, I don’t believe business objects should exactly mirror the associated database objects. For these reasons, code generators tend to lead to bad system designs.
5. Code generation leads to poor performance. This one is obvious, right?
6. Generated code is difficult to maintain. I should be really clear on this point. Without a firm, working knowledge of the code generation tool itself, the code is difficult to maintain. Unfortunately, there is little guarantee that the original author of the code is going to be the developer slated for maintenance.

It isn’t that I wish to be a modern-day John Henry. Simply, I believe code generators have their place and it’s not in my toolbox (except for really simple cases.)

I stumbled across, Phil Bradley’s Great Spam Experiment the other day. In an entertaining, educational and borderline-scientific manner he answered the age-old question — where do we get spam?

First, he went looking for spam. He created about a dozen email accounts which would be publicized through various sites and services. For example, one account posted to a news group whereas another was simply included in an HTML mailto: link on his website.

Next, he waited for the spam to come rolling in — and it did. After about 12 weeks, he categorized the results and published the spam winners and losers.

I won’t ruin the surprise and tell you where the most spam is propagated from (okay, it’s from opting out of emails), but I will say that it was interesting to see that the majority of our spam falls into three categories: Financial, Pornographic and Health. Since Financial was the overall winner, I guess we’re going to have to start saying, “Money and Sex” rather than “Sex and Money.”

My thanks for Mr. Bradley for an entertaining article.

I thought I’d give Mozilla Thunderbird a try this week. It’s not that I’m unhappy with Outlook, but the pretty Thunderbird icon has made the application somewhat irresistible. (I also wanted to manage a few of my email accounts independent of others — outside of simply setting up multiple accounts in Outlook — and using a second email client happens to do the trick.) Thunderbird 1.5 was release in mid-September. According to the release notes, this version did not include any significant enhancements outside of stability and security bug fixes, but it is a recommended download for everyone. After downloading, I stepped through the recommended setup. The installation would have gone very quickly, however, I allowed Thunderbird in import my account settings from Outlook which copied over everything - include tens of thousands of emails. This took a while. After launching the application, my first thought was, “Good. They didn’t try to reinvent the wheel. The interface is standard and rather intuitive. Good for them.” I then setup a few accounts which was painless, but I would change a couple of things. First, I wouldn’t separate the management of POP and SMTP Servers. I also would allow passwords to be provided when originally setting up an account — not when first trying to access the account. A ‘test connectivity’ option would be nice as well. It may be available, but I missed it. I’ve been using the tool for about two days now and I’m pleased with the basic functionality. And I have to give the Thunderbird Team credit for “the sophisticated and very well integrated Bayesian spam filter” and the integrated RSS feed reader as well. And, like Firefox, Thunderbird has Add-ons (extensions, plug-ins and themes.) I’ll have to take a look at what else is offered before making a final judgment. Here’s what you will here about Thunderbird on the Mozilla site: