wandercoding.com

When I meet new people, they inevitably ask me what I do for a living. I usually tell them that I write software (when I tell them that I rob banks, they often don’t believe me). Some people understand what that is and some don’t. It’s like the t-shirt I’ve seen that says, “There are 10 kinds of people in the world – those that understand binary and those who don’t.” The ones that do understand software might ask me what kind of software. The others just say things like, “You gotta be smart to do that.” While that should be a prerequisite for writing software, it’s not universally enforced, and thank goodness for that because some days…

Now, when I get in longer conversations, I also tell people that I’m writing a book about software – more specifically about software career related items (a lot like this web site, and no, it’s not just a collection of the blog posts contained herein.) A while ago, it occurred to me how similar writing a book and writing software are.

Creating an outline for a book is like planning the features for your software. Writing the text of a book is like writing the software. You even get syntax highlighting (spelling and grammar mistakes) pointed out by your integrated development environment (Microsoft Word, Star Office, WordPerfect, etc.) QA and bug fixing comes in the form of proofreading. Beta testing comes when you get other people to read what you’ve written and see if it’s logical, solves their problem(s) (even novels solve the problem of boredom or provoking thought), or provides a proof of concept. Then, when you’re done, you have to try to sell the book/software. Books, however, have traditionally been first sold to a publishing house, which is supposed to weed out the unpublishable. This is not a flawless plan, however. Some books are published that are boring as h**l and practically useless. Classics such as Jonathan Livingston Seagull, Lolita, and The Diary of a Young Girl (Anne Frank) were rejected by numerous publishing houses. Software used to have a similar avenue of distribution – you’d have to find stores to carry your software or advertise it in magazines and catalogs that catered to the end-user crowd.

Nowadays, publishing software is easy – just post it on your website for download. Book publishing has easy alternatives, too. Print on demand technology allows writers to bypass traditional publishing houses as does electronic publishing. In both books and software there is risk. Both require commitment, belief in what you’re doing, and a desire to overcome obstacles. The results are almost always unpredictable and what keeps life interesting and exciting. More to come…, wish me luck, buy the book (when it comes out in a couple of months).

Here are a couple of definitions for you. According to the Merriam Webster dictionary:

Strategy: noun, A careful plan or method.

Tactic: noun, a device for accomplishing an end.

These definitions work perfectly for talking about software management. When I was a manager a few years ago, some of my colleagues told me to stop worrying so much about the tactical and start worrying about the strategic. First, I had to stop and think about what they were driving at. As a software engineer turned manager (without much training in management), my approach was often to keep an eye on the code, what the people were doing with it, and how they were doing it. I was very good at helping solve problems that arose, coaching developers, adding some code occasionally (when I had time), and understanding what we were developing and why. For most engineers who move into management, this is perfectly normal and can be very effective. This is tactical thinking – what steps do we take to get from where we are to were are going.

What I wasn’t as good at (at least not then) was taking a step back from the day to day activities and looking at things as a whole. Do we have the right tools? Are our goals clear and correct? Are there more global changes to be made, such as schedule changes, personnel changes, feature scoping, etc.? Sure, I was good at some of these things, but not all the time. I would often get my head buried in the day to day operation of my group and not take the time to step back and look at the big picture. Looking at your overall goals is strategic thinking.

One thing I believe is lacking in many organizations (certainly in the places that I worked) is quality management training. Yes, I took classes in the legal aspects of management, how to develop a schedule (fine for waterfall methods), and how to communicate effectively. However, so much of management is fuzzy, and some new skills are required. How much time should you spend on various activities? What is your priority as a manager? What’s the best tool for scheduling and how to use it most effectively (MS Excel, MS Project, Rational, Visio, something else)? How frequently should you meet with your team members, colleagues, and manager? What’s the proper proportion of time to spend on various management activities? For example, some managers spend so much time in meetings, they never learn anything about your software and never know what is really going on. Then they’re surprised at inconvenient times to find out what the actual situation is.

In future posts, we’ll address some of these things. For now, whether you’re in management or not, take a step back and take a look at what you’re doing. Stop worrying for a minute about your current problem and ask if you’re even solving the right problem. Are you worried about the tree when you should be thinking about the forest?

