Rock Star Programmers - 5 Traits I See As Winners

In my heart, I’ll always consider myself a professional software developer.  I began writing code at the ripe old age of 12.  While I don’t write code on a daily basis anymore – the sin of being ‘management’ – I still write code at night to keep my skills fresh and to ensure that I can sit in a room with my development team and understand the conversation and hopefully add value.  While at one time, I considered myself an expert in the languages I used (don’t ask, they are all now ancient).  I realize now that I can still write good code – but because I don’t do it day in day out, I don’t kid myself in thinking that I’m the whiz kid anymore.  I’m not.  I’ve got team members that are extremely talented and I’ll give them praise any chance I get.

So what makes a great developer?

Over the years I’ve watched a lot of developers come and go in the shops where I’ve worked.  Some of these folks couldn’t code if their life depended on it and didn’t last long.  Others made it look effortless – producing code that was simple, easy to read and just seemed to work.  So what made these developers different, what did they do different than everyone else?

Patience

Some programmers get their assignment and without asking any questions start pounding out the code.  They’ll quickly listen to what is needed or skim the requirements and get to work.  They’re dismissive of further explanation, and are quick to say that they know what the users want better than the users of the system.

The best programmers take their time.  They actually read thru both the requirements documentation and the technical designs if they exist, or they’ll spend time interviewing the user to understand what the true problem is and what issue is being solved.  They are not only concerned about what it is that is wanted, but they take time to understand what isn’t wanted or needed in the solution.  These developers think not only about the specific assignment but want to understand how it fits into the whole puzzle.  Are there parts of the system that operate ahead of their piece – what do those parts of the system do to the data before it gets into the code that they are writing?  Are there parts of the system that will need the output of the code that they are writing?  How do they ensure that the data is validated before it leaves their code and is handed off to code written by another team member?

Lifelong Learner

Coasters – they drive me nuts!  These are the folks that think they know everything and that they are better than everyone else on the team.  They scoff at junior developers and will tell them that there is nothing that they can learn from such a junior team member.  The Coasters are forgetting that anyone can be a teacher.

On the other hand, I love lifelong learners.  These are the developers that are constantly pushing themselves to learn new technology, understand how to use the language they are developing in more efficiently.  They are constantly reviewing everyone’s code and are not afraid to take a chunk of code, walk over to the person that wrote it and ask them to walk them thru the code so that they understand what is happening.  They aren’t afraid when someone critiques their code and in fact actively pass their code around to others on the team to be examined.  When you run into them in the breakroom or walking thru the office, they will begin telling you about the new scripting language they are playing with or some new solution/tool/framework that might make the team more efficient.  Give these folks room to play – they will make your team better and find unique solutions to some of the toughest problems you have.

Commitment to Excellence

We know these folks – the developers that quickly write their code and then throw it over the wall for someone else to test.  They’re not concerned about what happens downstream – heck, they’re not even concerned about what happens within the code they just wrote.  They spend more time fixing their code than they spent quickly writing the code – in this instance, speed does not win the race.

Flip that around now.  The best programmers take their code personally!  They view their code as a direct reflection on themselves.  The best programmers will actually create their battle plan prior to writing any code – understanding exactly how they will test what is being created or modified to ensure that it works within the complete workflow.  Reviewing all of the incoming data, understanding what they should and shouldn’t expect.  Reviewing all of the output and integration points and understanding how the data can be manipulated and what are false values or boundaries of the data.  They will write small chunks of code or use scripts to test the code they are creating/modifying.  They are not only implementing unit testing, but are thinking through integration and regression testing along the way and then executing prior to handing off the code.

Passion

Look, if you don’t like your job – find something else to do.  We know these folks, they slouch in, plop down, ignore their fellow team members, don’t offer to help others, won’t bring new ideas to the table, won’t participate in meetings – team or otherwise and won’t do anything but exactly what they're told.  Are you kidding me!

Now, show me someone who is passionate about what it is they do!  Yeah, that’s the ticket!  I love these folks – they live and breathe to be the best coders out there!  They’ll call themselves a geek – and view it as a sign of honor!  They aren’t afraid to tackle the most complex parts of a project.  They find a way to practice their skillset – just like the best musicians.  If they’re given a particularly difficult task, they’ll try 2 or 3 different solutions to find the one that works best.  They are disappointed in themselves when they miss a deadline or someone finds a bug in their code – but they are the first to step up and take critique.  They view critique as a lesson along the way, will actually listen to it and attempt to learn from that criticism.  They will throw themselves at new technology when asked – and in a lot of instances without being asked – so that they can become more efficient.  You’re hired!

