Free Range Software

Internet TV is Here

2011-07-21T18:27:00.005-04:00

Image: digitalart / FreeDigitalPhotos.net

Note: Apologies for the long gap between posts. We've had quite a busy 6 months, but we're back to a bit of a routine now and I hope to be able to post more regularly.

My wife and I recently moved to a new house and one of the highest priority utility hookups on our list was internet access. The only available broadband connectivity was through the local cable company which, like all cable companies (insert sneer here), offers mostly package deals. That left us with an interesting question. Do we get cable TV or take the plunge and go Internet TV only?

I should preface this by saying that we don't watch a ton of TV and the TV we do watch is mostly movies and a handful of TV shows (Mythbusters, Madmen, Dexter, etc). If you're the kind of person that loves to channel surf and watch live TV, Internet TV is probably not for you. For us, it's more than enough and has several advantages:

- We were already using Netflix on demand on our computers, so moving it to the TV was a natural next step. Most of the devices out there supported Netflix, so this was a no-brainer.

- We HATE commercials. Broadcast television is so littered with mind-numbing, soul-destroying ads that we just gave up watching certain shows. Boo. Internet TV is (usually) much better about this, particularly if you're using pay services like Netflix, ITunes, Amazon, Hulu Plus etc.

- It's cheaper. Well, in the long run anyway :). Our internet access with the local cable company was roughly $40 cheaper per month without TV included (depending on the package, current offers, etc). Our Netflix subscription is $9.99 a month. Most of the media center devices out there ranged from $100-$700, which, even in the most expensive case, would pay off after the first 2 years. For the cheapest, it's saves us money after the first 4 months!

Once we made that decision, I needed to figure out which media center to get. Once upon a time, I had built us a home-brew Windows Media Center 2005 box http://en.wikipedia.org/wiki/Windows_Media_Center). My wife absolutely hated the thing. It was big, noisy, confusing and it had a nasty habit of developing problems that she couldn't fix by herself. It stung to let go of my little pet project, but I had to admit that she was right, so I disconnected the old machine and started looking at new options. After a copious amount of geeking out over features, price and flexibility, I narrowed our choices to the list below. Note that this is not intended to an exhaustive list as there are many other options available (Boxee, MythTV, etc). This is just our the list of finalists.

Device	Ease of Use	Netflix Support	Hulu Support	Price	DVDs	Games	Notes
Windows 7 Media Center (+ new low profile hardware)	Poor	Yes	Yes (w/ IE)	$500+	Yes	Yes
AppleTV 2	Excellent	Yes	No	$100	No	No	Good integration w/ iPhone and iPad, iTunes content
Roku XD\|S	Good	Yes	Yes	$100	No	No
XBMC or Boxee (+ new low profile hardware)	Poor (Same problems as Windows MCE)	Yes	Maybe?	$500+	Yes	Yes
Google TV (Logitech Revue)	Excellent	Yes	No	$300	No	No

After some soul searching, we decided that price and ease of use were the most important aspects, so we decided on AppleTV. It also had the advantage of being simple to use with the iPhones (My wife and I each have one) and iPad.

Normally, I'm not an Apple fan boy. I think they're a little too proprietary with their software. I have to admit, though, after a few months of messing with the AppleTV 2, I'm impressed. The device is ridiculously easy to use (no more cursing from the wife :) ) and it just works. My Windows Media Center was constantly requiring maintenance and tweaking. After spending the few minutes to set it up, the AppleTV has worked perfectly. The quality of the video is great considering it's streamed and we've had little or no connection issues. The remote app on the iPhone is pretty well done as well and makes it a thousand times easier to type something when you're searching for a movie. The on-screen keyboard is ok, but can be really painful if you're typing something long-ish. Oh, and did I mention that it's *tiny*. It's not much bigger than a hockey puck, which makes the real estate near the TV a little less cluttered.

