Rusty Divine

Live, Love, Learn, Teach

Learning Design Patterns - Strategy Pattern

This week I’ll be subscribing to the Strategy Pattern in my series on design patterns plucked from this book and from examples on the Internet.

What is it?
The Strategy Pattern defines a family of behaviors, or algorithms, encapsulates each one, and makes them interchangeable.

Where is it used?
An example of when the Strategy Pattern is used would be for grouping different sorting algorithms. A super class could be created that has a sorting behavior defined as a sorting interface, which delegates the sorting. A sub class that extends the super class and when the inherited sort behavior is called (sub.sort), the sub class can call a specific sort algorithm. Furthermore, if the super class allows the sort behavior to be set at runtime, the sort behavior can be changed dynamically.

But why?
The Strategy Pattern increases flexibility by allowing the algorithms to vary independently from the classes that use them. New algorithms can be added, and the existing classes can then take advantage of them without changing any of their code.

OK, and how is it implemented?

public abstract class Student {

	//Declare the two reference variables for
	//the behavior interface types
	IGotoClass gotoClassBehavior;
	IDrink drinkBehavior;
	
	public Student() {}

	//All students will dress for class
	public abstract void display();


	//delegate the Student behaviors; this is
	//an example of using composition, which
	//should be favored over inheritence because
	//it increases flexibility by allowing
	//the class to change at runtime.
	public void GotoClass() {
		//delegate GotoClass behavior
		gotoClassBehavior.gotoClass();
	}

	public void Drink() {
		//delegate Drink behavior
		drinkBehavior.drink()
	}

	//Add setBehavior's so that the class
	//can be changed at runtime.
	public void setGotoClassBehavior(IGoToClass gtc) {
		gotoClassBehavior = gtc;
	}

	public void setDrinkBehavior(IDrink db) {
		drinkBehavior = db;
	}
}

//Create the interfaces

public interface IGotoClass {
	public void gotoClass();
}

public interface IDrink {
	public void drink();
}


//Goto class behaviors (add more as needed)

public class GotoClassOnBike implements IGotoClass {
	public void gotoClass() {
		System.out.println("I'm riding my bike");
	}
}

public class GotoClassNot implements IGotoClass {
	public void gotoClass() {
		system.out.println("I'm hungover; not going
		to class today.");
	}
}

//Drinking behaviors (add more as needed)

 public class DrinkNot() {
	public void drink() {
		system.out.println("I don't drink");
	}
}

//NOTE: The DrinkTons class is also used by the Circus Clown class;
//this code benifits from reuse without the baggage of 
//inheritence
public class DrinkTons() {
	public void drink() {
		system.out.println("I'm a lush");
	}
}


//Student Simulator

public class GoodStudent extends Student {
	gotoClassBehavior = new GotoClassOnBike();
	drinkBehavior = new DrinkNot();	
}

public Class BadStudent extends Student {
	gotoClassBehavior = new GotoClassNot();
	drinkBehavior = new DrinkTons();
}

public class miniStudentSimulator {
	public static void main(String[] args) {
		//Create a new student while programming to the 
		//Student supertype to exploit polymorphism
		Student goodyTwoShoes = new GoodStudent;
		
		//Call the GoodStudent's inherited behavior's
		//which then delegate to the GoodStudent specific
		//behaviors; i.e, don't drink and go to class
		goodyTwoShoes.Drink();
		goodyTwoShoes.GotoClass();

		//Now, corrupt the student by drinking and skipping class
		goodyTwoShoes.setDrinkBehavior(new DrinkTons());
		goodyTwoShoes.setGotoClassBehavior(new GoToClassNot());
                //the student is now corrupted and will drink tons and not goto class
                goodyTwoShoes.Drink();
		goodyTwoShoes.GotoClass();
	}
}

Learning Design Patterns - Observer Pattern

This week I’ll be subscribing to the Observer Pattern in my series on design patterns plucked from this book and from examples on the Internet.

What is it?
The Observer Pattern helps keep your objects in the know; i.e., communicating with other objects about important events.

The pattern is analogous to a newspaper company and its subscribers. Say one day your power gets turned off by the electric utility since you haven’t paid your bill for six months (this actually happened to me one time; it was the first apartment my wife and I lived in and I assumed that the power would be transferred over to me and I’d get a bill. Evidently I needed to call the utility and subscribe, and since I didn’t, they figured I was Freddy the Freeloader and cut off my juice). When your power is cut off, you realize pretty quickly how dependant you are on it for everything from your electric can opener to your TV, and especially to the Internet. So, jonesing for some news, you call up the newspaper company and subscribe to the paper (it will be at least another 6 months before they realize you can’t pay, and by that time you should have your electricity back anyway). The newspaper company adds you to their list of subscribers, and lo-and-behold the next morning you’re awaken to the thunderous bang of a paper propelled into your front door by a kid with major-league hopes. In fact, every time the newspaper publishes a paper, they make sure you get one as long as your on their list. And when you cancel your account, or they revoke your subscriptions for lack of funds, they’ll take you off their list of subscribers and you’ll stop getting the paper when they publish it.

That’s pretty much it. There’s a publisher, sometimes called the "Subject" and subscribers, also called "Observers". There are a few different ways to implement the pattern, though, like whether the publisher just notifies subscribers of changes, or whether it allows subscribers to get part or all of the data by themselves, or some of both.

Where is it used?
To maintain state and notify other objects of changes. Some examples include a stock-ticker application, weather data service, and machine health and status (e.g., CPU temp, fan speed, etc.).

But why?
Letting the publisher control the data in one place, and then notify any interested subscriber objects when that data changes, is cleaner than controlling the data in each potential subscriber object and separately updating each when that data changes.

The relationship between the publisher and subscriber is described as "loose coupling" because they do interact, but they aren’t so dependant on one another that changing one will affect the other. All that matters to the publisher is that the subscriber implements an observer interface, and all that matters to the subscriber is that the publisher implements a subject interface. The loosely coupled relationship minimizes dependencies, and promotes a flexible design.

OK, and how is it implemented?
The publisher and subscriber each need to implement an interface; to notify and update, respectively.

// Publisher interface
public interface IPublisher {
	public void registerSubscriber(ISubscriber subscriber);
	public void removeSubscriber(ISubscriber subscriber);
	public void notifySubscribers();
}

// Subscriber interface
public interface ISubscriber {
	public void update();
}

//Publisher
public class JournalStarNews implements IPublisher {
	private ArrayList subscribers;
	private string news;