Self Sufficient

There are days I’ve pulled my hair out because someone will tell me that they hit a wall and couldn’t get any further.  When I ask them what the issue is, they tell me they’re waiting on answers to clarify some problem in the code or with the requirements/design.  When I ask them what they’ve done to solve the problem, I get a blank stare after they tell me they sent an email out 2 days ago.  Really, you couldn’t find it in yourself to stand up, walk to the other side of the building and get an answer?  Ugh – do I really look like I want to play baby sitter!

Now the best programmers are bull dogs!  They hit an issue and they are tracking down the best way to get the answer.  Sometimes that is tracking down someone internally, sometimes that is looking on the net to find a solution to a particular programming problem, and sometimes that is asking a team mate sitting a few seats away.  They are not afraid to ask questions and understand that communication can be used to solve issues!  If the issue is big enough, they don’t hesitate to escalate the issue – but usually have a couple of different options to resolve the problem.

Wrap Up

These have not been presented in any particular order, but they do represent the traits that I see in the best developers.  They are traits I attempted to show when my main role was to sling code every day and that I hope I still possess in the role that I currently play.

What are the traits that you see within the best developers you have on your team?  Let’s keep the conversation going!
 

If you'd like more information on my background: LinkedIn Profile

Don’t Be Afraid … Change!

Over the last several years, my teams have made significant changes to our project management, development, testing and implementation processes and paradigms. We’ve had some bumps along the way and in no way do I consider this evolution over. I will continue to challenge my team members to find a better way to build the mouse trap that drives our software development lifecycle.

Let’s look at some of the successes the teams have had introducing change into the organization:

1. Our project management process used to be split into separate and distinct teams: 1) project management for business and operational teams; 2) project management for technology teams. This has been consolidated into one project management team managing all project related activity across the organization. This has streamlined activity and improved communication across all teams involved in the process.
2. Our lifecycle was revamped as we consolidated the project management organization. During the revamp – we created RACI documentation that clearly outlined 1 owner for each key task/milestone within the overall project activity, along with those that would act in the roles of responsible, consultative and informed parties. This has provided clarity to who owns each activity and what the key tasks are that are included within every project.
3. Recently we made additional changes to the lifecycle – completely eliminating 1 phase and adjusting the tasks and milestones associated with both our scoping and design phases. This has allowed us to streamline the process and give clarity to when project activity actually starts within the organization.
4. We have challenged all of our team members to review the overall standard tasks/milestones within any given project, and challenge the project manager and sponsor to eliminate tasks and standard artifacts when it is justified and where there is minimal risk associated with utilizing an altered process.  This decision then is documented as part of the project and communicated to the team to ensure that down the road, people can review the effort and understand why certain documents or tasks might not have been done. This should allow us to be more nimble and find the best path for each project to take thru the organization.
5. A couple of years ago, it took up to 3 weeks to complete regression testing associated with key functionality within our application silos. This was a manual effort that typically was handled by multiple individuals. The teams have worked hard to automate the regression tests associated with these applications. Today, the execution of these tests can be done in less than 17 hrs. The labor savings moving forward will more than pay for this effort. This also allows us to provide quicker feedback to the development teams and ensures that our regression testing is more consistent across all projects.
6. Recently, the teams also completed the resurrection of standardized test data to be used across our test and development environments. This will be further enhanced as our automated tests are enhanced to create/modify/cleanse and reset data needed for a given test. This will reduce the time spent creating test data for each project and will ensure downstream processes/applications have the data that is needed to execute their regression tests.
7. Over the last several years, our implementation plans have seen significant improvement. Our business demands that our systems be available 24x7x365. When you want to buy a tank of gas at 3AM or 3PM, you want the transaction to go through so that you can continue on your way. You would not find it acceptable for us to deny the transaction because we are updating our systems.  Our implementation processes have been templated and include all implementation activity, across all application and infrastructure silos, commands, scripts, validation and fallback steps in the order they will be executed.  Recently, our external auditors informed me that our implementation plans are among the best that they have ever reviewed. This has hardened our implementation activity – reducing the overall time needed to implement changes into our production environment, standardizing the validation activity during and after implementation activity has occurred and most importantly having fallback steps at the ready when any validation activity shows that there may be an issue.
8. Our development teams have changed their processes to include code reviews of all changes prior to those changes being introduced into our production environment. This is hardening our code base and reducing the risk of making changes within our production environment.
9. Our development teams have changed their processes to ensure that unit tests are created for all code being touched within a project.  These unit tests are then kept in a repository and used in future projects. This, again, has hardened our applications and reduced the overall number of bugs slipping through the process into our quality assurance testing or into our production environment.
10. Our development teams are now doing nightly builds – with reports going back to each team on build failures, unit test execution failures, code coverage and other statistics. This is giving immediate feedback to our development team and ensures that issues are addressed within 24 hours.