That being said, there are a few things that are frustrating. The prices for iTunes movies is a bit higher than I'd prefer. I know it's the going market rate for digital rentals (about $5 per HD movie), but given that I can watch unlimited Netflix on the same device for $10/month, it seems a bit high. The lack of a DVD player, while understandable given the nature and price of the device, means we have to keep a separate DVD player around for Netflix-by-mail movies. It would have been nice to collapse everything into one device. The amount of content could be improved as well. An App store could make it possible to get things like Pandora or games on to the TV pretty easily. Rumor has it Apple is planning an App Store for the AppleTV, but there's been no confirmation yet from Apple.

All in all, it's been a very good experience, especially for the price, and I'd buy it again given the choice. Next project: Jailbreak the AppleTV and install XBMC to see if I can squeak every ounce of functionality out of our new toy :).

The Importance of an Iteration Demo

2010-10-16T22:32:00.000-04:00

When I first started using Agile, I really didn't make a big deal over demos. We did them once in a while, but if we skipped one here and there, no big deal, right? The product managers and business folks will come around at some point and we'll show it to them then, right? The classic purpose of an iteration demo is to gather feedback from your stakeholders. What I didn't take into account were the benefits of doing demos that had nothing to do with feedback.

A few years ago, I started a new project at work. One of my first orders of business was instituting an iteration "rhythm". The subject of demos came up and I was initially pretty unenthusiastic about it. I was alright with scheduling them but if we missed them that was fine too; we'd get the product manager to come down later. I had a colleague who was adamant that we have a fixed scheduled demo and and after some spirited but half-hearted resistance, I acquiesced. After the first 3 or 4 sessions, the affect on the team became obvious and I have completely changed my mind about the importance of a demo.

1) A Demo is a Deadline.
The first thing I noticed was that because the demo was scheduled in advance and was difficult to move, it served as a kind of unofficial deadline for the team. In previous iterations, the work always seemed to"bleed" over into the evening on the last day, or maybe even a little into the weekend or the next iteration. We always finished, but the end of the iteration was never really crisp. The iteration demo provided a specific time when everything needed to be done, working and ready to show to the team. While this created a little bit of panicked last minute work the first few times, over the next iterations it forced us to be a lot more disciplined and we started thinking very carefully about when things needed to be done before the demo.

2) A Demo is a Motivator.
Feedback is an important tool for improving software, but it is also an incredible morale builder. For most programmers, there's no greater compliment than hearing that someone really appreciates the software they've built. Of course, if you have somebody who's habitually trashes everything you do, this could blow up in your face, but as long as the good aspects of the software are acknowledged and the criticism is constructive, I guarantee you your developers will walk a little taller for the next few hours.

3) A Demo is a Test.
Software always has a tendency to fail in catastrophic ways right before a demo. It's easy to chalk this up to Murphy's law but demos by their very nature exercise the software as a user would, and often result in a more comprehensive test than you would create otherwise. In all likelihood you are uncovering bugs that would eventually show up in production. While this may make for a few uncomfortably bad demos, better to find out now than after you've shipped. Obviously, this information can be used to improve testing in future iterations which is always a good thing.

4) A Demo is an Education.
Just clicking through the software and showing that all the buttons and tabs work is one thing, but showing your customer that you understand how they need to use the system creates a whole new level of discussion. One of the rules in all our demos is that they must be scripted (well, at least loosely anyway) and that they must demonstrate how our customers will actually use the system. If you're building accounting software, then pretend you're an accountant attempting to create a quarterly report for his company. If you build music recording software, then record a simple song to demonstrate how the software would really be used in the field. Of course, this might require some research, but your team will better understand the needs of the customer as a result. In my experience, a better understanding leads to better software.

A good demo is more than showing your boss that you're actually doing something at work. If you catch yourself skipping iteration demos more than you should, it might be time to rethink their purpose. If done well, a demo can be a powerful tool to improve your product and motivate your team.

Find Dead Files

2010-07-11T13:37:00.005-04:00

Image: Simon Howden / FreeDigitalPhotos.net

I've been doing a lot of web development recently for a friend's website. One of the problems I always seem to have is cleaning up files that are no longer used as the site evolves. This is particularly true with images. I solved this problem by writing a simple Python script to do the following:

