Of Course I'm Done, Can't You See the Wall?

Across the street from where I work, they're putting up a large office building. We have lots of windows, so I sometimes gaze at the work going on there. Lots of big machinery, lots of people, and lots of progress from week-to-week. Sometimes, when I watch the big machinery "doing its thing," I wonder if I went into the wrong career. Nothing I do will look that cool.

I don't know anything about building houses, buildings or much at all. I did build a rabbit hutch when I was a kid. I've even put up a tent or two, though that usually required help from my wife. But, I've built software.

I was pondering, as I watched the construction of the building, how it must compare to building software. I imagined a large project schedule with all of the tasks that must be done, the dates and their dependencies, etc. I figure it must be pretty difficult to keep everything moving forward, ensuring that the right materials were on-site at the right time, etc. I started to think more about how it compares to building software.

Among other things, one of the more interesting differences has to do with the visual element. As a manager, how do you know that the software is "done?" Well, when the testing team says that it's done. But, that might be too late. Wouldn't it be nice to know from the developers when they're done building software? Of course...just ask them. But, what if they're wrong?

Though an obvious over-simplification, when building a house or even a large office building, when someone claims they're done, a quick inspection is all it usually takes (again, it's an over-simplification, as some parts of "done" are more complex than looking at a wall and saying, "Yup, I guess you're right...you finished the wall 'cause there it is!"). For software, that's not that easy. Some software is easier than others. Applications that are predominantly interface-related (i.e. desktop apps or web apps) are much easier because there *is* a visual element, though whether everything behind it is done or not is a different story.

Ultimately, testing determines whether the software meets the requirements. Newer methods of testing up-front or driving development via tests help to understand "doneness" sooner than later. Unfortunately, many projects are not that sophisticated.

Mowing Straight

Here it is, another lawn mowing entry. It seems that we learn much from our dislikes...something about what doesn't kill us makes us stronger. Well, I don't feel stronger, but it helps with the perspective.

So, there I was, mowing, again. This time, I'm pondering how difficult it is to keep my lines straight. To be honest, I'm not even sure why I bother, given that no one really looks at my lawn besides myself.

Of course, the real reason is that it means less rework, and given how much I enjoy mowing the lawn, rework is definitely something that I work hard not to do... (um, right)

So, how do you keep your lines straight? I'm certainly not going to go get a plum line or buy some laser sight or something like that. So, I do it the old fashion way: pay attention to where I'm at and where I'm going.

I noticed something, though. If I concentrated on only where I was at, to ensure I was lining up with the last line, I tended to make more mistakes. However, when I looked out a little further, I tended to do a better job of keeping the line straight.

I've found that this works with helping to keep a project moving smoothly. If all you do is fight fires and concentrate on what's immediately in front of you, you'll make more mistakes, head off in the wrong direction and lose your perspective. Keeping some view of what's coming ahead and where you want to go helps keep things in perspective and ultimately improves quality.

Lawn Mowing and Estimation

I hate mowing the lawn.