	public JournalStarNews() {
		subscribers = new ArrayList();
	}

	public void registerSubscriber(ISubscriber subscriber) {
		subscribers.add(subscriber);
	}

	public void removeSubscriber(ISubscriber subscriber) {
		int i = subscribers.indexof(subscriber);
		if (i >= 0) {
			subscribers.remove(i);
		}

	public void notifySubscribers() {
		for (int i = 0; i < subscribers.size(); i++) {
			ISubscriber subscriber = (ISubscriber)subscribers.get(i);
			subscriber.update();
		}

	public void hotOffThePress(string News) {
		news = News;
		notifySubscribers();
		}

	public string getNews() {
		return news;
		}

}

//Subscriber
public class NewspaperReader implements ISubscriber {
	private string news;
	private IPublisher JournalStarNews;

	public NewspaperReader(IPublisher JournalStarNews) {
		this.JournalStarNews = JournalStarNews;
		JournalStarNews.registerSubscriber(this);
	}

	public void update() {
		this.news = JournalStarNews.getNews();
	}
}

Learning Design Patterns - Singleton

A while ago now I bought this book on design patterns. At first glance, this book may seem a little silly, childish even, because of all the cartoonish thought bubbles on amusing old photographs and the crosswords and such. After reading the introduction that explained how making learning fun and interesting, and how they were going to trick my brain into paying attention to an otherwise dull subject, and how they sneaked in repetition and other memory inducing tricks, it started to make a lot of sense to me. Even though this book is targeted more at Java developers and I am a .Net developer, it is general enough and explains the concepts well enough that I have no problems understanding it.

This is the first post in my new series on learning design patterns. To say it another way, I am going to be learning these patterns along the way, so any helpful comments and corrections from the more experienced would be appreciated - just be kind!

To start, I figured I would select the classic and deceptively simple Singleton pattern. I guess I could start by writing a monologue about why patterns are important, but I'll leave that one to the academics; I just want to broaden my horizons and am more interested in application. Besides, I know a guy who got a great job in part because he knew how to write a Singleton pattern during his interview (not a bad interview question, I'd say).

What is it?
The Singleton pattern is intended to create one and only one instance of an object that can be accessed globally across an application.

Where is it used?
The Singleton pattern works well in many situations. Common uses include managing connection or thread pooling, application configuration settings, logging, dialog boxes, incremental or other counters, and device drivers.

But why?
Why not just create global variables or static methods? The Singleton pattern is a design convention, a best-practice of sorts and generally it would be better to pick it over the other two methods. Singleton gives you a global access point like a global variable, but is intended to reduce overhead by not initiating the object until it is called, unlike global variables that would be initiated at startup even if they are never used and guarantees that there is only one instance in memory.

OK, and how is it implemented?
Have you ever seen those kooky UML diagrams for design patterns? Crap, I'd have better luck baking a German Chocolate Cake from a recipe in German than writing code based on one of those. Suffice it to say, I have to spell it out instead.

The key ideas are: 1) Use a private constructor so that only the class itself can initiate itself, which will allow it to regulate itself. 2) Declare a private static variable of the same type as the class itself to hold a reference to the object in memory. 3) Create a public method that checks to see if the object exists in memory, if so, return a reference, if not create it first then return a reference. 4) Add other code as needed, but don't allow sub classing (which is impossible anyway since the constructor is private). 5) When it comes to threading, be super careful; it is easy to goof up and allow two instances of the object to exist.

