A few interesting links

Things have been crazy the last couple of weeks, so instead of a normal post today, I'm going to do a short little link post. Here's a few links I've found in the past couple of weeks that I've found interesting.


If you are currently training to take a MSDN Certification, you can currently get a free retake exam if you take both the first exam and the retake by June 30, 2010. You can find more about this here.


For my exam, I'm planning on just reading the Self-packed training kit, doing the exercises, and answering the sample test questions the book provides. However, I would also like to take another practice exam, so I will be using the free exams offered by Accelerated Ideas.


At my office, its the time of year for performance reviews. Like most geeks, I'd like to look nice, but I'm not quite certain how to go about it. I found this blog post on Lifehack particularly interesting. However, I don't agree with the author that non-pleated pants are more slimming then pleated pants. My worst looking pair of pants were a non-pleated pants. Most of my pants are pleated, and I don't think I look any worse for it.

There's also more information about men's fashion at this blog post on Wardrobe Oxygen, but I'm a little more skeptical of the advice presented here. I just don't think sandals are a necessary item for a men's wardrobe. I find sandals very uncomfortable, and not appropriate for the office, even one where the dress is business casual.


I came across an interesting blog post the other day regarding the writing style of popular blog posts. The author surmises that popular technical blogs are popular because they don't just share information, they also tell a story. While it would be nice to think that there are many people out there just waiting to read what we have to write, the reality of it is that they have to be drawn into your writing.


Finally, there is a new website that proves that interesting stories do indeed make for interesting reads.This site is a tutorial for the source code tool Mercurial written by Joel Spolsky. The site is very well designed and the tutorial is a fun read. Even if you aren't using Mercurial and won't be anytime soon, I'd still recommend that you read it.

Switching Projects

I've had to work on a couple of different Software solutions in my 5 year career. Each time I've made the transition I've felt like a fish out of water for the first couple of months while I learn what the software does, how the code works, and what processes and tools the team uses. In order to save some hassle during the next transition, here are a few tips and suggestions for transitioning to a new role to maintain an existing application.

1) Read through any documentation that the client is expected to read. This will give you an idea of how the product works (helpful in recreating/unit testing later) and introduce you to the terminology used by the software team and clients (useful in communicating with others).

2) Walk through the software and play around with it. As mentioned above, you will eventually be expected to navigate around the software to unit test it and to recreate defects. The more you become familiar with the project at the beginning, the easier your task will be later. But remember, when doing your testing, make certain you do so on a stable build. Encountering defects while you are still learning the system can be confusing.

3) Setup your development environment and download the source code, following any documentation that your team might have. I really like the suggestion Joel Spolsky made on the StackOverflow podcast #80, if the documentation is inaccurate, fix it. If it isn't detailed enough, add to it. If it doesn't exist at all, then write it yourself.

4) Are there any special design documents, a wiki, or some other supplementary documentation for the code? While these documents are rarely kept up to date, they may explain how certain key features of the software work.

5) Learn the basic structure of the code, and learn what the key methods and classes are. It's best to try to learn this on your own, but if you make an effort to learn the code before asking another member of the team for help, most of the times they will be happy to help you.

6) Learn who the key people for the project are. There's always key people for any project, the project leader, the lead developer, and often there's a business analyst, and a lead QA Engineer. It is important to know who these people are and understand how you will be expected to interact with them on designs, code hand-offs, and defects.

7) If there are any Third Party utilities used by the software, learn where they are used and make certain you understand how to use them. Some may be as simple as an external library, while others may as complex as Document/Report generation tools or Business Logic tools. It would be foolish to expect you could become an expert in these tools, but you should at least know what each do.



This should provide you with a rough outline of what to do when you are assigned to a new project. Depending on the work load you are given, you may not be able to accomplish everything on this list, at least not initially, but everything on this list is important and should be done eventually if you want to be able to contribute to the project at a high level.

The current state of your Development Team

If you're a manager of a software development project, how do you gauge the morale and mood of the team? I mentioned in a previous post that my boss recently took the direct approach and asked us all to answer a series of questions relating to our morale and such.

For this approach to work though, I'm pretty certain everyone needs to be honest. Given the current working environment (high unemployment, worry of layoffs, pay cuts, etc.), its unlikely that many, if any of the team members provided accurate results. There's just too high a risk that the information could be used maliciously. Personally, I provided a lot of well thought out responses that are true, but I certainly didn't share all of my thoughts on the questions and I carefully edited the responses. Wouldn't you?