I was out mowing the other day and was pondering upon how much I dislike it. I really shouldn't hate it so much, since it's good exercise, it needs to be done, and it makes my lawn look nice (well, "nicer" would be more accurate), but I do. My pondering included thoughts of hiring a professional company and wondering how much it would cost me. I wondered how they would estimate the cost. You see, my lawn, though not necessarily large (well, *I* think it's large), is very hilly (welcome to West Virginia, they tell me).

I wondered how you would go about estimating the cost: whether by size or by time. The way I think, the biggest cost to lawn mowing has to do with time. Specifically, I would expect that it would have to do with direct labor cost (how long someone spent mowing) and how much gas was expended. For some reason, I focused on the gas aspect (given gas prices) and wondered about the best way to estimate its cost.

If you do it by size, it's pretty easy to estimate, given that you can visually estimate the size by merely looking at the yard, itself. However, if you estimate based upon the time it takes, it's easier to run into tricky mistakes. Looking at my lawn, for example, with all of its hills and crooks and crannies, you'd think it wouldn't be too hard. But, after mowing it, I found that it took a *whole* lot longer than I'd anticipated.

Programming is fairly similar when it comes to estimation, though I think the difficulty is flipped. It's difficult to estimate size, but easier to estimate time (at least for smaller tasks). Estimating size in lines of code, of course, depends a great deal on the language, the programmer, and the task at hand. Not all lines of code are created equal. Of course, there are other size tools, such as function points, use case points, complexity counts, etc. The concept is the same, but the measuring stick is different (not to suggest that any measuring stick will work just as well...hence the number of different measures). There are even complex mathematical models that use size to estimate larger projects, such as COCOMO (there are a number of commercial parametric estimation tools that use their own proprietary models).

Estimating time, at least for smaller tasks, is usually straight forward for a programmer with a little experience. But, then, that's been my experience. Time estimation for larger tasks, though, becomes much more difficult...just ask anyone who has had to fully plan out a large project using MS Project or similar tool. So, maybe it's not so different than mowing a lawn...

Either way you look at it, though, estimating helps to measure cost and effort, helping you know how much of that lawn you're going to finish before it starts raining for a week straight...

Don't Touch My Swiss Army Knife

I got a Swiss Army Knife for Christmas (okay, it wasn't a "name-brand, trademarked Swiss Army Knife, but it had lots of blades and things...it was cool). Those things are cool. They have different kinds of knives, different kinds of tools (mine even has an LED light on it!), and maybe even a cool case. They're handy to have around when you need to do some cutting or sawing or snipping (if it has scissors) or whatever. It's great...

Unless, of course, you need to fillet a fish, skin a deer, saw a tree limb off, or cut up a cardboard box for your daughter so that she can make whatever it was she dreamed up. Then...well, it's not so handy. Then you have to go get "the real tool," whichever it is for the situation.

Of course, some people who get Swiss Army Knives use it, anyway. They use it to cut up their perfectly barbecued steak, or saw that tree limb (it's only a half inch thick...), or see how far they can throw it and still stick it in the tree, or even stick it under their pillows at night (okay, okay, maybe no one uses their Swiss Army Knife for any of those things...it's funny to think so, though).

It's just not the right tool for everything, but it *seems* like an *adequate* tool for nearly anything. And that's the problem.

At least, if it's a spreadsheet. That is, a spreadsheet is the "Swiss Army Knife" of the electronic world. It can be used as a database, a word processor, a calculator...I'm sure that it could even help you do your laundry. It's great for those simple jobs. But, it's amazing how it gets used for those difficult jobs. I'm sure you've seen them: a complete implementation of a general ledger, a metrics database, a process diagramming solution, a complete ad hoc reporting tool, a form processor, or whatever. I can't tell you how excited I was when I created my first pivot table...and I still don't really know what they are!

Sometimes, when you're all alone and you have a desperate need to cut something and all you have is a Swiss Army Knife, it's like a wonderful friend who you're glad to have along. But, sometimes...well, I think you know what I mean. Sometimes, you need the right kind of knife.

You can always keep the Swiss Army Knife in your pocket...it won't get lonely.

Discipline Enabling

I've got lots of kids, so I know all about giving out 'discipline.' What I find is that, in general, it doesn't work so well. In some cases, a well-placed "correction" can go a long way, especially if the child doesn't really understand that they were doing something wrong. For example, sometimes, my kids will use inappropriate words. They may not realize that they are bad words (they're still pretty young), so when I point out that it's an inappropriate word, they don't tend to use it again. In other situations, correction doesn't work. They aren't too disciplined in many respects. One of them, which parents for many years have labored against to no avail, is keeping rooms clean.

One of the problems is that they have too much stuff and not enough places to put it. In other words, there isn't much more than just beds in their rooms (we have recently moved and didn't bring all of the furniture with us and haven't gotten around to getting more), which means that 'stuff' gets left all over the place. Not only is it difficult to expect them to keep it clean now, but they're getting in the habit of not cleaning it, which means that when we eventually get them the furniture to put it all in, it will take some time getting them into the habit of keeping things clean (I figure that their rooms will get clean when they move out of them and leave the house).

Which leads me to processes: specifically, software development methodologies and their associated processes.

One of the fundamental problems with any and all software development methodologies is the issue of getting the team to follow the process, whatever it is. Discipline, in this case, is whether the team, on an individual basis, is following the process. If they follow the process, they are considered well-disciplined. If they do not, well...they get 'disciplined' (okay, maybe not, but it sounded funny, anyway).

What typically doesn't get discussed much, which I think is a gaping hole in any methodology and a pretty big gaping hole in software development, in general, is this issue of being disciplined. I think the reason for this is that there's an expectation that, as adults and professionals, you shouldn't need to have a problem with being disciplined. And, in general, that's true.

I never took economics in college...not sure how I got away with that, but I didn't. However, I've always had an interest in finances, so eventually, I broke down and bought some basic economics books to learn a little about the topic. What I found was a fascinating thing: economics attempts to accept reality for what it was and provide some understanding around the financial side of it (please note the use of 'attempts' in that previous sentence...I'm not an economics expert, and I assume that many would not take that perspective based upon the economics classes they took). What I mean by that is that it has, at its core, the concept of incentives (it has other things as well, but they aren't pertinent to my point). Incentives has to do with motivation, decision-making, and pain (stick with me on this pain thing...). It had interesting implications for software development.

So what does economics have to do with professionals not following defined processes? And what does missing furniture have to do with my kids inability to keep a clean room? One word: enablement.

'Enable' is one of those cool words that everyone hates because it's a 'manager' word...it's not a four-letter word, so it's okay to use it, but it's one of those words used by managers to mean something that is important, but which no one understands (or, is too big for what it's being used for). It's like using the word 'dialogue' as a verb...it's wrong on so many levels, but it sounds cool to a manager, because it's 'big.' Of course, since I'm a manager, I get excited about these kinds of words...it's a chance to make fun of myself by using big words.

In this case, applying the word 'enable' to discipline means providing appropriate incentives to people such that they will have a greater degree of discipline, whether they like it or not. Putting furniture in my kids rooms won't solve the cleanliness issue, but it will enable them to do better (in other words, it may not mean sparkling clean rooms, but it should mean better organized rooms).

Even though adults and professionals shouldn't have a problem with being disciplined on a software development project, they sometimes do (and in some cases, it's a major problem). This is because there are incentives (or a lack of them) to do what they are doing. Rarely do people do things randomly. Economics tends to agree with the concept that water heads in the direction of least resistance (technically, water heads in the direction in which it perceives the most value or return for its limited resources, but that's not as easy to picture).

Let's use an example: let's say the process states that all code must be peer reviewed. You're working on a project that's expected to have a million lines of code and it needs to be written in about a year. You've got a big staff and a process that's primarily paper or spreadsheet-driven. Do you think every line of code will be reviewed? How about if each review requires at least three people, must have half a dozen metrics tracked, reported, and verified? I won't suggest that there are no projects in this situation that haven't had every line reviewed. I just don't think I'll need more than a hand or two to count them all.

What if I changed the process by creating a web-based tool that allowed code to be reviewed asynchronously, which automatically tracked all appropriate metrics, etc.? Do you think there would be a better chance? Did you know that such a tool exists (it does, by the way...many of them, in fact)?

When you make something easy; when you smooth out a rough or painful process (there, I got back to that 'pain' thing); when you hide following a process by merely using a tool to accomplish something that you had to do manually before; when you make process a part of doing your job, rather than an external thing to be followed, it will get done more often. It may not completely remove the lack of discipline, but it will go a long way towards overcoming major discipline issues, if not fixing minor ones. You never know, it might save time and energy, raise morale, create better quality products, cure diseases and encourage peace on earth (okay, maybe not so much about the disease and peace thing, but, hey, those are good goals, too).

Just remember that a tool does not necessarily mean something physical or electronic (i.e. web site, development tool, etc.). It might mean providing decision authority to the right people, adjusting an organizational chart, letting people work from home more often, or merely bringing in a ping-pong table and seeing what happens...