1) Produce a list of files in the current directory and all subdirectories (minus a few file types that are ignored)
2) Search all the files in the current directory for references to those files
3) Output a list of files that do not appear to be referenced

Here's some sample output:

Creating list of files...

Searching files...

The following files are not referenced from files in this directory:

images/oldcontactus.jpg
images/header.jpg
images/photos.jpg
index2.html

Every week or so I run the script and clean out any lingering dead files. In the hopes that it might be useful to others, I have uploaded it to the blog. There are couple things to keep in mind if you intend to use it:

1) The search is not intelligent so it will recognize any text that references the file (including comments and the occasional lucky substring).
2) It only searches the content of files in the current rectory, which assumes that your HTML is in the current directory and images, .js files, etc are in subdirectories.
3) If you need to modify the file types that are ignored, edit the .py file and change the constants at the top.

Download the script here.

I've included a listing of the source code below. As always, feedback and constructive criticism is always welcome. I'm always looking for ways to improve my code. Enjoy.


#########################################################################
# find_dead_files (version 0.1) by Andrew Burke
#
# This utility builds a list of files in the current directory and all
# subdirectories. It then searches the files in the current directory
# for references to these files.
# If a file is identified that has no references to it, it
# is reported. The algorithms used is not and intelligent
# search so comments and raw text WILL match.
#
# This script is intended to help identify files that are no longer use
# in a website.
#
# Usage: Place the .py file in the root of the directory structure you'd
# like to analyze and execute the script. To change the file types that are
# ignored altogether or not searched, please modify the "Constants" section
# below.
#
# IMPORTANT NOTE: Files that are referenced from external sources only,
# WILL be reported this tool as being unreferences. Please use care
# before permanently deleting any files.
#
# Copyright (C) 2010 Andrew Burke
# This work is licensed under a Creative Commons GNU General Public License
# http://creativecommons.org/licenses/GPL/2.0/
#
# Revision history:
# v0.1 - First version (Andrew Burke)
# v0.2 - Corrections from PyChecker

import os

# Constants
NON_SEARCHABLE_FILES = ".jpg,.png,.gif" #Files that should not be searched for keywords
IGNORABLE_FILES = ".svn,.py,.bat" #Files that should not referenced anyway
FOLDER = "." #Folder to start from (default is current directory)

def does_string_contain_keywords(in_str, cur_keywords):
 # Search the given string for any of the given keywords

 for search_term in cur_keywords.split(","):
     if in_str.find(search_term) > -1:
         return True

 # If we get this far, none of the keywords were found
 return False

def is_ignored_file(search_filename):
 # Should we ignore this file altogether?
 return does_string_contain_keywords(search_filename, IGNORABLE_FILES)

def is_not_searchable_file(search_filename):
 # Is this a file we can search?
 return does_string_contain_keywords(search_filename, NON_SEARCHABLE_FILES)

def concat_with_slash(str1, str2):
 # Put two files/directories together
 if str1 == "":
     return str2
 elif str2 == "":
     return str1
 elif str1 == "" and str2 == "":
     return ""
 else:
     return str1 + "/" + str2 

def add_files_to_list(subdir, root_path, mylist, search_subdir):
 # Recurse the folder structure and build a list of files
 # mylist is modified as a pass-by-ref parameter

 cur_path = concat_with_slash(root_path, subdir)

 for cur_filename in os.listdir (cur_path):
     if is_ignored_file(cur_filename):
         continue

     if os.path.isdir (concat_with_slash(cur_path, cur_filename)) and search_subdir:
         new_subdir = concat_with_slash(subdir, cur_filename)
         add_files_to_list(new_subdir, root_path, mylist, True)

     mylist.append(concat_with_slash(subdir, cur_filename))

