wandercoding.com

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.

In Steve McConnell’s excellent book, Rapid Development, he talks about wasting time during the fuzzy front end. This is the time of a project when you’re waiting for the new specifications to come from product design or marketing or whoever does the up-front design work for your product (or web site, etc.). After a release, especially an intense one, it’s natural to need some slow time. Keeping up a high-intensity pace on a permanent basis leads to rapid burnout, which isn’t very productive in the long term.

So, what can you do and what should you do? Here are some ideas for you next time you run into this time period.

• Clean up time. Go through your code and find all of the crappy stuff you wrote because you didn’t have time to think it through clearly. Rewrite it the way you really should have.
• Fix up the buggy back end. How many bugs didn’t you fix at the end of the previous release? Now’s a good time to fix the low hanging fruit or the ones that seemed too risky to attempt just before release.
• Design time. What would you like to see your system structured like in the future? Can you design it differently to accommodate the expected feature set? Will some new designs make it easier to add new functionality?
• Toolkit time. Do you have a lot of semi-repetitive or duplicated code in your system? Is it time to take these routines or classes and create a toolkit from them that can be called by the rest of the system?
• Prototype time. As long as you don’t get too possessive of your new code, can you develop a small prototype for some expected new functionality? If you do, show it to the designers and see if it affects their thoughts on how something might look. I have long thought that the developers of a product can make excellent designers if consulted early and often during the design process. Are your developers actually the designers of your product? Great, but having someone be the overall supervisor of design work can make your product more consistent from a look and feel standpoint and can coordinate possibly redundant development work.

The fuzzy front end doesn’t have to be a waste of time. Your developers can be more productive if they have a clue of what might be coming and what’s expected of them. Making sure that they know that possible functionality isn’t cut in stone will help ensure that time and effort isn’t wasted on completed functionality before the details come out. Setting some clear goals for the fuzzy time can help keep them focused on using the time to their advantage and keep them from going crazy while waiting for the action to begin.

About 15 years ago, I worked for a large engineering software company. While I was attending one of their corporate conferences, I met John, who was instrumental in the development of one of their products. He told me a story about the beginning phases of their new product when they were making architectural decisions. Back then, memory wasn’t the commodity it is now. The product ran on UNIX workstations and you had to be far more conscious of memory consumption and data structure sizes than most applications do today (although we might all be better off if people gave it a bit more consideration). The product worked with Finite Element Analysis (FEA) for analyzing mechanical and structural designs. As you might imagine, this kind of mathematically intensive work could use a lot of numbers and the precision of the numbers would affect both speed and accuracy of the analysis. John was adamant that double precision was required for accuracy, but was overruled by a manager, who was not technically oriented. Months later, when the analysis results were proving to be inaccurate, someone asked who made the precision decision. Someone blamed John, who was understandably quite livid about being blamed for the decision he had fought against.

A few years later, I was working on a solid modeling product for architects. I was mentoring a colleague, Sharon, in the ways of solid modeling and general application development. In order to do some of our calculations, we were using a vector class created by our graphics guy. As such, the vector math was being done in single precision as that’s what was common practice for graphics. As you might guess, when some of our modeling operations came out poorly, I asked Sharon to convert our code to use a double precision vector class. She was sure this was not the problem, but as I was the project leader and her manager, she did it anyway. Lo and behold the problems disappeared and she learned a valuable lesson.

Perhaps you, too, will have to make some decisions like this in your software development. Before you jump to conclusions, especially when it comes to something that’s fundamental to your product, do some experiments on size, speed, and other measurable performance. Err on the side of flexibility, if all other parameters are equal. If your language supports creating your own data type (such as a C++ typedef), you can delay the decision and change it later. If you believe that someone in your group is making the wrong decision, say something. Be sure to say it nicely, but say it and record it for future reference. When the fecal material hits the rotating air circulation device later, and someone picks you as the scapegoat, you’ll be able to say you did what you could. Better still, however, is to prevent the mistake by proving that the decision is incorrect by backing it up with hard data and keeping it objective and not personal.

If you read my post Truth In Advertising, then you know how much I “love” commercials. Advertising is about what you say and don’t say. For example, there are two current commercials that feature bits of songs. The first is a cruise line that plays “Lust for life” by Iggy Pop. They only play the part that says, “Here comes johnny yen again, Got a lust for life, Yeah, a lust for life.” But, that’s only part of the song and actually it’s a mash of two different parts of it. You can see the complete lyrics here: Lust for life. I’ll give you a preview:

Here comes johnny yen again
With the liquor and drugs
And the flesh machine
Hes gonna do another strip tease.
Hey man, whered ya get that lotion?
Ive been hurting since Ive bought the gimmick
About something called love
Yeah, something called love.
Well, thats like hypnotizing chickens.