//general example from the book; Java?
public class Hermit {
	private static Hermit singleInstance;
	private Hermit() {}
	public static Hermit getInstance() {
		if (singleInstance == null) {
			singleInstance = new Hermit();
		}
		Return singleInstance;
	}
}
//Direct port to C#
class Hermit 
{
  //prevent optimization reordering with volatile keyword
  private static volatile Hermit singleInstance = null;
  protected Hermit() {}
  public static Hermit getInstance() {    
    if (singleInstance == null) {
	// double-check lock for thread safety and to 
	// reduce overhead if instance exists
            lock (typeof(Hermit)) {
                if (singleInstance == null) {
                    singleInstance = new Hermit();
                }
            }
        }
        return singleInstance;      
    }
}
//Simplified C# code that relies on .Net Framework's intrinsic abilities
sealed class Hermit  //sealed=not inheritable
{
   private Hermit() {}
   public static readonly Hermit getInstance = new Hermit();
   //.Net Framework guarantees thread safety on 
   //static type initialization, and only initializes static
   // properties when the method is first called.
}

Further Reading

Hourly vs. Salary

About six months ago, I switched jobs. The former company was crumbling, the current company is a behemoth. Jumping jobs brings change; for instance, I am no longer a salaried employee. I now punch the clock and am not guaranteed 40 hours of work per week in what my new company terms a "flex" position.

For some, the thought of a fluctuating paycheck and being sent home early would put a puddle in their shoe. It is unnerving at times to consider the worst case scenarios of being forced to make life style sacrifices, losing a car, a house, or even a marriage. And there is a general feeling of lack of control, of letting loose of the reins and watching the team of horses run where they may.

Why do I feel completely comfortable and even more content as an hourly employee?

Still in Control
Really, I am still in control. If the ends stop meeting and the creditors start calling, then I can pick up and move on. The market for my skills and experience is quite healthy, and I'm in one of the best locations in the world to take advantage of the opportunities (Seattle, Washington, USA, that is).

In fact, I may have more control. I can come and go as I please. Best of all, I don't work for free anymore! At a salaried consulting job, it is common to work 45 hour weeks for 40 hours of pay. Now, though, I will get paid for what I work, and if it's over 40 then I get time-and-a-half pay.

I've also noticed that I am more efficient now. I surf the Internet less, I am more conscientious about putting the correct time on my time card (no more putting 8 hours down even though I took a 90 minute lunch) and I try to focus on my tasks. I feel more accountable.

A Reprieve from Corporate Ladder
I spent the last 5 years trying to get noticed in the corporate environment. Noticed I got, but at my last job, there were 30 executives in a company of 120 people - I didn't feel like there was any room for me up there (it was super saturated). In fact, when I asked about the chance of a promotion at my last, fateful review, I was told the company had no notion of promotion. How did all those managers get up there then? Well, that's another story, but it essentially had to do with the company expanding by opening more offices or buying other small companies and keeping all of the managers around. Small company, many offices.

Now, at my new job, I just go in and someone hands me some work to do. I don't feel the pressure to get noticed, only to do my job as professionally as I can. Earlier, a coworker asked me if I was going to the company's open house. I asked, "Why the hell would I want to do that?" (I can be blunt at 7 am, especially since I recently gave up coffee) He said something along the lines of schmoozing and rubbing elbows. I have no ambitions at this company outside of doing my job the best I can, and I feel happy that I don't have to or feel the need to go to the gathering (I am an introvert, BTW, an ISTPto be exact).

Moving out of Dodge
Remember what you were like as a teenager, and maybe even into college? My guess is that when you moved out of your parents house (or when you do) your character will change in a very perceptible way. And here's the rub: when you go back home to visit, you will run the risk of falling back into the old role and may feel like a marionette on strings - not totally in control of yourself, your emotions or actions.

Moving on is a great chance to change yourself for the better. You can adopt a new you, because you will have brand new routines, environment, and people to interact with. I have grown professionally two pegs since I left my old job just a week ago, because it has given me the chance to reinvent myself. I fell into ruts at my old job; gossip, negativity, apathy, cynicism. I knew at the time that it really wasn't like me to be acting in some of those ways, but the more I acted that way, the more my environment changed to foster more of the same. Now, at my new job, I can try to stay away from attitudinal pot holes. I can remember to think clearly before I respond. No one has any preconceptions on how I think or solve problems, I am once again free to just be myself.

