team building

Tools of the Trade – Build Environment

Posted on August 9, 2008. Filed under: building software, software development, team building |

  • Source Control
  • Bug Tracking Software
  • Dedicated Build Environment
  • Testing
  • Documentation
  • Modern Hardware
  • Can we build it?  Yes, we can!

    But can you build it again?  and again?  and, oh how about rebuilding that release we did 6 months ago for that weird client who wanted the application in Esperanto?

    Oh?  You swapped your machine over to Linux since then!

    Oh?  You have switched to mono!

    Oh? You now use MonoDevelop!

    I think that everyone knows that techies (developers especially) love installing new applications and widgets and open source projects and who knows what else on their machines. 

    I used to install trial versions of games onto my development machine.  That was great fun until the day that visual studio would no longer worked.  I guess that somebody got a bit overzealous with their uninstall program and started deleting libraries that they thought were not needed by other programs.  The end result is that I spent a couple days reformatting the machine and reinstalling everything. 

    works on my machine, starburst

    The developers favourite excuse when the testers come forward with a bug: “Well it works on my machine”

    For those reasons and more, you need to have a machine that is dedicated to building your software.  It needs to be a pristine and bare bones installation from the ground up.  Access to the machine needs to be controlled and the fact that no one messes with the build machine needs to be hammered home.

    You could even go so far as to use virtual machines for the build machine and keep different images (or at the least checkpoints) around for when you make changes to the build environment.  While Microsoft does its best to not blow things up with patches, it does happen (XP SP3 ring any bells?). 

    While it is helpful to have a dedicated build person or team of builders, that isn’t so important.  I feel that it is important that everyone on the development know how to build and install the software.  If the developers are so focused on little pieces of code and unfamiliar with the big picture then trouble will be brewing down the line.

    I like to designate one person as the build primary and let them deal with the details of building the code and distributing the build and maintaining the build notes.  Since most people don’t like this job (and to ensure that everyone is familiar with the process), it is a good idea to rotate this on a regular basis.  However, don’t assign the shiny new face as being in charge of builds; they don’t know the software, they don’t know the team, they don’t know the system environment; despite their brilliance and inspiration to do an excellent job they will mess up.

    Read Full Post | Make a Comment ( None so far )

    Celebrations & Vacations

    Posted on August 8, 2008. Filed under: celebrations, random thoughts, tangents, team building |

    I ran across an old friend yesterday who is back in town to get some visa issues sorted out.  He had invited a bunch of people together for drinks and reminisce over old times.

    As I was sitting there and listening to stories from some of his other friends I found an interesting pattern.  A great many of the people there had worked together as teenagers at a local restaurant.  They talked with great fondness about those days and all the fun that they had.  They didn’t remember the hard work of serving people and dealing with customer complaints.  They remembered the fun times when they shut the restaurant down and sat around watching movies, they talked about disagreements they had with the boss, and camping trips that they shared.

    It got me thinking that this is a definite aspect of building a team.  These people have all left the restaurant and moved through life: relationships have come and gone, children have arrived, jobs have been found and lost and kept, but the friendships have endured.  Sometimes when we build a team and are focused on delivering software we sometimes forget that there is a world after the job.

    I think that sometimes we forget the larger world and our obligations to the social interactions of our employees.  If you can build a team where friendships develop and last over many decades it almost seems that the building of software becomes of secondary importance.  Jobs come and go, money comes and goes, but friends are something that need to be cherished and kept through life.

    By building a team that works hard together and plays together you will have started knitting together the individuals into a cohesive whole that is larger than the sum of the parts (wow, how about some cheesy images there!)   You will have enriched the lives of the team members and made the world a better place by connecting people and allowing them to support each other through the difficult journey of life.

    Read Full Post | Make a Comment ( 1 so far )

    Tools of the Trade (Part3-Fix it,Fix it, Fix it)

    Posted on August 1, 2008. Filed under: bug tracking, software development, team building |

  • Source Control
  • Bug Tracking Software
  • Dedicated Build Environment
  • Testing
  • Documentation
  • Modern Hardware
  • Sit down (oh wait you already are).  Close your eyes.  Take a deep breath.  Imagine a perfect world.  Okay, now you need to change it so that you are picturing my perfect world.

    In mine, the sun is shining, the birds are chirping, I have a cold beverage in my hand and I’m waiting for the phone to ring.  The testers have the latest build and I have no cares in the world until that phone rings and I can spring into action and devote my entire time and energy to fixing the bug.  I can walk over to the tester’s computer and have them reproduce the bug and then I can dive into code and fix it while they wait for the fix.  Oh, the sky is purple and a flock of pigs just flew by.

    Yeah, not going to happen.  There are many things wrong with my perfect world.  Not the least being the inefficiency of doing testing and bug fixes in serial instead of parallel (yeah call me old school).

    For a typical developer a day involves working on multiple projects, switching from a discussion on delegates, attending a status meeting, checking their facebook profile and connecting to their home machine to check on the download of the latest movie (this multi-tasking is an issue for a later discussion).  Compound this when you have other people in the mix: testers, support techs, project managers, customers. 

    With so many different demands and priorities information passed from person to person is bound to get lost.  Emails are deleted, paper is recycled, conversations are forgotten.  You definitely need a common shared medium that allows communication and collaboration between the different parties.  The common collection point allows data on bugs and fixes to be stored and pulled up when it is convenient to each individual.  The stored data in a bug database becomes invaluable as time progresses.

    It allows developers to fix bugs and explain the fixes back to testers.  It allows testers and developers to work on their own schedules and locations (how many people want to wake up at 6am to hear about problems with their support?  no one except the tech support guys).  The tool can be used by customer support to log customer complaints and give feedback to customers on the status of their issues.  It can be used as a planning tool for future releases( an enhancement request is very similar to a bug and bugs can be prioritized by the number of times it is reported by an end customer ).

    It should be noted that bugs are not only found in the software, they are found in other artifacts of the development process: requirements, mockups, wireframes, training material, installation procedures.

    While a bit more difficult, the bug database could form the basis of a knowledge base for helping customer support: customers call in with a problem, it is logged as a bug and then a solution is given as a fix.  When the next customer calls in, you search for a similar problem and then read out the solution.

    The only real downside that I see to a bug tracking system is misusing it for generating non-valuable metrics on a project.  People enjoy printing reports on number of open bugs, number of closed bugs per developer, number of bugs raised by tester, length of time a severity 1 issue is open.  These approaches are not always helpful in understanding and managing software projects (well, maybe the last one is a valid metric), but then as I’m often the one being held responsible for the bugs my viewpoint may be a bit skewed.

    What are some of the important aspects of a bug tracking tool?

    • Workflow – this defines who will look at the bug and what actions that person is allowed to take.
    • priority/severity – defines the importance of the bug
    • description – explains how to reproduce the bug, impact of bug
    • solution – explains how the bug is solved
    • exportability – at one time or another you will migrate to another system.  Can your data be transported with you?

    There are many different bug tracking solutions out there and you need to find the one that best feeds your operational and project needs.  I’ve worked with open source tools, commercial products, custom in-house solutions.  Heck, I’ve used google apps to track bugs for a small project that I ran with a few friends.  The key is to find one that you like and stick to it.

    Some interesting and popular tools:

    Read Full Post | Make a Comment ( 1 so far )

    Tools of the Trade

    Posted on July 29, 2008. Filed under: software development, team building |

    Before we get into some of the intangibles that define a great development team, we need to discuss some of the tools that build a foundation for a team.  Without these tools and procedures in place, then the team will be spinning wheels, wasting time and generally unproductive.

    This may be a strange discussion as I will not be pushing for any specific tools or technologies.  This is for good reason; tools and technologies come and go but the general principles are eternal. 

    Take a first year computer science course for example.  Back in those days when I was a rosy faced student who expected to solve all the world’s problems, I was doing my assignments in Pascal.  Over the next few years, for that same course, the language changed to C then C++ then Java.  However, the contents of that course stayed the same: looping, conditional statments, stacks, queues, linked lists (well maybe not in Java-but you get the picture).  The general concepts and data structures are important to know and understand while the tools to achieve your goals will change and improve.

    The specific technology and approach should be tailored to your team.  The tools and process should be there to help not to hinder the development process.  Once the process becomes the big thing and you are spending more time worrying about ‘Am i doing this right?’ instead of ‘Am i doing the right thing?’ you need to step back and revaluate.

    It is that way with developing software.  There are a few essential aspects of developing software that are just ‘best practices’.  If you master those aspects you can worry about more important things such as learning the details of the new silver light release, what is the difference between a machiatto and a latte and why did Indiana Jones climb into that fridge?

    So, what are those essentials?

    • Source Control
    • Bug Tracking Software
    • Dedicated Build Environment
    • Testing
    • Documentation
    • Modern Hardware

    Perhaps one reason to start with these details are that they are easy to implement.  Just take some money, take some time and you can have these elements with little fuss and little muss.  Some of the other aspects of building team takes time and takes leadership skills.

    Read Full Post | Make a Comment ( 1 so far )

    What makes a good development team?

    Posted on July 25, 2008. Filed under: Introduction, software development, team building |

    Yes, it is a good question.  It is something that I’ve been thinking about a lot over the last couple months.  I’ve been a part of many different software teams over the years and while each team has their own strengths and weaknesses there hasn’t been one team that excelled in every area.  That is to be an expected outcome of building a team from individuals that have foibles and personalities (and as you know programmers definitely have foibles and personalities).

    However, that should not be an excuse to keep a team as it is and accept their current behaviour and performance as a given.  You need to continually grow and learn and stretch the team.  If you

    remain static then you stagnant and can no longer react to the business market and are in danger of becoming an irritant to the powers that be.

    When I first started thinking about this, the elements that first came to mind were concrete elements of software development that must be present just to perform the core task of producing software.  They are things like testing and source control and written documents.  This quickly progressed to some of the intangible skills that will transform a group of smart individuals into a high performing team of skilled and enthusiastic developers that will be a major asset to the success of a business.

    Next post… Elements of a good team

    Read Full Post | Make a Comment ( 1 so far )

    Liked it here?
    Why not try sites on the blogroll...