For the past few years, I’ve been playing fantasy football. If you’re not familiar with the concept, you join a league with some other people, pick a name for your team, and then draft players from the NFL. There’s an order for picking players based on your record from last year and each NFL player can only be chosen by one team owner. Your score for each game against another team (usually one “game” per week) is based on the yardage and scoring that your players contribute to their real NFL teams.

I’ll be honest – I’m a pretty good owner. I’ve won the title once and come in second twice. My success is based on a sound strategy:

1. I pick as many good running backs and wide receivers as I can early because they tend to score more points on a weekly basis.
2. I pick the best player available at the time. The best player available is determined by what is recommended by a couple of sources (magazines and web sites) as I figure that they probably know more than I do.
3. After each week during the season, I look for trends in the past couple of weeks to see if there’s an undrafted player who is really producing that I can pick up and I drop one of my non-producing players.

One of my opponents in the league follows a different strategy. He arms himself with all of the same kinds of data that I have. Then he follows hunches and drafts players way too early (when they will probably still be available in later rounds), thereby wasting his good picking position. He ends up with a good picking position (much better than mine) because he’s always finishing in the bottom half of the league. So, not only does he have a bad strategy and bad results, but he never seems to learn from his previous mistakes. Of course, luck is involved in this game. Injuries will take your best players out for weeks or even the whole year. The best running back in the league will have a crummy offensive line and get nowhere. The NFL coach will let your running back do all the yardage work and let some guy come off the bench to score all the touchdowns. However, even with all of this, a sound strategy, a good bench, reacting to the situation, and contingency plans can keep your team in the playoff picture.

After draft night last weekend, I got to thinking how similar this was to my last product at a former company. Every release we would get a feature set, spend a couple of months designing the features, do estimates based on our design, argue over the validity of our estimates, and end up with a feature set that just fit into our time allotted. The end of the development cycle would come up right at the end of the year, just before the holidays and the week off we were supposed to get. The end of the entire release (bug fixing time) would coincide with the company’s flagship product which we were supposed to ship with. In other words, we were set up to work under stress with little margin for error. Inevitably, we would start to run behind, have to work through the week off during the holidays and go through a death march, working nights and weekends, for four months until we shipped. We had a bad strategy, poor contingency plans, and never seemed to learn from our previous mistakes. Before the next release, we’d say, “Well, we’ll just have to do a better job designing and estimating this year.” It’s a classic waterfall development cycle without any room for error, and no contingencies built in.

In previous products, we might use the waterfall method, but when time was running out, we’d be able to drop a feature to keep the release process sane. In any software release, you have the three main variables built in: time (including people, so person-hours), quality, and functionality. Things work best when there’s flexibility in the quality and functionality parts. The powers that be usually don’t like to ship extremely buggy software, so there’s only so much flexibility on the quality end. If you aren’t willing to drop any functionality, you expand the person-hours. Given that you usually have a set team size (and don’t forget that adding people to a late project doesn’t usually help) that means simply working more hours. As appealing as that sounds to upper management, especially those who haven’t written software in years, working tons of overtime doesn’t help as much as you might think. The garbage that gets written after you’ve been working for ten or twelve hours in a day is truly staggering. I frequently came in the next morning wondering what on earth I was thinking when I wrote that code or fixed that bug the night before. Essentially, I wasted hours of my life and didn’t help the project any.

If your release cycles are going the same way, take action sooner than later. Be willing to drop functionality as the release falls behind (lots of features are extraneous “nice to haves” not “need to haves”). Use a different release cycle process – will an agile process work where you are? Push the ship date back – many (but not all) ship dates are simply chosen out of thin air. When you push back at management or marketing, sometimes you’ll find that these dates really are flexible. The worst thing is to keep making the same mistakes over and over again. Can you get better at designing and estimating? Sure you can. Will it ever be perfect? Unlikely. Do some companies succeed this way? Sure. Has yours? Chances are that it hasn’t, which is why you’re still nodding your head as you read this.