I suppose the answer to that question is “It depends on the situation.” What kind of work environment is it, what's the culture of the company, what's the history of the company, what is the management team like, and how the question was asked. In some corporations, the level of distrust between management and employees may be too high to get useful responses from an employee directly.

But surely there are other ways to find out the current state of your team besides asking the team members directly? None of my other managers has ever asked the team what their morale is directly like my current manager, but surely they still had a good idea of what the team's morale was like?

And I think the answer to that is quite simple; all of my previous managers tried to engage the team members in meetings or in hallways. By talking to each members of the team on a regular basis over a long period of time, they were able to discern when the attitude of the team had turned sour and try to improve it when needed.

But as a manager, asking employees directly is probably not the best approach unless you're certain your team trusts you enough not to use the information maliciously.

Recommended Reading

Here's my recommended reading list, with computer science or computer engineer students in mind, as well as junior Software Developers.

Code Complete by Steve McConnell
A must read for all Junior programmers, Code Complete covers everything you need to get started in professional software development. My College education was very heavy on the theory and didn't cover much of the actual practice of Software development. This book helped bridge the gap and should be required reading for seniors in a Computer Science program.

Design Patterns by Gamma, Helm, Johnson, and Vlissides
This is the ultimate book on software design. Its over 15 years old, but it is still packed full of useful information. You'll find that many of the common libraries that you come across use some of the patterns laid out in this book, and it is helpful to understand their convention. I've always found this book to be a little difficult to read because all of the code samples are in Smalltalk, but if you can learn enough
Smalltalk to understand the samples, this book should make sense to you.

Refactoring by Martin Fowler
If you've done maintenance programming of any kind, you'll have an appreciation for the principles and steps defined in Refactoring: Improving the Design of Existing Code. This book explains many common Refactorings, reasons why you might want to do them, and suggestions on how to perform Refactoring on large projects.

Refactoring to Patterns by Joshua Kerievsky
Ideally, you should read this book after reading Refactoring and Design Patterns, but I actually read Refactoring after this book. I was still able to understand this book, which is a huge achievement both for the author of this book, Joshua Kerievsky and the author of Refactoring, Martin Fowler, who came up with very simple and easily understood names for his common refactorings. With better examples then that provided in the original Design Patterns book, I was able to fully understand the power and beauty of the Design Patterns.

Web Technologies by Jeffrey C. Jackson
If your College experience is/was like mine, then you covered regarding Web development. With nearly everything on the web these days, understanding the technologies behind it is essential. This book covers many different Web Technologies, including HTTP request, HTML, CSS, JavaScript, Java Server Pages, and Web Services. This book serves as a good introductory or intermediate text book on the Web.

Mythical Man Month by Frederick Brooks
This is the quintessential book on project management. The lessons taught in this book are so important, that you may have already learned them from others or through other books, as this has been a very influential book. But just as you might choose to read Poe's The Raven despite having seen it parodied by dozens of cartoons and shows, so to is it important to read the original source for many ideas in project management and software development.

201 Principles of Software Development by Alan M. Davis
I've just picked up this book a few weeks ago. It is a very simple read. Each of the principles takes about just a few sentences to explain, and then the author provides a link to the original source of the principal. If you've run out of books to read on software development, this one just might point you in the direction of a few other great books.

Dreaming in Code by Scott Rosenberg
All of the other books are pretty technical and can be difficult to read. Dreaming in Code reads like a story because it is one. It is the story of a software project named Chandler. The book follows the course of the project for the first couple years after its inception. The book outlines delay after delay, and gives an insite into the software development process and shows that even the smartest programmers may miss the mark.


I have a few other books I'm currently working on, but reviews of them will have to wait for a second installment at a latter date.

If you are looking for a good introductory book for a particular language for cheap, Barnes and Noble used to publish and carry a series of books on different languages, but they do not appear on their shelves. Since I live next to a Borders, I rarely find myself in a Barnes and Nobles so I haven't verified that they still carry these books.

Validating a Phone number field with Regular Expressions

Validating user input is a very common task when building a program with a user interface. While this task may appear daunting at first, it can actually be quite easy. Once you know of a good approach.