Why don’t they play that part? Or how about another commercial that plays R.E.M.’s “I am superman”? They play the part that says, “I am superman and I can do anything, I am superman and I know what’s happening.” But, they leave out the next lines:

You don’t really love that guy you make it with now do you?
I know you don’t love that guy cause I can see right through you.

I am I am I am Superman and I know what’s happening.
I am I am I am Superman and I can do anything.

If you go a million miles away I’ll track you down girl.
Trust me when I say I know the pathway to your heart.

I can’t imagine why.

Clearly there are reasons to leave this stuff out of their ads - mainly, they don’t add to the message they want to send. Let me tell you another short story along similar lines, this time related to software. A friend of a friend sent me his resume so that I could point him to some local companies that matched his skill set. Before I did that, I felt compelled to point out a few things about his resume - the main thing being that it was blatantly obvious based on his college graduation date that he was over 60 years old. While age discrimination is illegal, can you prove it if you simply don’t get called in for an interview? Heck, I’ve sent my resume to job listings that practically say, “Bill, this job is tailor-made for you” and never received a phone call.

So, my response was: remove those dates. If he managed to get an interview based on his skills and experience (the important stuff), then someone was bound to notice that he was, shall we say, life experienced. However, he’d have gotten in the door and could then convince them that he was the right person for the job. There’s room on your resume for what you’ve done right in your career. There’s no need to add what you haven’t done right and no need to supply detail about things that are detrimental to you being hired. Your resume is your own advertising brochure and the lyrics to the song about your own life. (Does that sound corny or what?) It’s dishonest to change they lyrics from programmer to CTO, but it’s not dishonest to remove a few details that may prove unflattering. For example, let’s say you got fired from a job a few years ago. Is it dishonest to not put that on your resume? Of course not. There’s no precedent for putting reasons for job departures on your resume. Similarly, while dates of employment may be important to have on your resume (employers are wary of gaps), there’s no reason to let people age you and it’s illegal for a potential employer to ask you your age.

Polish up your personal brochure and have a couple of friends in the business look it over with a critical and constructive eye. Nobody’s resume is perfect, but it should be the best advertisement you can make for the best product - you.

We are living in interesting and confusing times. Gas prices have skyrocketed, home prices are dropping, foreclosures are increasing at an alarming rate, and our fearless leader seems to constantly side with big business over the common guy with a problem. There’s only one thing to do - take matters into your own hands.

For example, let’s say that your company has laid you off or looks like they might do so. You have choices to make. Do you want to be the last one out the door and try to hold on as long as possible? If so, it’s time to prove or remind your boss that you are key to the continued success of your company. Sometimes, however, things are beyond immediate control. If your entire division or group is about to be let go, then convincing your manager that you’re the best developer on your team is pointless. So, what’s the plan.

Any job change is a chance to evaluate. You have the opportunity to evaluate what kind of work you’re doing, what you’d like to be doing, where you live and would like to live, and what aspect of the business you’re involved in. This is a great time to be purposeful, not rash. Unless things are extremely tight financially, you don’t have to accept the first job that comes along. Consider whether you’d like to change the kind of software you’re developing or the industry it serves. Have you been writing embedded military software? Would you like to try commercial off-the-shelf instead? Are you a web developer and want to try writing financial software? Try to find someone who does this kind of thing and have a talk with them about your qualifications and their assessment of their industry and your suitability to it. Make connections through linkedin.com or another networking site.

Finding another job is your new job. Plan your attack and your day around this. Do research on your city or another that you might like to move to. Find companies that you might like to work for. Use corporate web sites in addition to careerbuilder, dice, or indeed.com (a great local company search engine.) Spend time every day doing some research on new possibilities. Chech web sites, newspaper want ads, and your people connections.

Make your resume shine by having some other people critique it. It’s never quite as good as you think it is and can always stand another opinion. Keep in mind that several people will have differing opinions. Use some web sites or books for good examples and ideas to improve your resume.

Inside connections, not Human Resources, are your best ways to enter a company. Use your people network to find someone inside the company that can check internal job boards and put your resume on the hiring manager’s desk. Few things are more hopeless than adding your resume to the electronic stack of an online company job site.

Take your time, evaluate what you want to do, reflect on your desires, but don’t get lazy. It’s easy to get complacent at your job and get surprised by a massive layoff. Keep your eye on the corporate bottom line and listen to the tone of your CEO’s statements (especially the internal ones). If your company is listed on a stock market, dropping prices are a sure sign that layoffs could be on the CEO’s mind, even if your company has a history of never having them. Every time you change jobs you have an opportunity to learn something new, find a better place to work, add new experiences, and meet more great people. Job hunting stinks, but it’s a job you’ve got to do once in a while. Make it a rewarding one. And when you land an interview, be sure to read Pimp My Salary for getting your best offer.

