That's the Way the Cookie Crumbles
I have heard people talk about "baking quality" into the software, as opposed to finding and siphoning out the defects at the end. That certainly makes sense, but this whole baked-in thing became clearer to me after a recent experience making some bad cookies. How can cookies be bad, you ask? Well, if someone puts too much salt into a single batch--say, a tablespoon rather than a teaspoon--cookies can, in fact, be pretty bad. The visual difference between "TBSP" and "tsp" is not nearly as drastic as the palatable difference in a small batch of cookies.

In this particular recipe, that difference had a distinct negative effect on the product. Yet by the time the cookies were sampled and this was discovered, what were we to do? You can't very well vacuum out the salt at that point. You basically have to throw out the whole batch and start over, using new materials and additional time.

Sound familiar?

If only we had double-checked the recipe more closely as we added the ingredients. If only we had sampled the batter along the way. Or what if we had worked together, calling out what we were doing and giving the other a chance to say, "Wait. The recipe says teaspoon, not tablespoon" or even "A tablespoon sounds like too much salt." Maybe we could have avoided the disaster.

Of course, there were temptations to get by without actually having to make a new batch, because by this time we were low on flour. For instance, we thought about covering the not-so-sweet cookies with a bunch of frosting and hoping that the lavish, sweet topping would camouflage our mistake. We also talked about calling them tea biscuits or something that might imply that the flat, salty taste was meant to be sophisticated. "Ah, yes. The salty aftertaste is perfectly matched with a cup of piping hot Earl Grey, don't you think?"

I'm sure some of you can think of software equivalents to these ill-fated shortcuts.

But in the end we had to bake a new batch of cookies, using the right ingredients in the right amounts. So I will never again hear about baked-in quality without a slight craving for dessert.

For cookies that is, not "tea biscuits."

What Does Your Garden Grow?
I like gardening. I grew up with a big yard and lots of flowerbeds that my Mother tended with care. Now I putter in my own yard and make frequent trips to the nursery. It's common for me to scout out a nice spot and create a whole new bed in a weekend. So you can imagine my excitement when I moved into a house with twice the yard as my previous home. I was anxious to dive into the overgrown beds and chop out new spaces for planting.

But then a funny thing happened. Spring arrived, and I noticed some sprouts breaking through the weeds. I soon discovered I had a river of daffodils that spilled across the side of the yard. I started looking around and found a strand of irises next to one of the trees. A month later, a twelve-foot row of gorgeous peonies emerged and kept my house in cut flowers for weeks! Each season brought a new surprise, and I was so glad I hadn't started tilling. In fact, other than pulling weeds and trimming hedges, I simply let the year unfold and took stock of what my yard had to give me.

What does this have to do with software? We operate in a fast-paced world with a lot of change--job hopping, promotions, new teams to manage, corporate mergers, outsourcers to work with, and, of course, the next, best project to tackle. Sometimes it's easy to jump into new scenarios with old mindsets, armed with our own proven formulas. But in doing so, we run the risk of bulldozing some natural resources that might be lurking in the weeds. My advice: First tend the weeds, and remove other obstacles while actively observing what flourishes naturally on a new project, team, or task. Then add to the positive elements, bridge the trouble spots, and make adjustments strategically. We may still use our favorite methods to effect big change, but it'll be more productive when we do.

I'm now into my second year at the new house. I have fortified some of the existing beds, moved others, and added a few of my own design. The yard looks like I have been working on it for years. I doubt many of us have a year to wait before taking major action on projects, but I guarantee that a little well-placed observation will pay off in bunches!

"In" Season
Can you feel it? Fall is here. Kids are settled back into school. The evening air has lost its summer weight, and soon trees will begin showing off their colors. Fall has always been my favorite season. While I lived in Florida, I secretly missed those first cool nights and last fall harvests.

So what does this have to do with software? I suppose I could say, "Nothing. I just wanted to talk about fall." But I've noticed that people seem to have "favorite seasons" on software projects, too. Some people get fired up about determining requirements and creating early designs. They tend to be idea folks, and you can see them get all wound up during brainstorming or story gathering. Visit them during a code review and you might experience a very different energy. Others just love the end game-putting features through their paces, uncovering unexpected outcomes, and getting the product shored up and ready to ship.

Discovering your favorite season on a project can be helpful in two ways. First, it gives you an idea of where your natural strengths are. By aligning your role in a project with where your energy is highest, you can enhance your productivity and flex your skills. Second, knowing where you thrive can help you start to understand why other areas don't capture your energy and attention as well. If you can't limit your role in those aspects of a project, you can at least make strategic adjustments-more preparation, additional time, or just more conscious effort.

So what's your favorite season? When in a project are you most likely to feel your energy level rise? When you think through the lifecycle of a new project, is there any part that you look forward to more than others? Think about it, and see if you can use your findings to help make the most of your efforts.

Meanwhile, I'll be raking a pile of leaves to jump into or watching the marching band at a high school football game. 

Danger, Will Robinson!
Did you ever watch the show Lost in Space? It was a 1960s sci-fi series about a family whose spaceship got stranded on a distant planet. Every time the youngest son, Will Robinson, and his robot companion (aptly named Robot) got close to trouble, the robot would declare with arms swinging, "Danger, Will Robinson! Danger, Will Robinson!"

There have been many times I wished I had a personal device to warn me of impending crisis: "Danger, Pam Young! That author is about to miss a deadline!" or "Danger, Pam Young! You are about to be confronted with an irresistible dessert tray!"

Here are a few things that should set the warning bell ringing for you on your
next software project:

• Your developers say "yes" to everything you want, even though you suspect you're asking for too much with too little time.
• Your organization decides to do extreme or agile programming because there isn't enough time to gather requirements.
• You get a brand new release to test with a comment that the testing should be simple because only "a few changes" were made.
• You implement a plan to measure and reward testers by how many bugs they  ind.

These are just a few things that should trip your warning switch. Think of some others and be ready to sound your own alarm as danger approaches.

What Do they Expect?
Are you are doing the same job you were last year?

Most of the people I talk to have changed companies or positions in recent years. But perhaps as significantly, many companies seem to be changing you--or at least what they expect of you. Perhaps you survived a round of layoffs (good!) only to find you now have your old job and half of someone else's too (not so good). Or maybe you've shown such remarkable testing or development skills (good!) that people are increasingly leaning on you to create miracles (not so good).

Expectations can be a tricky thing. You want your employers to believe in your abilities. You should rise to meet all new goals and show everyone how competent and capable you are, right? Maybe. Maybe not. Over-inflated or over-zealous expectations are often a diversion from dealing with difficult realities-especially in a techie's world, where people are more comfortable discussing lines of code.

Take a moment to step back and reflect. How has your current role changed in the past year? Does management recognize those changes? If so, then you may experience some career growth from the new responsibilities. If not, then you could be enabling your organization to avoid serious staff or productivity issues. It might be in everyone's best interest to open a positive but frank discussion of where the gaps are and to make a long-range plan for handling them.

"Do more with less" is the mantra of this new world we live and work in. Taking on a few more tasks or stepping up your level of responsibility may be a great idea. But make sure new expectations are well defined and recognized by more people than just you.