These are just some of the changes that have been implemented by the teams over the last several years. And we’re not done! Moving forward, we will move the regression testing into our nightly build process. We will be evaluating further changes to our development lifecycle to reduce the amount of time between idea generation and product introduction into our production environment. We will continue to improve upon our implantation planning. We will introduce key metrics across the development lifecycle. And where it makes sense, we will introduce Agile techniques into the development process.

I talk to college and high school students on a regular basis to discuss what it means to be in the technology field (specifically software development). The one constant that I tell students is that being in this field means you will constantly have to learn. They will learn new languages, they will drive change into the organization, they will experience multiple different development paradigms. All of this is good – it means the organization is alive, is learning and is adapting to its competition. 

Don’t settle for how it works today or with someone telling you, “well, that’s the way we’ve done it for decades!” Your job, no matter what role you play in the organization, is to find a better way, review your suggestion with those that can help implement, trial those changes and then roll them out across the team and the organization. Change is good – don’t settle for the status quo! 

If you'd like more information on my background: LinkedIn Profile

Don’t Hide Behind the Process

Well, it’s been a while since I’ve discussed process issues.  Time to dig in and have some fun!

Most of you that have followed my previous posts know that I’m a process kind of guy!  I’ve introduced formal lifecycle management into several organizations.  The teams that I’ve led have successfully utilized process enhancements to drive improvements in productivity, overall capacity and quality within various organizations large and small.  Utilization of a known process allows you to begin to measure various pieces of the lifecycle – looking for inefficiencies and issues that impact your overall ability to deliver for the organization.

Now all that said, each organization needs to find the lifecycle process and development paradigm that will work with their culture.  I’m not going to try and tell you what development paradigm you need to follow because I don’t know your organization.  Within the organization I currently work for we largely follow a waterfall process with some agile techniques utilized within various teams.  This works for us and the style of applications that we create/support – mostly technical interfaces within the payments industry.  Our overall lifecycle has various checkpoints/gating that we use to validate we are ready to move to the next stage.  This works for us!  We’ve significantly increased our productivity and capacity over the last decade and have improved the overall quality of applications that we are delivering to our production environment.

While all this has been good, I occasionally notice when people are hiding behind the process versus just getting the work done!  Not every project needs every step of the lifecycle.  Some are small enough and straight forward enough that we can skip various parts of the process or make the decision not to create some of the standard artifacts/documentation.

Decisions need to be made up front when the project is defined.  Those in the know, need to direct the teams when a project needs the full pomp and circumstance of the lifecycle and when the teams have the option to skinny up the process and skip parts of the lifecycle.  That means at the very earliest stages of Discovery, the Project Sponsor should be giving direction to the team on what the risks are associated with the project which can then drive decisions on how much of the process can or should be used on the project.

Additionally, once a project has been initiated, I think individual team members need to be cognizant of what is happening and make recommendations to the Project Manager if they feel certain pieces of the lifecycle could be skipped or maybe some documentation might not need to be created.  I’m not saying that we’ll always make the choice to skip over pieces of the lifecycle or to not create various pieces of documentation, but as leaders, we need to listen to the recommendations of the people closest to the work and if it makes sense, say yes!  When we decide that we can skinny up the process used within an individual project or that we can eliminate some of the standard documentation, those decisions should be documented.  That way, there is a record of the decision and the reason is documented and shared with the Project Sponsor.

Overall, we still need to deliver for the organization!  Delivering the requested solutions with the necessary features/functionality; delivering a solution at or below the expected budget; delivering a solution with the highest levels of quality.  Our teams should be held accountable to ensure we are delivering successful solutions at the end of the project.

If you'd like more information on my background: LinkedIn Profile