def search_file_for_keywords(cur_path, search_filename, cur_keywords):
 # Search the specified file for keywords and remove the keyword if found
 # cur_keywords is modified as a pass-by-ref parameter

 if is_not_searchable_file(search_filename):
     return

 if os.path.isdir (concat_with_slash(cur_path, search_filename)):
     return

 try:
     cur_file = open(search_filename, "r")
 except:
     print ("ERROR: Cannot open file: " + search_filename)
     return

 line = cur_file.read()
 keyword_iterator = list(cur_keywords)
 for cur_keyword in keyword_iterator:
     if line.find(cur_keyword) > -1:
         cur_keywords.remove(cur_keyword)

# Main script
filelist = []
keywords = []

print ("Creating list of files...")
add_files_to_list("", FOLDER, keywords, True)
add_files_to_list("", FOLDER, filelist, False)

print ("\nSearching files...")

#search each file for the filenames
for filename in filelist:
 search_file_for_keywords(FOLDER, filename, keywords)

# Print out the list of files that are not referenced
print ("\nThe following files are not referenced from files in this directory:\n")
for keyword in keywords:
 print (keyword)

The Joy of Static Websites

2010-07-05T09:32:00.001-04:00

So, you've got a little website you're working on as a side project. The requirements are pretty simple but there are a few pieces, maybe internationalization, feedback forms or even a shopping cart that sound like they're going to need some server-side programming. Being the geek-ified programmer that you are, you start evaluating what tools and bits of knowledge you can bring to bear on this problem. What should the database look like? Should I use ASP.NET or something like Python or PHP for the dynamic parts?

It is easy to start building a monster this way. If you think about it, most of the features above can be built with simple programs, javascript and a completely STATIC website. No dynamic content, no server side scripting at all (well, at least not for you).

"So what?", you ask. Well, static websites have several advantages over dynamic ones:

1) They are SIMPLE. Static websites are easy to build and debug. There's really not a ton of tricky things that can happen when the page you store on the server is exactly the same as the one that gets rendered in the browser.

2) They are FAST. Static web pages can be cached by browsers and web proxies. This improves performance for the end user and reduces the load on the web server.

3) They have no STATE. If you want to update the site, you don't need to migrate the database. If you want to back it up, just keep a copy of the html. If you're site gets big, scaling it up is just a matter of a load balancer and some more servers.

4) They are generally CHEAPER. Many hosting providers charge more for dynamic content and databases. A static site needs neither of these. Of course, you might be uploading more static content to the server, so disk space could become a consideration.

Of course, none of this helps you solve the issues mentioned above. You still need that feedback, internationalization and shopping cart. A lot of that can be provided without resorting to server-side programming.

Feedback: There's an amazing variety of stuff that can be built just using cloud service these days. Uservoice.com for example, is a great solution for adding user feedback to your site using a little block of HTML and some javascript. Theirb smallest offering is free and is still pretty customizable. If you're fussy about the URLs looking like they're all from the same site, you can opt for their paid version and they will allow a DNS CName record to point your users to your uservoice site.

Internationalization: If you're building an e-tail site these days, it's tough to ignore the international market. You could build some crazy database-driven resource lookup solution, or, you can simply generate the site on your local computer and upload the files to the web server with no dynamic content at all. That might sound a bit confusing at first, so let's take a step back and go through an example.

You're getting ready to start selling your gourmet jelly beans overseas. In fact, you've discovered that there's a HUGE market in France for jelly beans, so you decide to translate your site into French to better target this market. You could just make an /fr directory on your web server, copy the website into it and change all the English to French (assuming of course you speak French, which as another issue entirely). The problem is if you decide to alter the HTML of the main English site, you're going to have to copy the changes over to your French site as well. If you have a dozen different languages, this gets hairy pretty fast. Instead, consider building the site with some unique strings in place of your descriptions. Maybe something like JELLYBEAN_DESCRIPTION_SOURAPPLE. Then write a script in the programming language of your choice to copy the site into the /fr directory and replace the dummy string with the real content in French (or English, or Italian, etc). Once you're ready, run your script, build the site and upload the whole thing. Of course, you will still need to check and make sure the text looks ok and doesn't get cut off anywhere, but you need to do that if you're building a dynamic site too.

