Recently, I was involved in a discussion with a colleague of mine that was focused around TDD – Test-Driven Development.
During the discussion he mentioned that he personally finds the process of coding up the method first and test later to be easier, natural and more efficient. Writing the test-first just seems more difficult to do and less efficient. He then went on to state his reasons:
He said, and I agree with him here, it’s probably easier and feels natural because that’s the way he has always programmed. Create functionality and then test that functionality. TDD flips that around and as result you have to “re-learn” development. Something he wouldn’t mind doing, expect that…
In his opinion, TDD is a slower way to code. Here is his reasoning: A great majority of the time, you’re going to change the code that you wrote to begin with – you will rename the class or method, move things around, change the number of parameters or throw away the first attempt and start again. If you were to write the tests first then those tests would have to change as well! As a result, you’re increasing the amount of effort involved. It’s much faster to just write the test after the code has been finalized.
Until a year ago, those were my thoughts exactly. Then one day (well, probably more like over a period of several months, several books and several articles) I finally found the missing piece to the puzzle. The piece that made TDD possible for me without causing me spend countless hours making significant changes to my test cases because I would keep making significant changes to my code-base. I realized what TDD actually states. Which is: Do NOT write a single piece of production-code before first writing a test for it. And there it is, the missing piece to the puzzle – production-code!
Ah ha, I said! I finally get it! In other words, if you’re unsure how about the solution is going to look like or work – write non-production code first to work out ideas, fill-in the gaps in requirements, get your questions answered, and get a feel for what the overall solution will look like. Then and only then are you ready to write production-code!
Here is the process I now follow during the development:
1. Write a spike or POC code to “brainstorm” what the solution might look like. Sometimes I spend quite a bit of time here. Since in the brainstorming process you’ll find out gaps in requirments or will have to go research the third-party product that you’re planning use.
2. Once you’ve got a good grip on what the overall solution might look like and how it’s going to work, I throw away the spike (or at least put it out of sight).
3. I then write a failing test case.
4. Write code to make it pass.
5. Back to Step 1 if I am unclear on what the next piece of functionality entails; otherwise, Back to Step 3.
So I mentioned that to him and he sort of agreed but not really. He was sort of on the fence. After further discussion we hit upon another point on why to follow TDD that really hit home for him. Here is the example I gave him:
Consider the following: You’ve got X number of test cases in place for a piece of existing functionality. All of the tests pass and everything is working just fine. Then you get a change request. You make the change and then run all the tests. They all pass. Are you done? It’s a little difficult to say, isn’t it? Somewhat open to interpretation. I’ve come across developers who think that they are done at this point because they didn’t break any existing tests. But they forgot to ask – have I added a test for the new change that I made?
On the other hand, if we were to first write a failing test for the change request then there would be no debate on whether or not a test is needed. This where TDD really shines and ensures that we’ve got tests for all of the functionality. When pressure creeps in, and this is especially true for change requests, then the discipline to add tests after the fact even when all of the existing tests are passing becomes very hard to follow-through on.
Sorry for the long-winded ranting. Hopefully you got something out of it. 
Unobtrusive JavaScript with HTML 5
HTML 5 supports a new feature known as Custom Data Attributes. These attributes give us the ability to define custom attributes for ANY HTML tags. The only restriction is that the tag must start with “data-”. For instance, we can add a custom attribute to a link as follows:
<a href="#" data-search-by-type="<value>">My link with custom attribute</a>
This feature comes with a neat benefit that we no longer need ANY inline javascript inside our HTML content. For instance, say, we’ve got a commonly-used javascript function that performs a search by searchType:
function search(var searchType) { ... ... }
Prior to HTML 5, we would invoke the function using inline javascript inside our HTML tags:
<a href="javascript:search('byName')" class='search-link'>Search By Name</a>
<a href="javascript:search('byType')" class='search-link'>Search By Type</a>With the introduction of Custom Data Attributes, we can now completely do away with the in-line javascript and write the links as follows:
<a href="#" data-search-by='byName' class='search-link'>Search By Name</a> <a href="#" data-search-by='byType' class='search-link'>Search By Type</a>
We would then add the following to our common.js file that contains the search() function:
$(document).ready(function() { $(".search-link").click(function () { search(this.getAttribute("data-search-by")); }) })
The Custom Data Attributes in HTML 5 gives us a benefit that is similar in nature to the benefits provided by the CSS model – namely, separations of concerns. CSS enables us to separate content from the presentation of that content, thus enabling our HTML pages to follow a well-defined structure.
Similarly, with Custom Data Attributes we can now separate logic or functionality from HTML content. This provides with the following benefits:
- We no longer need to pollute our HTML with in-line Javascript.
- Keeping all our Javascript functionality centralized makes it much easier to manage.
- The use of Custom Data Attributes increases code re-usability since they can effectively serve as parameters to our javascript functions.
On conducting technical interviews…
As a software consultant, I’ve both gone through and conducted a fair share of technical interviews. By conducting interviews, being interviewed and watching others interview I’ve learnt a few things myself. Below are some tips on what works and what doesn’t when interviewing software developers…
1. Ask the candidate to write some code!
IMHO, this should be one of the first filters. The coding question should be simple enough that it would take a decent coder less than 5 to 10 minutes to code. The purpose here is to filter out the “talkers” from the “doers”. For instance, if the candidate is having trouble coding a method that reverses a string, then it doesn’t really matter how many years for experience they have, what company they last worked at, or how big the project was! If they are having trouble remembering the a string is char[], then they are not someone you want on your team.
This little test may sound too easy or “something that anyone should be able to pull off”, but you’ll be surprised at how many candidates are be unable to write a simple method when asked to do so.
For interviews that are conducted remotely, you can have the candidate share their screen (I typically use Skype or Join.me), ask them to open up notepad and code the solution.
2. Separate the behavioral interviews from the technical interviews
Be fair to the candidate – let them know ahead of time what sort of interview will be conducted and by whom. It’s very confusing for a candidate when behavioral questions are mixed-in with technical ones. This is because behavioral interviews require answers that contain a different vocabulary and are geared towards a different audience. The candidate that is answering a behavioral question is usually careful to answer the question at a high-level without getting into the nitty-gritty technical details. The answer is more focused on their contribution, how well they worked with others, how issues were handled, etc. Whereas a technical answer would cover things like: what specific technology was used, how was the functionality broken out, what sort of development model was used, what approaches did they take to test their own code, etc.
Letting the candidate know what sort of interview is being conducted and by whom will enable them to put forth clear and appropriate responses.
Which brings to my third point…
3. Please have the candidate go through AT LEAST one technical interview!
It’s surprising how many managers, that haven’t looked at code in ages, feel they have sufficient knowledge to hire a software developer. Software development is changing – rapidly! The skill-set required 5 years ago (or even a year ago in some cases) is quite different from what’s required today. So you if haven’t kept up, you will have no way of knowing whether a candidate is right or wrong when they tell you that an ORM is an Object-Role Model that allows you to map roles (yes, I did have a candidate tell me that). By all means, have the managers do the behavioral interviews – which, by the way, is a crucial part of the selection process – but PLEASE leave the technical interviews to your technical folks. If for some reason you’re not in position where you can have your own developers do the technical interviews (and there are many valid reasons why this may be the case) then hire an outside consultant to conduct the technical interview.
The last thing you want is someone who is adept at talking through the concepts and seems to knows all the technical buzz-words but is very poor when it comes to writing code. And, for some odd reason, there are many “senior-level developers and architects” that are just that!
5. Skip irrelevant questions – such as brain teasers
Instead, ask questions that require some creativity and thought to answer. For instance, say you want to find out whether the candidate that is being interviewed for a web development position has the habit of looking at and thinking about the big picture. One question that may help gauge this is: What are some common performance or security related issues that surround web development and what are some strategies to circumvent them? It’s okay if they can’t fully the answer the question. What you are looking for is whether such thoughts and questions have crossed their minds and how much time they’ve spent thinking about such issues.
Another example is to give them a user story from your actual project (after maybe simplifying it a little) and ask them to sketch an object model for the user story. What you are looking for is: What sort of class names they come up with, what sort of methods these classes contain, whether the relationships among the classes are represented correctly, does their overall object-model look “clean” and easy to understand?
Another question that requires some brain-power and creativity is to give them a user story and ask them to come up with a list of test-cases for the user story.
6. Find out if they actually like (nay, love) software development!
Ask them if they are currently learning or have recently learned a new technology outside of work. What was the last software development book they read? How long ago? What did they learn from it? Any mentors, role-models they follow? Have they read or follow the following persons: Uncle Bob, Martin Fowler, Scott Hanselman? (Big red flag if they haven’t heard these names before). Where do they see themselves a year from now, five years from now?
Lastly, please keep in mind that these are my opinions that I have reached through my own learning and experimentation. You may or may not agree with them and they may or may not work for you – and that’s as it should be. Try them out if you’d like, modify them as you deem appropriate, and definitely invent your own.
Conducting interviews, much like giving interviews, requires constant refinement. Filtering out and selecting the right candidate out of a pool of qualified candidates is never easy. Hopefully, the above tips will prove somewhat beneficial to you while searching for the right candidate.