Money, Money, Money, Money
I am a capitalist at heart, and money speaks loudly to me. At my salaried job, I told my boss how much I should be making, and he told me to go find a job that would pay me that much. So I did. And, at the hourly job I took, if I work 30 hours a week, I'll be making more than at my salaried job - talk about a difference!

I have a large grudge about ageism - people getting paid more than I do based on age alone. Yes, older people have more experience and are generally better able to cope with stressful situations and lead. Generally. Let me tell you this though; when it comes to technical experience in my field, a ton of people have as much experience as I do, some, but not many have more. The computer industry is different than most industries because it is so damn new. My buddies and I were working on starting a dial-in bulletin board system (BBS) that hosted pornographic material before the world wide web had its first graphical browser. (We coulda been rich if we realized how on the mark we were back then in 1990!) When I sit next to a guy who is 40, is not managing anyone, and knows less about programming, but is making 50% more than me because he is 15 years older, I tend to get a little cynical. (But that was the old me, right? You bet; I left that stinking job.)

At my new job, I do have some benefits like 401k and cheap healthcare, but they are more limited than I had at my old job, or would have if I was full time here. I am lucky that I can go through my wife's health care (which is better even if it was free for me here), which is the big concern for me. There are no bonuses I'm missing out on, but I do only get 5 hours of vacation per period instead of 8.

Turns out I was Right
And, conveniently enough, it turns out that my new job is much more fun than my old job. I like my office space better, my coworkers are a breath of fresh air (for now), and I have new challenges, new experiences, old experiences and lessons to share, and a new outlook on my job.

It could have been much worse; my new job may have been awful just as easily as it turned out not to be. I would like to meet the person who knows how to get a good feeling of what it will be like working at a company before they start working there. For me, I just have to jump in feet first and start swimming.

Top 10 Holiday Gifts for Geeks

Next to kids, out of all the categories you can wrap around groups of people, geeks have got to be the easiest to buy for. I wonder what would happen if like having age-appropriate ranges on toys there were geek-appropriate ratings on gadgets and goodies? We might see labels like, "For any cubicle penned techie", or "Object-Oriented Only", or maybe "Phor Phreaks".

Anyways, I've made a list of 10 uber cool gifts that I personally recommend for myself; i.e., if you've enjoyed my columns the last few months, consider sending any one of these items to me in gratitude.

10. The Spork - There's nothing I heart more than efficiency. Why should I have to put down my spoon and pick up my fork when switching from Dorito Crumbs to french fries? No More!

9. Soda Machine - Mountain Dew is the nectar of the gods. I used to work for Pepsi Co. you know; it was a sweet job. Remember those Pepsi points they put on their 12 packs as a total rip-off of Camel points? Well, every stinking soda machine I filled that year, I cut off those points and turned them in. I got duffle bags, bean bags, various paraphenalia, and to top it off - a Pepsi Mountain Bike - now that's styllin!

8. Digital Pen - It's a pen that writes in ink and, later, you can download all of your pages! I might actually prefer to remove the ink cartridge so that it looks like I'm not writing anything - that will keep those nosey coworkers scratching their heads at your next meeting! Plus, you'll be able to write what you're really thinking as Jane from marketing banters on about how Microsoft Word is the greatest database ever invented.

7. Hot Dog Toaster - Whoa, when I saw this baby I thought, "What would Homer do?" Nuff said.

6. Book Gift Cert - Now that Joel has updated his recommended reading, we'll all be scrambling to be the first on our block to read "For Days with Dr. Deming." Only four? Alternatively, a subscription to Books 24x7 might suffice - they probably have all those books in eTree form (note: if you live in Seattle, you have a free subscription to this through KCLS)

5. or RC Helicopter or Plane - Coders are very controlling, but we also welcome crashes as learning experiences. What says controlled crash better than indoor RC flying objects?

4. IMMORTALITY - If you've got some creepy love going for your geek giftee, then nothing beats giving the gift of everlasting life. For a slightly more romantic gift, turn your favorite geek into atree with floppy-disk fruit (5.25" or 3.5").

3. Ambient Orb - wireless wonder that changes color in response to the stock market fluctuations, IM notifications, new blog posts, and more.

2. Eco Orb - 98.5% of all Geeks' passwords consist entirely of these three letters in this order: g-o-d. Now, let your egomaniac geek friend have a dream come true with this little gem that is a self-contained enviroment that thrives for years.

1. Binary Clock - Separate the script kiddies from the top tier with a clock face that displays time in binary - hours, minutes and seconds! After all, "there are 10 types of people, those who read binary and everyone else."

Wrap Party

The final installment; part six of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

Six weeks go by quickly, and the project is complete. Now it's time to take a look back to see what we can learn about what went well and what did not.