Shopping Cart: Shopping carts are a really common reason to add back-end scripting to a site, but there are tools that will allow you to put this in the cloud as well. Paypal has a nice little forms-based API that will allow you to host an entire shopping cart with them. You can even brand the shopping cart page so that it matches your site's look. You won't get the kind of flexibility you would get from a customized cart, but it's quick, easy and pretty inexpensive. (Disclaimer: Apologies to those of my friends out there with a really deep-seated hatred of Paypal. They were just the easiest example.)

It doesn't solve every problem, but you can do more with a static site these days than most people would think. They can be a lot easier, faster and cheaper than a dynamic site and can save you boatloads of work and headaches. It's at least worth strong consideration before diving into a pile of database and server-side coding.

Working with Distributed Teams - Maintain Relationships

2010-05-29T15:25:00.002-04:00

One of the most difficult aspects of working with distributed teams is maintaining the personal connections that come naturally when you are working with your team in person five days a week. Despite what we're told to believe by many human resource "experts", you must build and maintain a personal connection with your direct reports if you want your team to be effective. Think about the connections you've had with your bosses in the past. Most people are far more willing to go that extra mile for their boss if they know that their boss is listening to them and looking out for their best interests.

It's easy to fall into the trap of assuming that this sort of connection is impossible over long distances, but the truth is that we do this sort of thing all the time in our personal lives. It is not at all uncommon to have family or friends that live in other states or even countries and yet we manage to maintain a personal relationship with them. You may not live in the same state as aunt Jean, but you can still call every so often and fly in for a visit now and then. Unsurprisingly, the tools at your disposal are not all that different from what you would do with friends and family, albeit a bit more structured and formal.

The most obvious tool is travel. While it's not impossible to keep close contact with your staff without travel, it's significantly more difficult. This is especially true at the beginning of a project when there is more need for communication to set up methods of work and decide on the scope of the project. Getting everybody on the same page early and giving everybody a much needed relationship boost early in the project will set the stage for a much more organized and clean running project in the future. The same is true of your family relationships. After all, the phone calls after your visit to aunt Jean just seem so much more natural and easy, right?

For those of you that follow the managers tools podcast, the second tool won't come as much of a shocker. One-on-ones are the key to keeping regular personal contact with your remote reports. They can and should be done at least once a week over the phone, and can be done in much the same way they are done in person ( Click here for the Manager Tools podcast on one on one's ). You still need to cover work related areas, but consider leaving some extra time to discuss more personal matters such as family, weekend events, vacation plans or just whatever comes naturally. This is particularly important since you will be missing the regular "water cooler" types of informal conversations that happen naturally when you are co-located.

The last that I want to address in this post is assignments. Nothing improves your staff members' relationships and understanding of remote sites as much as going there for a while. Ideally a small percentage of each of your teams should be on a remote assignment at any given time. Unfortunately this is often the most difficult tool to justify in budget conscious organizations. However, if you can manage it, your team members will have developed relationships and knowledge that will help them immensely. They will know who to contact when they have a problem. They will know how the team process works at the remote site and the challenges they face on a daily basis. All of this information makes them more effective themselves and also helps to make them ambassadors for others in the organization, helping to overcome the "us and them" mentality that so often plagues distributed teams.

Maintaining relationships with remote teams can be difficult, but it's not impossible given the right time and energy. The steps mentioned above are just a few of the many options available for keeping those connections with your remote teams tight and effective.

Working with Distributed Teams - Effective Communication

2010-03-17T21:18:00.003-04:00

If you work with a distributed team today, then you're already painfully aware of how critical time is when communicating. Issues that could be resolved locally with a simple five minute conversation can take days with a remote team to say nothing of the time lost when one group is plowing ahead with incorrect assumptions about what the other team is doing. This is further exacerbated if one of the remote teams is in a distant time zone and there's a limited amount of time in which the corresponding work days overlap. If you're based in the US and you have a team in Asia or vice-versa, then there may only be a few hours a day where you can actually talk to your team. Establishing a regular rhythm of communication is critical. It may be difficult or impossible to talk to your team extensively during the day, so a process by which you communicate and expect information can help immeasurably. The most basic tools have worked for me are status reports both to and from your remote teams and regular staff meetings.

