Archive for August, 2008

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.

    Advertisements
    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 )

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