I just returned from a trip to Memphis to visit friends. We spent the first few days downtown at an excellent hotel, the Talbot Heirs Guesthouse. Downtown Memphis is very walkable and if you don’t feel like walking you can just take the Main Street Trolley. The people were friendly and accomodating just about everywhere we went.

The interesting thing about the town is that it has been up and down. At one time, downtown was vibrant, but underwent a decline beginning in the 1970s. There are numerous empty store fronts, deserted blocks, and panhandlers roaming the streets. But, there are many historic and beautiful buildings. There are rental properties advertising condominiums. And there are some fantastic restaurants. The famous Beale Street, home of the blues, is right downtown, along with the Gibson guitar factory, an NBA stadium, and a minor league baseball stadium.

Now, the question is: if you build it, will they come? There’s little difference between this and software. If you build a website, will people visit? Will you make money actually selling something or by advertising on your site? If you build software, will people buy it? How will you market it? Will you pay to advertise on web sites, in magazines, or at trade shows? Like anything else, things take time. Patience is important, but so is constant action to improve the likelihood of success. And once success has been achieved, never stop trying to improve. The competition will always be after you. Don’t have any competition? If you’re successful and have proven that there’s a market for what you’re doing, the competition will come.

I like reading other software blogs as much as writing my own. My big advantage so far, is that I don’t tell people how to write code (yet). Why is this an advantage? Because, so far, I’ve managed to avoid the wrath of the Perfect Programmer.

Who is the Perfect Programmer? He’s (or she’s) the one who responds to the blog posts with things like: Don’t let Jeff Atwood Lead Your Web Project or corrects silly bits of code on code postings, where the correctness of the code example doesn’t matter because it’s only for illustrative purposes.

Fortunately, in my career, I’ve only run into a few perfect programmers, who have commented on my code without tact. My code is far from perfect (even perfect programmers write crappy code), but most people who have commented on it have at least done so constructively. This brings us to my real point for this post.

Criticism is a dish best served warm (as opposed to revenge, which we all know should be served cold - it must taste like gazpacho). I’ve found it best to approach someone in a more questioning manner, asking someone to explain what they were trying to do first. After all, is it possible that you misunderstood the intent of the code or the design?

In a previous life, I worked with a guy who was a good coder, but could be a bit on the testy side. He had added a new feature to the API that was very useful, but would be difficult for users to interact with. A couple of people told him so and he became very frustrated with the criticism and insisted that it was perfect as is. I was asked to talk to him, so I went over to his desk and asked him to show me the new functionality. He told me about it and showed me the code that a user would have to write. There was one piece of information the user would have to supply that wasn’t obvious to me, and therefore users as well. I simply asked him to tell me about what the user would have to do to get this piece of information. Once he started to explain it, he stopped in mid-sentence. He said, “I can see how I can make this whole thing much simpler,” and he did. He changed the code and it was very clear and much simpler than the original. I had gotten him to criticize his own code.

Along the same lines, this is one reason why I always write comments and documentation on my classes. I find that once I start trying to explain what the code is supposed to do that I find out how convoluted I may have made it. Try thinking like a user when you design something. Try thinking like your colleague when you have an issue with their code. You’ll find that people will learn to trust you and accept suggestions more readily without getting defensive.

I’m not sure exactly when this started, but my recollection is that it began spreading in the late 1980’s. What am I talking about? I’m talking about a scourge that spread so quickly and has become so prevalent that it is practically inescapable in today’s world. I’m talking about redundant-speak.

It started small. People in meetings started saying things like “continue on” when continue would have done just fine. Then other people who presumably didn’t want to be left out must have come to the realization that they weren’t being clear enough if they didn’t say things twice in the same sentence. Memos suddenly needed to be “distributed around” and “circulated around”, when distributing or circulating them would have been sufficient.

With the price of words skyrocketing, it should be clear that we need to decrease down the amount of redundant speak (did you catch the one in this sentence?). Okay, so words aren’t really getting more expensive, but there’s still no need for the prevalence of this kind of talk. Communicating clearly and effectively isn’t difficult. Removing modifier words isn’t difficult, either. The first step is recognizing that there’s a redundancy in the first place. Next time you listen to someone speak, listen for a two word combination that describes one thing. If the description tells you two different things, then it’s fine. However, if the second word, or sometimes a supporting phrase, doesn’t add anything, then it’s redundant.

Once you recognize this kind of speech and writing, you can examine your own. Once you start removing the redundancies, your communication will be clearer and more direct. Try not to revert back to your previous behavior (did you catch “revert back” when “revert” will do?). Help remove redundant speak from the world until it’s totally abolished.

For a nice list of redundancies, check out: http://kcweb.nhmccd.edu/employee/jsamuels/redund.htm