Daily status reports, although most people roll their eyes when they hear that phrase, can be a great tool for keeping you up to speed on the days events. This report, however, does not and *should not* be a 10 page detailed report on the days activities. Often a simple email with the highlight reel from the day is sufficient to alert you to something that might need attention. For example, you might get a status report from your onsite manager at the end of the day that looks something like this:

- Started integration testing between system A and B
- Coding blocked on component C due to a bug in third party libraries
- Bob and Sam off on training till Thursday

If you're working on something that requires more structured information (perhaps performance testing or deployment) then a 1-page spreadsheet copied and pasted into email usually does the trick. My general rule of thumb is that it should take no more than 10 minutes to fill out the report and send it off. The last thing you want to hear is that your team is behind on deliverables because they spent half the day putting together a status report for you. The goal is not to communicate every detail of what's going on at the remote site, it's to provide a little communication boost between you and your team until you can talk next.

Getting information *from* your remote teams is important, but it's really easy to lose sight of what it's like for them. Chances are, they are feeling disconnected from the decision making process and out of touch with new direction and changes. A regular staff meeting can help you to communicate this sort of information, but your team could be out of sync for several days or weeks depending on how often you hold them. A simple status email (in the same form listed above) sent to your remote team from you can go miles towards helping them feel connected, informed and on track. Some people balk a little at this idea. Perhaps because many people think of status reports as something that is sent from a subordinate to a manager. At the end of the day, a status report is a communication mechanism and nothing more. If it helps get the best our of your teams, then how can it hurt?

Status reports are good, but, there's no substitute for regular staff meetings over the phone. It may be tempting at first to rely on email to communicate, but email is just too slow to support the kind of in-depth conversations that are necessary to develop software. If you share a time overlap with your remote teams, then it helps to block out the overlapped hours in your calendar. You have a limited amount of time to communicate with them and you don't want those time slots chewed up by meetings that could happen at any other point during the day. If you don't share an overlap, then chances are one or both teams are working night hours at least once a week. Either way, detailed meeting agendas are critical to keeping that limited communication effective. Manager tools has a great podcast on effective meetings that I highly recommend (click here and scroll down for the 3 part series on effective meetings). Setting up a good agenda and timeline are not rocket science, but it does take a bit of discipline and practice and the manager's tools model provides a really clear place to get started. One of their suggestions is to ask for meeting topics ahead of time. Google Wave or a Wiki are great tools that can be used to gather agenda items when you have limited face to face interaction and can help offload the gathering and formatting to the team.

The problem with remote teams is almost always communication, so it shouldn't be a surprise that all of the points above are about squeezing the most effective communication possible out of the time you have. These are the tools that I've found useful, but there are many more techniques for managing relationships over a distance. I'm sure there are tons of other ideas out there and look forward to hearing about them.

Today's post in GREEN in honor of St. Patty's Day :). Enjoy the holiday!

Working with Distributed Teams - Use Good Tools

2010-02-25T19:11:00.015-05:00

I think it's fair to say that being a manager with responsibility for remote teams is very common today. Advances in technology have made this possible, but not necessarily easy. Communication, cultural barriers, time differences and the sheer impact of being physically remote introduce a host of potential pitfalls. If you're lucky, your company allows you to travel and see your team in person frequently, but travel is often the first thing to go when budgets get tight. Unfortunately, I don't think there are any magic solutions to this problem, but there are some things I've found that make it a bit easier. In this entry, we'll be talking about tools that help improve communication, but this is only the beginning of the story. There is much, MUCH more to this, involving behavior and organization, that we'll get into later.

The first thing that pops into most people's minds when you think of communicating with remote teams is heavy use of email. While this is certainly true, email is an ancient tool (in technology terms at least) and there are some great new products out there, many of which are free, that can help overcome these barriers. Google Wave is a great way of managing communications. Although it's still in development (as of this writing), it's relatively easy to request access and doubles as a simple collaborative document system as well. I've found it particularly effective for managing meeting minutes and agendas (see image above). Attendees can suggest agenda items and can take notes collaboratively in the same space. Actions can be tracked and updated as part of the same wave. Alternately, Wikis can be used if you just need a collaborative document solution. They are great for sharing documents that the team needs to maintain such as process documentation, test plans and requirements documents.