Logic and Project Management!

As a child, I was glued to the television whenever there was an opportunity to watch Star Trek!  I loved the show - campy by the standards of today, I couldn't help myself as I wanted to be on the Starship Enterprise as she traveled to the stars.  And, yes, my favorite character was Spock - followed closely by Scotty.  Spock in may ways spoke to many of us - using logic instead of emotion to solve problems.  And when he did let his emotional side out of the box - showed that emotion could and would frequently lead to painful mistakes.

So, why am I using space within a blog focused on project management and applications development to discuss Spock?  Logic - use it to succeed within your role.  Strip aside the emotion that you feel when confronted with issues and follow the facts!  Stay calm, track down the details and use those details to identify the move forward solution.

No project of any realistic size moves from idea to implementation without some sort of issue rising up, ready to take the whole thing off the rails and into the ditch.  Some problems are small and others tend decloak themselves like a Klingon battle cruiser to surprise and fire upon your Starship Enterprise!  These incoming salvos threaten to overwhelm you, the team and the project.  At this point, you can either act emotionally, running around without a plan and make the problem worse.  Or, you can act like Spock - use logic to create a plan, execute the plan and overcome the issue.

Planning:

Sometimes with a small issue, you can 'wing it' and successfully manage the issue.  That said, the larger the issue, the more likely you will need some type of plan and process to deal with the issue.  Leadership in the organization is going to expect you to communicate the issue, progress in finding a solution and then progress against whatever plans are ultimately put in motion to resolve the issue.

There will be wide variety of additional items you will need to manage within the overall effort:

1. You may need to setup a research team to investigate how the issue was missed or what the cause of the issue was so that this information can be communicated to the management team.
2. Additional personnel resources beyond the original scope of effort associated with the project to identify the overall solution as well as assisting in any work needed to implement the solution.
3. Additional budget resources beyond the original scope of the effort to cover any additional internal or external resources needed to provide the overall solution.
4. Communication plans may need to be put in place to update internal resources, communicate with and manage customer expectations and manage any risk to the overall reputation of the organization.

Each of the above items will require management effort from the Project Manager to ensure that future milestones within the overall effort are adjusted and manged properly; and to coordinate activity between various team members, departments, and outside consultants.  All of this will take careful planning, using organizational skills to minimize the impact to the project.

Methodical:

Many times as a Project Manager you are dealing with choices - making decisions about where short-cuts can be taken; making decisions on whether to go with Plan A or Plan B when there is no consensus from the team on which direction to take; sometimes sifting thru agonizing amounts of detail to understand an issue so that it con be communicated to the management team.

As the complexity of a problem increases, the number of details being tracked or managed associated with the issue will grow beyond your minds ability to track them all.  You are going to need processes in place that allow you to align the issue resolution within the overall tracking mechanisms in place to manage the project.

1. You will need to track new data points within and aligned to the overall project - new milestone dates, budget information, new internal and/or external resources, new equipment that may need to be purchased.
2. You will need to realign your current schedule to accommodate any new milestones associated with the new effort.  Especially those new milestones that will require current or future activity within your plan to be delayed or altered.
3. You will need to ensure that communication plans are executed properly not only to manage internal expectations, but just as important to ensure that customers, vendors, the media and other 3rd parties are kept in the loop.

Your role as Project Manager requires that you have a plan, that you execute the plan and that you manage the expectations of your team members.  You need to be the calm within the storm.

Detail Oriented:

Team members are going to be hitting you with lots of information - your job as Project Manager is to sort through the minutiae and ensure that the relevant data is recorded, tracked and used to make decisions throughout the overall project lifecycle.  As Project Manager, you will be expected to identify the important pieces of data, communicate that to the team and ensure that the information is available within meetings as decisions are made on the forward progress of the project effort.  

Additionally, management will expect that you understand the relevant pieces of information within the flood of details and know when to present that information up the ladder.  Many a Project Manager or Manager have failed when they have forgotten to keep the leadership team informed on decision points and the underlying information used to make those decisions.  I'm not saying that you should have the expectation that your being micro managed - but when there is an unforeseen issue that crops up, over communication is necessary to ensure that everyone understands the nature of the issue, the solution being implemented and the overall impacts to the organization.

Logical:

You can be angry and frustrated - that however is not going to help you move the ball forward and find a solution.  At this point, you need to step away from your emotions and use logic to understand where your at, what data points you have available to make a decision and then make short and long term decisions based on that information.  Knowing that you can adjust future activity and decisions based upon additional data points that surface.

