Rock Soup, It Works!
At my current place of employment, we fail the Joel Test. We used to score exactly 0 (ZERO) on this test. At first, I thought this merely annoying, but as time passed I felt I had to do something about it. I was often distracted from what I should have been doing to deal with something that resulted from not having at least some of these processes in place. The tipping point was when I was trying to work too often from home, and I was having to copy the code and the database to my USB drive, and then install both on my home system before I could get any work done. Having freshly read The Pragmatic Programmer I thought I would give some of the techniques in that text a whirl.
My primary tactic was what they refer to as "Rock Soup." This is the practice of planting the seed of something better. You galvanize the actions of the group once they have a focus and can see the light at the end of the tunnel.
The first step was task and defect tracking. I, again, took Joel's advice and just starting using a spreadsheet. At this point, it was just me and another programmer working in a single office, so he saw me using it to record the things that we had to do, when we needed them done by, and just little tidbits of information. He started to have me label things in there by who was going to do them. Then we needed more columns to describe the nature of our tasks. Then we needed a more powerful system. He had already started a system that would allow us to make notes in our development product - a precursor to letting our users make notations in that same system.
Asking for forgiveness is easier than asking for permission. If you know something is right, just do it that way. Nevermind the boss who is breathing down your neck to get out a product six months before it could realistically be functional. Nevermind that you have several days worth of programming to finish this afternoon. Do it right. Later, you will be happy you did, when you spend less time testing, debugging and maintaining that very same code. Your boss will be happy too, because there will be less bugs reported against that code, and more customer satisfaction before they have to report a bug.
In this spirit, I made alterations to the task list system. I added various fields, split the tasks into sub lists, made the interface easier to use. This inspired my coworker to do the same. In the end, we had a fairly functional defect tracking tool that would allow us to print out reports for management to review. Could they understand what the bugs each meant? Doubtful. Did they love getting the report and watching the count move up and down? Absolutely.
Things started to get harry with the source code. In the past we had tried to use Visual Source Safe. It wouldn't allow us to work from home, and as the project dragged on, it appeared we would be working more and more from home (weekends, evenings, mornings, etc.). We needed a better solution. We asked the people in charge of the project (5 of them, 2 programmers - see a problem?) if we could get a better version control system. They agreed once we made it clear that their goals were aligned with ours, namely us working on the code easier. So, I research the best alternative for us (in our case, it was SourceGear's Vault) and we implemented it. A couple of weeks go by, and I start to get worried because our temporary license is about to expire. I talk to the heads of state, they are interested by I get no action. I buy the software. I install the license. I send them an expense report. This is normal operating procedure at most companies, but you would think that the company would be a bit more interested in protecting their quarter million dollar investment (in man hours alone) with a ~$600 version control system.
I'll stop here, because I am sure you all get the point. Just do something, especially if you know it is the right thing to do (like having version control software, or testing!). Get permission after it is done. Get your coworkers to buy in by doing it yourself and showing them how much better it is. Rock Soup really works.
My primary tactic was what they refer to as "Rock Soup." This is the practice of planting the seed of something better. You galvanize the actions of the group once they have a focus and can see the light at the end of the tunnel.
The first step was task and defect tracking. I, again, took Joel's advice and just starting using a spreadsheet. At this point, it was just me and another programmer working in a single office, so he saw me using it to record the things that we had to do, when we needed them done by, and just little tidbits of information. He started to have me label things in there by who was going to do them. Then we needed more columns to describe the nature of our tasks. Then we needed a more powerful system. He had already started a system that would allow us to make notes in our development product - a precursor to letting our users make notations in that same system.
Asking for forgiveness is easier than asking for permission. If you know something is right, just do it that way. Nevermind the boss who is breathing down your neck to get out a product six months before it could realistically be functional. Nevermind that you have several days worth of programming to finish this afternoon. Do it right. Later, you will be happy you did, when you spend less time testing, debugging and maintaining that very same code. Your boss will be happy too, because there will be less bugs reported against that code, and more customer satisfaction before they have to report a bug.
In this spirit, I made alterations to the task list system. I added various fields, split the tasks into sub lists, made the interface easier to use. This inspired my coworker to do the same. In the end, we had a fairly functional defect tracking tool that would allow us to print out reports for management to review. Could they understand what the bugs each meant? Doubtful. Did they love getting the report and watching the count move up and down? Absolutely.
Things started to get harry with the source code. In the past we had tried to use Visual Source Safe. It wouldn't allow us to work from home, and as the project dragged on, it appeared we would be working more and more from home (weekends, evenings, mornings, etc.). We needed a better solution. We asked the people in charge of the project (5 of them, 2 programmers - see a problem?) if we could get a better version control system. They agreed once we made it clear that their goals were aligned with ours, namely us working on the code easier. So, I research the best alternative for us (in our case, it was SourceGear's Vault) and we implemented it. A couple of weeks go by, and I start to get worried because our temporary license is about to expire. I talk to the heads of state, they are interested by I get no action. I buy the software. I install the license. I send them an expense report. This is normal operating procedure at most companies, but you would think that the company would be a bit more interested in protecting their quarter million dollar investment (in man hours alone) with a ~$600 version control system.
I'll stop here, because I am sure you all get the point. Just do something, especially if you know it is the right thing to do (like having version control software, or testing!). Get permission after it is done. Get your coworkers to buy in by doing it yourself and showing them how much better it is. Rock Soup really works.
posted by Josh at 8:18 PM
1 Comments:
Josh
Good going. It is always best to do something - anything! - instead of blaming management or other people. Once you do it, you usually find them agreeing to what you have done. Most people have fear and inertia, by default. So take the first step and you will find followers all the way.
Krish
Post a Comment
<< Home