Regular expressions were born in the Unix world, but they can Be of great benefit anywhere. Regular expressions are complex and intimidating, but once you have mastered the basics they can be used in many tasks.

Let's look at a common usage of Regex: to validate user input. In the following code, we need to verify that the string phoneNumber contains a valid US phone number. First we need to verify that only numbers are imputed into the system.


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber, @"^(\d+)$");
}


Doing a quick test reveals that indeed a string of 123456789 is considered valid. However, so is 123 or 1234567890. Clearly we need to verify length of the string in addition to content. The following code will ensure this:


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber, @"^(\d{10})$");
}


While this is an improvement, there is still much more to consider. What if the user places the area code in parenthesis? This is a fairly common practice and should be accounted for.


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber, @"^([(]{0,1})(\d{3})([)]{0,1})(\d{7})$");
}


This code checks to see if there is zero or one parenthesis, 3 digits between the parenthesis and 7 digits after.

But, there are still other possibilities to consider; such as, what if the user uses white spaces to delineate the different sections of the phone number?


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber,
@"^([(]?)(\d{3})([)]?)([ ]?)(\d{3})([ ]?)(\d{4})$");
}


Or if periods are used?


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber,
@"^([(]?)(\d{3})([)-]?)([ ]?)(\d{3})([ -]?)(\d{4})$");
}


Or dashes?


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber,
@"^([(]?)(\d{3})([)-.]?)([ ]?)(\d{3})([ -.]?)(\d{4})$");
}



The final code snippet will validate most US phone number formats, in just 1 line of code. There are certainly other methods to validate a phone number, but can they be written in 1 line of code?

Team Building Exercises

My current manager recently posed several questions to the team that he wanted candid responses too. He's new to the organization, but he seems genuine in his efforts to improve our process. Several of his questions have gotten me thinking, which I'll turn into blog posts over the course of the month. The first I wanted to discuss is about team building exercises.

My manager asked for suggestions for a team building exercise that we could do. He never explained what he hoped to get out of the exercise but I'm sure it is the generic "get to know each other, build team cohesiveness" mumbo jumbo. On previous team outings we've played laser tag and gone bowling. I believe the team building value in these activities was minimal and was mostly chosen for the entertainment value.

So, what activities could a development team do together in the sake of team building? Here's a few suggestions that I have, though I've not been able to put into practice.

One idea is team lunches. Getting everyone together in one room for an hour in a relaxing environment can be good for the team. The boss doesn't even have to pick up the tab (though it doesn't hurt). An alternative to this would be a lunch pitch-in, where everyone brings in something to eat.

Another alternative is to have a brown bag lunch every so often and select someone to present information on a specific topic. Perhaps a particular design pattern, or new technology, or a new programming technique could be demonstrated. Maybe there is some new internal software being developed that the team could benefit from learning about in a relaxed setting.

If your development projects are like mine, they could use some internal documentation. You can address this issue as a team building exercise by setting up a documentation tool, like a wiki, and ask the developers to submit articles to the wiki. So long as the productivity doesn't suffer you could even create a contest for the best written article, or the best diagram.

Estimation poker itself can be a fine team building tool as well, and it provides some useful output; Estimations for code changes that have been hashed out in a group. Some more information on estimation poker can be found here.

Finally, my current manager has started a new team building exercise with us, he gives us a series of hints about a person on our team and we have to guess who it is. We've done this a couple of times and is a great way to learn about each other.

What team building exercises have you attempted or thought of?

Writing my way to better health

I've made a few references to the PDA that I own. I've found it very handy to use in many places where a laptop is too bulky, like the car or exercise bike. The last six blog posts were either written or edited while on the exercise bike. This is great multitasking that would be difficult to do with a laptop, though there are items out there for this task.

There are a few down sides to working in this fashion. First, because I am spitting my focus between two tasks, one may suffer. I can usually keep a good 10 or 11 mph pace on the bike, but I've found myself going at a more leisurely 8 or 9 mph pace.

Second, the device lacks grammar and spell check. I'm forced to do my best on my own, or hold off checking until I transfer the post to the PC.

The device also lacks internet access so I must wait to do any research or programming until I am on my laptop.

Finally, while the device does its best to translate my chicken scratch hand writing into text, my writing is a bit illegible, especially when on the bike.

Despite these drawbacks, I am getting blog posts done and I'm getting some great exercise while doing it. Given the results, I will deal with drawbacks.