Spock would 'follow the facts' to get to the answer - wherever those facts happened to lead him.  That's your role!  You will be tempted as angry and frustrated team members, management, customers or 3rd parties call you or come over to talk with you.  At times, you will want to 'fire back' at the individuals - however, it is better to step back, take a breath and then approach the conversation.  Focus on the fact, just the facts!  Use logic - it is the best tool you have at your disposal to deescalate the situation.

Mr. Nimoy, you are and were an inspiration to many of us ... may you live long and prosper among the stars!

If you'd like more information on my background: LinkedIn Profile

Education and Software Development - It's going to get Rough!

I've been talking to several different groups lately on how we attract more people into technology fields - specifically Applications Development.  If your an employer and you're out looking for development talent - it ain't easy!

Maybe for the larger companies that have offices all over the country and that can pull from multiple pipelines, they might have it easier.  But for many small to mid-sized companies that are attempting to build or maintain their development shop - it's tough to source good talent.

Don't get me wrong - if you take your time, don't panic and hire the 1st candidates that show up (even though they don't match the qualifications or clearly will unsettle the team) and force yourself to hire individuals that truly meet the needs of the position and have the personality to fit in with the team, you can do it.  The flip side is you loose months of productivity within the team because the position sits open.  Now let me state right here - I will take the pain of an open position vs hiring the wrong person into the position.  And, yes, I have the scars to prove hiring the wrong person is a bad idea.  Trust me, it just doesn't work.

I will not speak for every company, or every geographical area across the United States.  We all have our own issues when attempting to find employees.  Overall, I think I have a great story to tell prospective employees - from the organization that I work for to the community that we work in, there are a lot of positive things happening.  Look no further than the following link if you want to know why folks should look to metro Des Moines area as a place to work and live.  This is a beautiful community with easy access to other metro areas and a lot of reasons to live and play right here at home.  We have plenty of colleges and universities in the metro area and our K-12 educational system is as good if not better as any other school district in the country.

However, I compete against a lot of companies in the local area for talent - large financial and insurance companies, to small and mid-tier companies - including tech start-ups.  The baby boomers are beginning to retire - which is leaving holes in all of our teams.  And our companines are demanding that IT shops expand to meet the needs of internal and external users.  In essence, we are competing for the same talent and we all need to be honest about where we are going to find these workers and also be honest about the false criteria we have within our hiring process that rules out good people.

Back in the day, many school districts actually had software development classes taught in the high schools.  I was lucky, when I was 12 I had a friend show me a teletype terminal (just dated myself) hidden in a small room at the middle school I attended.  I was curious and wanted to play around with the thing - not knowing what it could do.  Luckily, I had a math teacher that got me an account on the computer that the terminal was connected to and I began to teach myself BASIC.  By the time I hit high school, I was able to take formal software development classes using Fortran (and, yep, I've dated myself again).  If my memory serves me right, the high school instructor that taught me Fortran also ended up teaching me Assembler outside of class - that was some real fun.

Today, very few K12 school districts have formal technology classes provided to students.  Some of the larger schools in the metro area are able to provide them, but many don't have the money and the smaller school districts from what I can tell don't have the expertise or the money.

Well, in my opinion something is going to have to give:

1. As parents - we need to stop hitting the easy button!  School is to prep our kids for the real world after they graduate.  While I encourage my own kids to be involved in sports - it's not at the expense of their education.  If there is a tough test coming up - I'll pull them out of practice to ensure that they are ready for the test.  We also need to speak honestly with our kids about what careers will allow them to live independently when they leave the house and move out into the real world.  We also need to support the instructors that are teaching our kids - that means when they aren't getting the grades we expect we hold the child accountable as well as the teacher.
2. At the middle school level - kids need to be given formal opportunities to play with technology both from the hardware and development perspective.  We also need to change the way that we communicate these opportunities and ensure that we market these career opportunities equally to young women and young men.  Our field is woefully underrepresented by women - this didn't use to be the case and we need to turn this around.  If that means we have young women only technology competitions, than we have to think along those lines.
3. We need to begin ensuring that every school district has the means to provide technology trade classes to their students.  Much like we have trade classes for auto (used to also have for metal and wood - some high schools still do), we need to have trade classes at the high school level for Technology fields.  If done right, these students should then be eligible for entry level jobs into the work force.
1. Infrastructure courses that allow students to learn how to build and troubleshoot networks.
2. Application courses that introduce students to the concepts of software development using scripting languages and progress to more structured languages used by business.
4. We need to encourage our State Department of Education to ensure that Computer Science courses taught at the high school count towards the overall Math and Science credit.  Some states have even moved to count these courses as foreign language courses replacing Spanish, French or German.
5. We need to look at the possibility of software educational boot camps.  I've been looking at these as tools to find developer talent over the last couple of years.  I have yet to pull the trigger, but based on what I'm reading and hearing, this is going to become a valid tool for many of us.  This is a very compressed educational and hands on environment that gives someone the basic skills they will need to join a firm as an entry level developer.  Usually requiring 10-12 weeks of 40+ hours a week to get the student ready and certified.
6. We need to encourage and work with our Community Colleges to ensure that their course curriculum matches the needs of the business community - unfortunately, technology changes happen frequently and it's tough for the Community Colleges to keep retooling for the latest greatest fad.  We need to encourage the Community Colleges to stick with the bread and butter of what is needed within the local business community - augmented with some of the newer technology.  Slow down the pace at which they retool.
1. While some of the scripting languages are hot, most business have standardized on Java, C++ and C#.  Let's make sure that they are learning the languages that will get them jobs.
7. We need to continue to work with our 4 year colleges and universities.  Ensuring that their course work aligns with the needs of the business community.  These are fine institutions and they provide a much deeper experience for candidates before they come into the workforce providing both deeper theory and the practical how to of applications development.
8. As business leaders and technology leaders - we need to make sure we are seeding our technology teams with entry level candidates when at all practical.  While it is easy to go out and hire only 'experienced' candidates - we are doing a disservice to the organization by not mentoring our next generation of leaders and subject matter experts.

We have become somewhat complacent because we have traditionally held a very strong lead on the rest of the world.  That lead is evaporating and we need to ensure that we are preparing the next generation to continue along the journey. 

Collectively, we need to get off our back end and demand the best from our kids and their schools.  We need to look at multiple ways to source entry level candidates into our organization and we need to be flexible when we look at how these entry level candidates got their education.  The days of sitting back and demanding that every candidate have a four year degree are over.

If you'd like more information on my background: LinkedIn Profile

Off-Shore Development - Plan it right or Fail!

Off-shore development continues to be a discussion point within many organizations.  I've managed teams across the US and had the occasion where I've used off-shore resources.  Let me share some of the experiences in the hopes that it helps others that struggle with the model or are questioning whether to proceed with the use of off-shore resources.  I won't claim this represents the model to run off-shore development, ultimately, you need to make the decisions that will work within your organization.  Hopefully, this will shine a different light on the topic and allow you to gain insight that may help you make the decision to use off-shore development resources or to keep the development on-shore.

First, it is not easy.  If you think this will solve issues within your current development lifecycle - don't bet on it.  If you're going to seriously begin to use off-shore resources, you better plan appropriately, or you'll pay the price with development timelines that get extended and budgets that creep beyond your expectations.  In the worst case scenario, you'll end up rolling product into production that has not been properly tested and vetted.

Some of the breakdowns that my teams encountered in using off-shore resources are as follows:

1. Communication - eliminating the natural lag in communications as teams work shifts that do not align.
2. Design Aberrations - ensuring the product developed fully conforms to the original design/requirements.
3. Coding Standards - putting processes in place to ensure that the off-shore development team followed the development coding standards of our internal teams.
4. Quality of Code - ensuring that the code had been properly tested all the way through integration testing with other application silos/subsystems.
5. Quality of the Team - ensuring the consistency of development resources applied to projects.
6. Product Knowledge - ensuring that knowledge of team was retained from project to project.

The above list covers the major challenges that we encountered.  Let me go in to some level of detail so that you can get the flavor of what was experienced and how we handled the longer term needs of the organizations use of off-shore resources.

Communication: Each and every day, without your knowledge dozens and dozens of project decisions are made as developers lean across the walls and talk to each other or see each other walking around the office.  My teams have been no different, requirements and designs could change based on a hurdle that needed to be solved and a quick conversation in the hall.  Suddenly you have a team separated by multiple time zones - in my case, they had left the office for the day by the time we arrived in the office.  If the remote team had a question, or hit a roadblock and needed direction, there was an automatic lag of at least 1 work day.  If it was a serious issue, the team might loose several days as communication threads worked their way through email.  In extreme instances, we might have some of the remote team stay late or some of the local team come in early to establish conference calls and work out the issues.

Design Aberrations: The standard methodology we used to develop project requirements within the organization wasn't sufficient to support the use of outside resources.  Didn't matter if those resources were on-shore or off-shore, our teams were comfortable dealing with each other and could abbreviate how the requirements were documented.  There were a lot of things assumed within the requirements that didn't need further explanation because the teams had years of experience working together.  This continued to feed through the process as design documents were generated by the team.  Suddenly we introduced a team of developers that did not have that tribal knowledge.  The results were obvious in hindsight, the off-shore resources built the product to match the documented requirements and designs.  The only problem - those requirements and design documents didn't contain the unspoken elements known by the internal teams.

Coding Standards: Some of the products that we chose to develop off-shore ended up needing to be supported by local teams.  We quickly found out that the coding standards we had in place were not documented thoroughly and left many items up for consideration.  Translation, the remote team was producing code that looked like none of the other code that was used internally.

Quality of Code: The internal teams had many years of experience working together, touching each others code and making the necessary revisions to the code base.  Suddenly we had bugs that had been solved being reintroduced into the code base later in the development cycle.  Worse yet, we would find chunks of code that were never being executed, yet were loading up the code base.

Quality of the Team: Just as we were getting used to working with one set of developers, suddenly they would be reassigned to a different project and we would end up having to reacquaint ourselves with a new team.  To say that this slowed down development and introduced inconsistencies into the code base would be an understatement.

Product Knowledge: As we completed development with one project and started up the next project, we were not assured that the team we had gotten used to would continue on and do development on the next project.

None of this is serious and can be resolved, but you need to think through the engagement up front and take the necessary measures to protect your organization.  Here are some of the tactics we began to utilize to minimize the risk in the use of off-shore development resources:

Communication: We required the off-shore company to place one of their resources on-site with our local teams.  They became the primary communication point between our teams and the off-shore resources.  They sat in on the meetings locally and could catch the small things that needed to be communicated to the off-shore team.  They could do the impromptu meetings in the hallway and get that information promptly to the remote teams.  Our project timelines included buffers to accommodate the communication lag between the teams.

Design Aberrations: We ended up beefing up our Business Analyst and Architecture teams to create more thorough documentation.  Our documentation became much more thorough and attempted to accommodate the things that people took for granted.  The architectural diagrams became much  more sophisticated outlining all servers touched, all databases touched and were color coded to identify new, changed or removed elements.  Design documentation began to reference not only the objects that would be touched, but could go down to the individual methods and parameters when needed.

Coding Standards: We ended up going through our coding standards and documenting much more thoroughly how code was to be structured, how variables names were to be created, what security precautions were to be taken when creating the code, etc. 

Quality of the Code: Code created by off-shore resources was required to go through the same code review process that we used for internal teams.  This ensured that our senior developers were reviewing the code - exactly as would be done for internally written code and that they could catch issues and feed them back to the remote team.

Quality of the Team: After some experience with team members shifting, we ended up negotiating with the off-shore company to ensure that we had a core set of developers that would not be reassigned off of the project.  This allowed us to maintain some level of consistency within the off-shore team and addressed quality of code, coding standards and communication issues.

Product Knowledge: Similar to the Quality of the Team issue - by keeping a core team of developers assigned to our projects, the off-shore teams knowledge base of our products began to increase and they could begin to anticipate some of the issues ahead of time.

I want to state again, these were experiences that my team had in working with off-shore resources.  Other organizations may have different experiences.  Hopefully, some of these issues and the ways in which we resolved them will assist you with determining whether you can support the use of off-shore development resources.

I typically do not use off-shore resources unless there is a need to temporarily augment our internal resources to accomplish specific development/project goals.  That's a choice that I feel comfortable with based on the particular business needs within the organization.  In previous roles, I've had the opportunity to work extensively with off-shore resources.  If you're going to use off-shore resources, I highly recommend you pick a couple of small projects and trial a couple of different vendors to establish which one will work better with your current development paradigm.  Don't be afraid to switch  vendors if you don't feel you're being taken care of - ultimately, it's you that will be held accountable for the delivered product.

If you'd like more information on my background: LinkedIn Profile