Collaborative Web based meeting tools like Webex can be the difference between a long confusing meeting and a simple one. This is especially true if there's a language barrier involved. Having a document open that everybody can look at can help avert those endless "Sorry, can you repeat that?" conversations. They're also great for demos or for use as a screen sharing tool when trouble shooting problems together. When there's a time barrier involved, making the most of the meetings you have is absolutely critical and anything that makes the conversation quicker and easier is welcome.

Instant Messaging is a great tool when there's some time overlap. There is a different feel for instant messaging than email. It's generally more casual and more interactive than email. Some might say that this is an unnecessary addition and that email covers this need, but I can tell you that it absolutely does not. People are much quicker to type an IM than an email and a couple of simple messages back and forth can save you days in the right situation.

Several of the tools mentioned above support webcams as well. While it might seem unnecessary, visual communication on top of audio goes a long way to improving communication (especially across language barriers) and helps to reinforce relationships with your team. Webcams are cheap these days and with tools like Skype, there's really no reason everybody can't use some level of video conferencing.

Centralized development tools are really critical for a distributed development team. A single source code control system(especially if you're sharing code across sites) and a web based bug and task management system can save you and your team piles of work. I've been using Altassian JIRA and Subversion recently, but there are literally dozens of alternatives out there. If your company can't host these tools for you, there are lots of companies that will. If you're working with a virtual team of home-based engineers, then you might also want to check out a distributed source code control system like GIT.

Social Networking sites get a bad rap in most corporate circles, but they fill a very basic need. If you have a distributed team, your personal relationship with them will be strained. The lunch conversations, water cooler conversations and the discussion on your way out to the parking lot all help to solidify your relationship with a local team, but unless you travel often, you won't have this kind of rapport with your remote team. Sites like Facebook help keep you in touch on a more personal level. Keep in mind that this can be a tricky thing. Insisting on "friending" a direct report is generally a bad idea. If they are interested in sharing their personal lives with you, they will respond to a request, but forcing the issue will generally have exactly the wrong effect. You will also need to be careful what you post. A complaint about your job might be ok with your friends and family, but taken out of context with your staff can lead to bad assumptions about what's going on in the company.

While email can be an absolute nightmare to manage for some of us, effective use of email is still a great tool. Regular status updates both from staff to you and *you to your staff* are great ways to keep everybody in sync. Be careful of relying on email too much though. It can also lead to an enormous waste of time if used when you need a timely response.

The PHONE. Yes, I know, it's positively primitive, but it's also extraordinarily effective. Hearing your voice is the next best thing to seeing your face and there is simply no substitute for it. With tools like Skype there is virtually no cost associated with a phone call and regular verbal communication is critical.

This list is not exhaustive, but I think it covers the highlights for what I use today. I'm sure there are lots of opinions out there on what tools are effective and what tools are a waste of time, so let's hear what you're using.

Podcasts

2010-02-15T18:38:00.004-05:00

Over the last few years, I have become more and more enamored with podcasts. They are a great way to keep up with the industry and you can listen to them while your driving, walking or generally doing things that make holding a book, well, dangerous. There's still no substitute for hands-on learning or a good book, but with the dizzying array of technologies, processes and techniques available out there, podcasts provide a nice overview and can help keep you abreast of all the new stuff.

There is a stunningly good amount of content available for free if you know where to look for it. Topics range wildly, but if you're a software engineer or manager, there are a few (in my opinion) that clearly stand out from the rest.

Technical Podasts

Software Engineering Radio - Really good for more detailed technical topics. Topics vary but include specific technologies, design patterns, architecture, process and all things software engineering. There tends to be a bit more open source stuff here, but all technologies are represented.

HanselMinutes - A software engineering podcast by blogger Scott Hanselman. Scott's show tends a bit towards .NET based solutions but not exclusively. Topics vary widely and Scott is an excellent speaker and interviewer. Highly recommended.

.NET Rocks - A technical podcast focused (obviously) on .NET technologies. I haven't listened many of the audio podcasts, but they do have a vidcast called dnrtv that is great for showing in groups with your teams. Topics are largely focused on .NET and .NET based technologies.

Management Podcasts

Manager Tools - I've been listening to Manager Tools only recently but so far, I've been very impressed with their cast. The focus is on more general management techniques, not software, but almost all of their topics apply. There is a very heavy focus on "what to do" rather than theory. Their approach is clear, well thought out and practical.

Lean-Agile Straight Talk - A podcast specifically focused on lean engineering processes as well as agile development practices. Worthwhile if you have an interest in these subjects.

A little of Everything

Stack Overflow Podcast - The stack overflow podcast is more of an open ended software development discussion with bloggers Joel Spolsky and Jeff Atwood. The conversations range all over the place, but are always interesting and entertaining.

Typically, I listen to an hour of podcasts a day, usually on the train to work or when walking to and from the station. I'm always on the lookout for good podcasts on technical and management topics, so if anybody out there has some favorites, please feel free to post them here.

Why Free Range Software?

2010-02-06T01:09:00.002-05:00

Okay, I know, it's a weird title. It evokes images of large two-dimensional desktop applications grazing on mid-western fields... or at least it does for me. So, what do we mean by Free Range?

From Wikipedia:
"Free range is a term which (...) denotes a method of farming husbandry where the animals are allowed to roam freely instead of being contained in any manner "

In a way, that reflects my view of how software should be developed. Software development is a hugely complex activity. Often, we're dealing with customers who are not sure what they want and new technologies that we don't completely understand. It is (sort of) possible to plan out every last detail of such a development project. Unfortunately, the result is often failure in the form of budget overruns, burned-out teams or software that does not meet the needs of the customer. Software development is part research and part engineering and to really create the best possible products, the software must be allowed to evolve or "roam freely" during the course of the project.

For those of you that are familiar with agile software development practices, you are probably already smelling a little bias towards those techniques. You'd be right. However, as much as I believe in the effectiveness of those techniques, they are not without their flaws and there is much to be learned from the traditional waterfall development practices that created the overwhelming majority of the software that we all use today.

That, in a nutshell, is what I mean by "Free Range Software": Development projects work best when they are free to evolve (roam?) within a set of guidelines (fences?) that govern the overall goals of the project. If my analogy is a bit rough, well, let's just say good domain names are hard to come by.

Hello World!

2010-02-02T13:33:00.002-05:00

My name is Andrew Burke and I've been working in software as an engineer and manager for the last 16 years. Like many people in this industry, I got my start very early on and what started as a kid's hobby became a career (and an adult's hobby for that matter). I still remember the early days of typing hundreds of lines of BASIC code out of books into my very first computer, an Atari 800XL, complete with a *whopping* 8K of RAM. While the tools and technologies have changed radically since then, it's amazing how many of the lessons I learned then still apply today.

I spent many years working as a developer, and then about five years ago I was given an opportunity to manage the team. It was a great opportunity (and a pretty decent raise), but I'd be lying if I said I was initially excited about the idea. The industry was full of horrible stories of ineffectual managers who worked their teams to the bone. It was a running joke that such a promotion was actually a "management lobotomy" and that no self-respecting developer would even consider such a position.

Ultimately, I took the job. At the time, I'm not sure I knew exactly why. I was earning a living doing what I loved and a shift to management was a very different (and potentially boring) job. I think the real motivation was the desire for a new challenge and a chance to see if it *could* be done better. I've learned a great deal since and made my fair share of mistakes along the way. Now, I can't imagine doing anything else. My work encompasses all the things I love about people, technology and people who love technology.This blog is intended to be a place to share my experiences and thoughts and for us all to discuss our views on software engineering and management. With any luck, we'll all be better managers for it.