As one measure of the project, I'll use Joel's test of a good software development environment:

  1. Do you use source control? + 1 (We used VSS, shoulda used Subversion - we had some VSS hiccups that cost us time, although, last time I checked Subversion had some problems with ASP.Net projects, too.)
  2. Can you make a build in one step? +1 (no automated script, just hit build in VS)
  3. Do you make daily builds? +1 (Not too applicable to our little web app, but we essentially did this)
  4. Do you have a bug database? 0
  5. Do you fix bugs before writing new code? 0 (didn't use a bug database and didn't really pound on the code)
  6. Do you have an up-to-date schedule? +1 (used Joel's format)
  7. Do you have a spec? +1 (used Joel's format)
  8. Do programmers have quiet working conditions? +1 (got the Team Palace)
  9. Do you use the best tools money can buy? +1 (Good dev machines, latest software & 3rd party components)
  10. Do you have testers? 0
  11. Do new candidates write code during their interview? +1 (I instigated this one)
  12. Do you do hallway usability testing? 0 (shoulda, woulda, coulda)

Our Total: 8 - Not great.

We really should have been using a bug database, and I should have made the declaration that we need to find and fix bugs before writing new code. The project was a bit of a whirlwind, and it felt a little out of control at times, but that's all the more reason to try to confine the chaos.

The project could have supported a tester - we even had a young (read: cheap) guy that was light on work who could have done the job. He left for a vacation to his homeland - Nepal - early on though, and wasn't around for most of the project.

We easily could have done some usability testing - it was even in the original scope. Our usability lead left the project early on for maternity leave, and that loose end just didn't get tied up.

We did have a great team room though, and that was really the hallmark of this project. It was a big breakthrough for us because it was the first time a development team had requested their own room, and it caused some ripples throughout the office which will hopefully start to bring about change in how developers are perceived.

We overcame some early team friction, and in the end we jelled very well. I feel like I've made some new friends during this project who were just coworkers before.

We had a good up-to-date schedule thanks to Joel's spreadsheet (I've even been asked to give a brown-bag presentation over lunch to our division), but the original estimate wasn't exactly realistic. The problem always boils down to not knowing enough about the scope of the work at the time we submit a bid for the project. We aren't given a cushy business development budget to really nail down a scope prior to bidding on it, and frankly, our client likely would have been put-off by us if we tried. When I originally priced the project, I came up with $92K. The business analyst who knew the customer well balked at that figure - unfortunately, he is a business systems analyst and doesn't know by experience what goes into a software project - so I cut the cost down to $62K by making some major assumptions. In the end, the project cost about $75K, and we were able to ask for the extra $13K from the client due to out of scope requests; it remains to be seen if they'll actually pay us for it though. I now regret having bent to the pressure to reduce the original estimate. I think it would have been spot-on for a quality web site that was well debugged. Instead, we produced a fast and cheap application that sacrificed accuracy.

We had a problem with entangling priorities. I was being pulled in two different directions by critical dates on this and my other project. I don't think its realistic to expect to focus on just one project in my line of work, but I can't avoid saying that dividing focus does reduce quality.

The spec documents were a big hit - we wrote them with a sense of humor that was a welcome change for our readers. The clients and the project manager all appreciated the specs, and it was obvious that they actually read them in entirety.

The end product is finished, and I'm glad to be moving on. Getting closure is one of the benefits of a quick job, and if you've ever been unfortunate enough to work on a job that drags out indefinitely with constant scope changes and no schedule, I'm sure you appreciate closure, too!

Thanks for all who have read and commented on this series. I hope it has been an entertaining read - it was fun to write. I'll be switching back to a more technical style for a while, but I may revisit this novel-style periodically.

Beta max

Part five of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

"Can we add a link for Trip Reports under the Correspondence section?" Brett, our client on a small web application project, asked during the alpha demonstration.

"Of course," was my gut reaction, "Do you want it below the link for Meeting Minutes?" And with that, the scope crept incrementally.

Overall, the alpha demonstration went very smoothly. We used Live Meeting to share our desktop with the client, which worked great, even through the firewalls. Brett was happy with the progress we had made in short order, and besides the few new features they asked for during the demo, we were right on schedule.

Those few innocuous-seeming feature requests, though, would be starting to threaten our deadline if it weren't set in stone - instead, usability and quality will take a hit, or other features would be dropped. I was using a variation on Joel's schedule tool that included release version, and a column for date added, and one for notes on scope creep.

After updating the schedule, it was obvious that we had more features than we could finish. What should we do? Cut features? Skimp on quality? Add more developers? From cheap, fast, and good, we needed to pick two. Robert decided to call the client and ask what their preference was. We knew they had some money in reserve for contingency. Meanwhile, we'd finish the core features.

Continued next week...

Down to business

Part four of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

It was Monday, and I was finally starting to feel at peace with my job and personal life. Friday's confrontation with Robert ended amiable enough with an agreement that we were basically on the same page; the problem was that we didn't know each other well enough yet for trust and understanding to develop. Even the confrontation started building our understanding of each other and brining us closer together as a team instead of driving a wedge between us.

I took the elevator up two stories to the fifth floor where Robert's office is, and waited for him to finish a phone call. While sitting in an adjacent common area staring at a wall-sized white board scribbled with notes, I took stock of my feelings. Although I had harbored waves of viewpoints taking me from angst for my career, to self-righteousness, to apathy, and back again over the weekend, I had finally found the calm of melding them in appropriate proportions.

"Are you finished?" I asked, as I stood in the doorway. Robert had just finished one call, but had a dial tone buzzing out through the speaker phone.

"Sure, come in, I will just be a second," he replied as he dialed a number and had a gave an answer to someone on the other end before promising to call back later.

I had come up to discuss the plan for brining in two developers from the Portland office to help out with the DTX and CPUD projects. Before we got into that though, Robert tested the water with his toe, "I just wanted to say that I think you guys are doing a great job on CPUD. I think we will cut into our profit a little on this job, but instead of asking for the extra $12K," money that we knew they had in contingency for the project we were working on, "I want to show them our integrity and not grab that cookie, even though I think they are waiting for us to do so."

I nodded and agreed. "I think we can really show them what our IT department can do on this project," he continued. "They've worked with our company's other departments, but this is the first experience they've had with us, which is why I want to impress them by brining this project in on schedule, too."

Understanding the undertone referring to last Friday's conversation about working overtime, I answered to his meaning, "Yes, I've been thinking about that. I think the reason I was so upset was because you were asking me to enforce your schedule," a schedule that I had objected to during our internal kickoff meeting as way too tight, "If I made the schedule, I would feel more comfortable asking people to stick to it," as I said this I wondered if I would ask people to stick to my schedule even if it meant overtime, and realized with a tinge of disgust that I would; the difference being whether I had bought into the schedule or not. "I think since it's your schedule, you should ask the developers to work overtime."

"Well, it's not my schedule either," Robert replied with a chuckle as I remembered he was right. Robert had been brought into the project after that schedule had been set by the client and to a lesser extent, our analyst who closed the deal. Feeling somewhat sheepish, I acknowledged that it wasn't. "But I understand, and I will ask them, no problem."

"Thanks," I said, "I realize now that it wasn't your schedule; I'm sorry that I had forgotten that it wasn't. Now, let me fill you in on Janet and Jon from the Portland office."

We talked and decided that Janet wasn't needed to help out on DTX; instead, I would finish the project myself and Jon from Portland would stay this week to help Ryan out on the CPUD project while I stayed on the periphery to answer questions.

I was relieved with how everything shook out, and headed back down to the team room to get to work on completing DTX. About a half hour later, Robert did come down and talk to Ryan and Jon about working overtime, and somewhat to my surprise, they both seemed eager to do it.

The rest of the week went very well for both projects. Ryan, a brand new employee at our company, had shown he could work independently and efficiently. He wasn't one to pester me with trivial questions; instead he had shown he was perfectly capable and competent to make all the little decisions that are necessary to bring a web application into being, from choosing colors to deciding the best way to implement a feature.

Jon showed a quiet and understated personality. He would ask probing questions like, "Do you want a person to be able to belong to two organizations?" And I'd start out answering, "Yes, some people may work out of two offices, which will each be treated as their own organization," and then sometimes I'd realize what he was getting at, "Ohh, I see, but then we'll need to do multiple templates for each," or some such realization, but usually he would then shine the light in on the problem.

On Robert's suggestion, I brought in some Krispy Kreme donuts one day for the crew, which were a nice perk for all of us. The next day, the guys gave me a coffee order and I went down to the café to get them their drinks. After that, I considered it a standing order and filled it every morning on my way to the team room.

Our team was really starting to jell, and the projects were both benefiting from it. By the end of the week, we were well prepared for the Alpha demonstration scheduled for the following Monday. We would use Net Meeting to do share our desktop with the client and walk through the application to get their comments.

Continued next week...

Alpha blues soup

Part three of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.


To: Rusty/SEA
From: Robert/SEA
Sent: Fri Oct 21 08:35:20 2005
Subject: RE: Just when you thought it was safe to go out...

I will be in late this morning (about 9:30), and will drop by. Can Angela get started with training docs?

R


---------------------------------
To: Robert/SEA
From: Rusty/SEA
Sent: Fri Oct 21 07:38:44 2005
Subject: RE: Just when you thought it was safe to go out...

Robert,

Thanks for the update.

Jon’s already got things to work on, I’ll check in with him to see how he is progressing.

I called Janet up and she won’t be here until tue/wed since the Portland office is doing its move over the weekend. She also told me that Andre and Lara implied there were many fewer hours than I said there were to do; and she surmised that because her billing rate is high, the PM on the DTX project might not let her actually charge that many hours to the project.

When Ryan gets back, I’ll let him know that he’s cleared for overtime on the CPUD project, but I will not cajole, coerce, or request that he actually works more than 40. Just to be clear, I am steadfast against it because it is the quickest way to demoralize and burn out a great worker and I do not want to lose Ryan. To me, employees and their families come first, clients come second.

It's probably never a good career move to tell the project manager to unceremoniously stuff it when he or she starts hinting at the need for overtime in order to meet a tight project schedule, but it was Friday and I was wiped out from a stressful week of balancing priorities and realigning my goals between the two projects I was working on - DTX and CPUD.

The undertone of Robert's reply was clear enough to me - I was going to get a talking to about being a company man. "Great," I thought sarcastically to myself, "now I won't be able to concentrate on the DTX synchronization routine until I have this confrontation with Robert."

The CPUD project was going as smoothly as it could. We had just delivered the bare-bones functional and technical specifications documents (with a little help from Joel), we had already started programming a few of the modules, and had the user interface mockup ported to HTML and CSS. The project team room was working out beautifully; our development team had great productivity and communication.

The problem was my other project, DTX, had about 45 hours of work that needed to be done for final delivery, and I was the only developer who had worked on the 500 hour project. If I put all of my attention into finishing it, it would only take me a week, but if we brought in another developer to finish it, it might take twice that long.

The plan hatched between the PM's of the two projects was to bring in Janet, a thoroughly qualified developer from another office, to finish DTX while I concentrated on CPUD - sort of an "architect" role on both projects, directing the developers and pitching in. So, I went from being excited to be finally wrapping up DTX, a project I came to feel ownership of after putting in so much time, to having some ambiguous "architect" role where I wasn't explicitly responsible for any particular thing, and didn't really have ownership of anything. Blech.

Soon enough, Robert came down to the team room. I was there alone at the time and wishing I had a witness to the upcoming confrontation.

"Let me start off by saying that I agree with you that employees families come first," he started sincerely. "I am not a slave driver, and I don't intend to force anyone to stay at work for long hours. I understand that a lot of companies do just that, and I am glad that this company has not shown any signs of strong arming the employees into long work days since I have been here."

"I appreciate that," I said as I tried to release the tension from my muscles that were geared up for fight or flight. "I just wanted to make it clear that I am not going to be the one to ask the team to work late hours. I don't believe in doing that, it is a very slippery slope" my voice grew a little husky to my embarrassment, "and this is an emotional topic for me because I have been through this scenario myself of being overworked, and I have seen it happen to my coworkers, and it is never worth it," my explanation was starting to turn into a plea, so I cut it off there.

"At some point in your career, you are going to have to ask people to work overtime," Robert reasoned. "It doesn't have to be you telling people to work overtime, you just have to ask; they can say no if they want. I don't want you to be here being the lone horseman bringing this project in on schedule because you don't want to ask anyone to work overtime."

My body went a little more rigid at his attempted persuasion to get me to do something I was obviously unwilling to do. As I gripped the armrests of my chair, I lost my cool somewhat when I retorted, "Let me be perfectly clear here; I am not going to be the lone horseman. I don't care if this project goes down in flames; if I take the wrap for that and get fired, then fine. I'm smart. The market is very good right now." I considered telling him about the two other open offers I had that I could always turn to, but decided not to show all my cards. "I can always find another job." I stared him down; a bit crazed still, like a horse backed into a corner.

And then the thing happened that in retrospect, however petty, made the whole confrontation worth it. Robert reached into his pocket, and without breaking eye contact, pulled out a blister packet of Nicorette gum, peeled back the foil, and popped it in his mouth.

Continued next week....

Team Friction

Part two of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest. (Part One).

Robert held his key card to the electronic light of the entry door to the third floor office space. The light greened, and he opened the door while gentlemanly holding it for the team to pass through.

We were working on a project to develop a web application that managed documentation related to contracts and communications for a regional power utility district. The team consisted of Robert, Project Manager; Ryan, Developer; Angela, Graphics/Usability; and myself, Lead Developer. The client had requested a six-week final delivery schedule to coincide with opening their next big project using the web application. A break-neck project to be sure; six weeks to gather requirements, develop an interface, code, and document; forget about time for testing. Registering my complaint about the over-ambitious schedule at our internal kick-off meeting fell on deaf ears, but at least it was on record.

As we crowded into a short hall, Robert squeezed passed us to show us into our team room. "There are three keys;" he explained, "I'll keep one in my desk. Rusty, you take this one, and I'll give the other key to Angela. We need to make sure not to lock ourselves out of this room or we'll be in trouble!"

The team room was impressive. One entire wall was windows looking out on the courtyard. The mahogany conference table comfortably sat 6, and occupied the main space. There was a large white board on one wall, and several individual desks against the interior wall. "Don't tell anyone down here this is only a $70,000 project, now," warned Robert, putting his reputation before the team.

As we sat down at the table, I took a seat at one end while others sat on the sides; a habit I had noticed of myself in the past, and one my modesty is not proud of. As we sat looking at each other, it quickly became apparent that it was unclear who should be leading the meeting, a problem that was already recurrent.

The problem first became apparent the previous week when Robert, Ryan, and I paid a visit to the client for what was supposed to be a week of meetings and requirements gathering to jump start the project. The first day was chaotic; the six-member client team was reduced to debating insignificant details amongst themselves, but at least had shown a lot of interest and willingness to participate. At dinner that night, the three of us mulled over the plan for the next day.

"Today we got some good ideas about how they want their unique document numbering system to work, but I haven't gathered the information I need to actually write a functional specification," I said between mouthfuls of BBQ chicken. "Tomorrow, Ryan and I need to corner two or three team members at a time and get them to walk through how the system will be actually used. How are projects added, archived, and managed." I was reminding them of the agenda I had forwarded to Robert at his request for this week's meetings, and which he had passed on to the client.

"I'd really like all of us to meet with them again in the morning and go over all the questions we have from today's meeting. I think Brett (Client Project Manager) had a few more things he wanted to talk about," Robert replied. "I really want to go in there tomorrow with a clear list of things to do, questions to ask, so that we don't get off track. How about, after dinner, we meet to get everything laid out and typed up for tomorrow," he stated, rather than asked.

And we did just that; we came up with a list of questions to ask the next day, but I was still sore that I wouldn't get my agenda complete. I worried that I wouldn't have the information I needed to figure out how the site was supposed to work.

The next morning when we reconvened, things went from bad to worse for me as the precedent of unclear leadership was set. As we sat at the table for the meeting, Robert handed me the list of questions and started telling me how to lead the meeting. He imposed the responsibility of leading the meeting, without any ownership over the agenda, and it made me feel a little uneasy. Nothing to get too upset about, but a flag was raised in my mind that something didn't feel right about this.

As the meeting started, I asked Brett if he had anything to discuss leftover from yesterday's meeting, and he looked at me blankly and shook his head. "Ungh," I thought, "I should have questioned Robert's assertion last night when I wondered what he was talking about."

"Why don't you group your questions concerning each web page, and we can walk through them that way," Brett suggested.

"Crap, we didn't organize them like that, now I have to scan this two page list and try to ask them in an organized manner." I thought. "OK, let me just scan this list for the first set," I replied lamely.

At that point, Robert interrupted and took over with his own line of questions, and we fell back into the previous day's arguments over the unique document numbering system.

After two hours of debating, my face was showing my disgust, which Robert interpreted as impatience with himself, but which actually was the feeling of powerlessness over getting the information I actually needed.

"I don't think we have time to get into that subject," I tersely replied to Robert, somewhat under my breath, as he suggested opening Pandora's box 10 minutes before the client team had said they needed to break for other meetings. He opened it anyway.

Fifteen minutes later, we had successfully closed the box, and he was ready to go open another one. "No, I don't think we should talk about that now; it's already past 10, and Brett needs to get to his other meeting," having lost my patience, I clearly stated this while glaring at him. "We will adjourn now, and while you go and read the contract with Sam, Ryan and I will interview Renae about how the site will actually work."

After the room cleared out, Robert apologized a few times for taking over the meeting, and I felt silly for losing my cool. Besides, I was happy that I finally caught a break and would get a chance to talk to a client about functionality.

Our interview went spectacularly! We learned so much basic information about who would administer what, how security roles worked, what Renae expected each page to do, and how the work flow would proceed, including email notifications on certain events.

"That was what we needed to do that whole time!" Ryan cheered gleefully after the interview.

"Man, I know! That was great." I agreed, feeling vindicated.

The afternoon went well as Robert was still absent, so I was clearly the leader of the meeting. Even with the whole group back, we stayed on track and got through a lot of information.

That night, Ryan returned to the home office 150 miles away, as did Robert. I was staying at the client site to write a draft functional spec the next day, and then planned to reconvene the following day when Laura was scheduled to visit for usability interviews. I got an email reading that Laura had a change of plans due to personal reasons that required her to be replaced on the project by Angela; neither would be coming out. I decided to keep working anyway, and to present the draft spec in a couple of days. Then, my laptop HD crashed. Shoot. I didn't loose any work thanks to backups, but I decided to pack it in and go back to the home office; it seemed fated.

It turned out to be two days of meetings instead of five after all; funny how things work out sometimes.

Continued next week...