The Paradoxes of Software Development

When you've been working in Software Development for a while, you eventually wise up to the three important factors that drive any project: Time, Money, and Scope. (Sometimes people replace that third option with "Quality", but I think that the three of them together make up the three sides of a "Quality" triangle.)

They are certainly the three things that drive any Project Manager, although you sometimes hear them talk about it using different words:

1. Schedules, Milestones and Deadlines
2. Budgets, Resources, People, Equipment, Tools, Training, etc.
3. Features, Requirements, Work Breakdown Structure

When you start any project, you always desire lots of each of these. In reality, you are constrained in each. You can't have all the time in the world. You can't have all the people, tools, training, or equipment that you'd like. And someone is always trying to sneak in more features, but there are limits to what you can put into any software release if you ever want to get it out the door and make some money from it.

Consultants use these three factors (Time, Cost, and Scope) during contract negotiations. The experienced consultant will be able to take any two fixed factors and give you a practical estimate for the third.

So what are the paradoxes? These three factors are, but not for the reasons listed above so far.

Time

You never have enough time. Never. Live with it.

It's more than that though. When you are at work, your time is always interrupted. This is unfortunately unavoidable. It is the nature of Software Development that we miraculously create a complex masterpiece through a process of continuous interruption.

Interruptions come in different forms. Everybody expects to take bathroom and mealtime breaks. But what about the interruptions by email? What about when someone calls you on the telephone or shows up at your desk? Bam! There goes your train of thought!

Of course, it's not polite to yell at people to go away and leave you alone. (Although it may be very tempting with some people.) The reality is that, as a complex human activity, software development requires that a lot of people get the information they need to do their part of the project. Everybody has a part in creating information, so everyone has a responsibility to make sure that the information they know is passed onto the people who need it.

You could be on the verge of solving a complex problem that has eluded you for days, when all of a sudden a Project Manager shows up at your desk to ask you your opinion on the risks involved in making a change somewhere. Or it could be an impromptu meeting. Or a technical writer asking you to review some documentation that you have some familiarity with.

I knew a programmer once who said that he was far more productive when he worked at home for two reasons: (1) he didn't have to get up and leave the building whenever he needed to smoke (he could just smoke at his desk at home), and (2) no interruptions.

The problem of course is that when he does get back into the office, he will eventually be inundated with questions about the work that he did -- in order to pass that information onto the next person who needs it. He also eventually needed to collaborate with other programmers to understand the integration of his work with theirs.

Try as you might, you cannot make software in isolation forever. You may need to get away from others for a while to help you focus on a problem or goal, but you cannot stay away for long. You just can't.

Money

This is a funny one. Not everyone is immediately aware of the importance of the money available for a project until they try to get something and realise they can't. For example, it would be really cool if we could get this "super analyzer metrics-reporting database-query problem-solving automatic-tester all-in-one XML-friendly scriptable-API user-friendly reliable coffee-making appointment-remembering time-saving dry-cleaning fully-customizable easy-to-use tool" ... until they see the price tag.

Or worse, you realise that you can get some of the tools you need cheaply, but you don't have the time to spend figuring out how it can be integrated into your project or environment. Is there any way that we can hire a contract person (e.g. a high school or university student) to figure it out for us so that we can reap the benefits of the tool without actually spending any of that time figuring it out for ourselves?

What? No money in the budget for extra hires? But how can we meet the deadlines if we don't have the help/tools/equipment/training/whatever that we (think we) need?!

Start-up companies generally have a harder time with budgets and available finances than larger, more established, global organisations, but big companies have their share of money problems too.

The funny thing about needing money is that often you get it - but at a price! You will end up "owing" someone, in one way or another. Nothing comes free, and money is at the top of the list.

Many years ago, I had a terrible experience working for one company when we had a person leave our test team. I approached the Director of Development about when I could start hiring her replacement, but then he started giving me the run-around, talking about the "return on the value" of our test team, and that perhaps the funds allocated to the test team salary budget could be better reallocated to hire another programmer instead. After all, we would certainly be more productive with another programmer and one less tester, wouldn't we?

I quit a few months later. I have been extremely happy with my decision and never regretted it. That company no longer exists since it lost all of its customers a short time after I left.

Money is a tricky thing. It should never be placed in the hands of fools, because they will always do foolish things with it.

It's about more than just the Economics of the business though. "Time to Market" can have a BIG impact on the price of the Shares in your company (if it is a Publicly traded organisation). You don't meet the release deadline for a particular Quarter >> share prices drop >> No bonuses this year! In fact.. there might even be "restructuring" in the near future.

To do a great job, you may need more people, tools, training or equipment, but those things all cost money. You may or may not have money "in the budget" for these things. Getting those things may come at the expense of a lower salary or absence of financial bonuses. Not having those things may mean that you will miss the important deadline and cause your business to miss its Sales goals... which in turn mean lower salaries, no financial bonuses, or even layoffs.

Money. How do you want it?

Scope

It all starts innocently enough with the customer. This "customer" may take different forms depending on the industry you are working in.

You start with a list of features. These features are deemed to be the critical success indicators for the software if it is to be bought and used.

Software Development is a complex and iterative process whereby some really smart people take that feature list and break them down into hardware and software components from a particular technology. Suddenly that list of ten or so items, is now broken down into hundreds of smaller pieces that all need to work together in harmony to make up the features that the customers want.

Think of it this way: In Ancient Egypt, a Pharaoh once said: "Build me a Pyramid! I want a tomb of magnificent proportions that will leave a legacy for eons to come!" The Architects designed it, and then the Engineers built it.

Have you ever looked closely at a Pyramid? It's made up of thousands of stone cubes! Where did these stones come from? How did they get there? How did they put them together to make the finished product? What about the workers? How did they feed and clean up after thousands of slaves?

Thinking about some of these questions will begin to give you an idea of the orchestra at work in a software company to produce a product that the customer needs and will pay for.

But then a funny thing happens. Someone looks at the software. It might be a Product Manager, a Software Tester, or even the customer. And they discover something that isn't quite right. Sure, perhaps the big, important features are there, but the little details between them might be clunky, incomplete, or too complicated to make sense.

Uh oh. We need to make changes to the software.

And we keep "testing". And we keep discovering more "little things". And before you know it, that "critical list of ten features" that was broken down into hundreds of components is now tied together with thousands of little details!

It takes a keen mind to be able to keep all of these details in perspective of "the big picture". That is, does it make sense to make a particular change now, or should we put it off until the next release or version of the software?

I've met many testers who believe that every bug they find should be fixed right away. That's a foolish and narrow-minded perspective, in my opinion. I believe that if the problem is worth reporting, it should be worth fixing (whenever feasible), but each problem needs to be assessed for the risks involved and the priority or relevance for that particular release.

For example, I once tested a client-server application and found a bug that crashed both the client and server at the same time. (This is unusual because usually you only find bugs that affect one or the other.) In the Project Status Update meeting that week, I argued that we should NOT bother fixing the bug for that release. That is, even though it was a serious crash, I knew that no customer had ever reported the problem in the five years that the software was on the market. This led me to conclude that no one was in fact actually using that feature. So, I could only conclude that it would be a waste of time to fix a feature that no one was actually using.

Being able to keep things in perspective like this is what helps you to avoid one of the strongest Failure-factors in the business: "Scope Creep." Changing Requirements.

It's just a game sometimes. I've seen it many times. It goes something like this..

You ask the customer what they need to do their jobs. They tell you and you make the list. You come up with the requirements and double-check them with the customer to make sure it looks right. You make the software, work out the bugs, and release it to the customer for approval.

Now that the customer has the working software in front of them, the bar has been raised. "Oh well, it almost does what we need. It just needs these many more features, and then it will be perfect."

The smile falls from your face, but you go back and work to get these new features into the product. When you bring the software back to the customer, the bar has been raised again! "Well, it's almost perfect, but it still needs these features for it to actually work for us with the way we do things."

Just for the record, these are the kinds of customers that cause software companies to go out of business. More importantly, the Project Managers who don't recognise this situation and allow these scenarios to play out late in the development cycle are really the ones who cause the software companies to fail.

"Scope Creep" or "Feature Creep" simply refers to the changing of the requirements while the product is still in development. What may seem like a straightforward list of requirements at the outset may suddenly become conflicting requirements by the time you expect to release the software.

Changes may be subtle and sneak up on you in inconspicuous ways, or they may just hit you in the face like a closing door when you are looking the wrong way.

Getting a handle on Scope requires you to understand: (1) the Development Models (Life Cycles) used to provide the guidance in the way you build the software, (2) the customer and their appropriateness to help you achieve your desired results, and (3) the Requirements gathering process and the iterative nature required to truly flesh out the useful features from all the unnecessary "Bells and Whistles."

Scope. Feature list. You think you know what you need to do. You will be wrong every time. Software Development is a process whereby you usually engage on a journey with nothing more than a general sense of direction but no clear understanding of the final destination. That's the way it is.

Go to the ocean and learn to surf. Things will become clearer.

New Year's Revolution

I'm at an interesting crossroad in my career. Allow me to think out loud and recap a few things..

On the one hand, I have a formal Science education. I love Science. I got into it because of Physics. I loved the problem solving. However, I didn't see myself as a Lab rat for the rest of my life, despite the coolness factor.

Enter my second love: Teaching. I went to Teacher's College and became a High School Science teacher. Interesting thing about teaching is that you actually learn more about a subject than you ever did as a student. There's something about looking at a particular concept from many different perspectives to try and explain it to a variety of students with a range of skills and interests. I learned even more about Science and I loved it even more. However, the reality was that I needed a break from school so the timing was a bit off. I can always return to it later if I choose.

Somewhere in between all this, a hobby of mine (fooling around with computers, and software in particular) turned into something of a recurring job. I did the programmer thing for a few years. Did my time in Tech Support for almost a year, and then I fell into QA almost by accident. I liked Testing. It was somewhere in between the programmers and the customers, but there was something I couldn't quite put my finger on that kept me interested in it.

When I chose to not teach anymore, I decided to go back to QA & Software Testing. I didn't know what the difference was (between "QA" and "Testing") but I knew that: I enjoyed doing it, that I could do it, and that not a lot of people really wanted to do it. I spent about 6 years trying to figure it all out. Eventually I came to understand what Quality Assurance (QA) really was about and how different it was from Software Testing. At that moment, I chose to continue to pursue learning and doing Software Testing.

The years have passed, and I have become quite Senior in this field now. That means that I can be dropped in pretty much any situation now and have a reasonable chance of success (but more on that later). One of the problems when you reach this point though is that there aren't many people you can turn to when you have questions. As luck would have it, I stumbled across the right set of email discussion forums where all of the industry experts hang out and discuss ideas. These are some of the smartest and nicest people I have met in my life -- outside of the circle of Physicists I once knew who still ponder the mysteries of "Life, the Universe, and Everything in it" today.

I gotta say that being able to talk with some of these people is really cool! I don't think I've ever been this close to the cutting edge of creating a new profession and affecting an entire industry as I am today.

Here's my dilemma: I'm enjoying my work as a Tester too much, but the "teacher" side of me is aching to get out and spread the word! BUT.... to become a teacher here, it would mean either becoming a trainer/consultant of some kind or going into an educational institution of some kind (a university or college).

Going the independent consultant route involves risks that I'm not prepared to handle at this particular moment. I could do the consulting and training part, but I don't have the business skills I would need to keep myself busy. There's a recipe for disaster! So, until I find a partner who can help me with the marketing and finances side of things, I'll keep this one on the back-burner for a bit.

Going the educational institution route has it's own interesting problems too. If I wanted to teach at the local college, I could probably do that. There's not a lot of money in that though, so I don't know how long I would be able to keep it up. Teaching at the university has a great many attractive qualities. Just one thing: I don't have a Ph.D. Oh ya, I'd need one of those.

The funny thing is that I know exactly where I would go to get one (can you say the Florida Institute of Technology?), but there's a few things keeping me from packing up and doing that right now.

Okay, so fine. I have a few options, but I have relegated them for the time being in favour of staying where I am to see what else I can learn and help contribute to the Testing Profession as a "practitioner".

So, what now? I wrote an email to the Software-Testing mailing list a few days ago asking for a sense of direction. Maybe it was an unfair question to ask. Maybe it wasn't the right place to ask it. But I felt that I wanted to open myself up and see what kind of response I would get.

I got some good replies, but one of the best by far came from James Bach when he wrote:

We are headed toward a world that recognizes and respects testing as a skilled investigational activity, and is able to systematically describe and foster those skills.

• Can you list your testing skills?
• Can you demonstrate how to develop testing skills?
• Can you describe a model of the testing activity as you see it?
• Can you explain and defend your work without appeals to authority?
• Can you relate testing and testing skills to other established fields of intellectual work?

Let these questions, or others along the same vein, guide you. Anyway, they work for me. Please suggest others, if you want.

I like James. He makes me think. =)

I'm pretty sure that's why I love Testing so much. It really is the closest thing (for me) to Physics when it comes to the think-work required to do a good job of Testing. I've met so many drones in my career and only a few who ever gave testing a passing thought. But here, now, is the paradigm we are striving to communicate: to do a good job of testing, you have to use your head.

Imagine that!

Well, of course it's actually a bit more complex than that, and smarter people than me can explain it really well, but I'm content to just know what I'm doing right now.

This is it. The beginning of a movement that will change the way Software is developed forever. (Welcome to the Revolution!) Historians will look back at the early 2000's one day and try to piece together the events that led to the paradigms that affected future thinking on the subject of Software Development and Software Testing in particular.

That history - our future - isn't written yet. Someone's gotta make it happen. In the words of William Shakespeare:

All the world's a stage, And all the men and women merely players: They have their exits and their entrances; And one man in his time plays many parts..

This is my part and the curtain hasn't fallen yet. So I have some improvisation left to do.

At least I can use James' questions as a guide in the short-term.

Let's see where it takes me, shall we?

Don't ask me to look.. I'm tired.

This year it was our turn to host the family Christmas lunch/dinner party. My wife planned to cook a turkey with all the trimmings and I was in charge of baking some cakes for dessert. (I love to bake.)

About a week ago, I found myself sitting in the kitchen making a shopping list of the things that I would need for the baking extravaganza on Christmas Eve:
- I need milk. Don't we have milk? Better get some more.. Add it to the list. Check.
- Need sugar. Check the cupboard. Got plenty. What's next?
- Flour. Hmm.. we don't seem to have enough in the flour container. Didn't we have another bag of flour in the cold cellar(*)? (* Our "cold cellar" is an uninsulated storage room in the basement that we use as a pantry.) I've already been in there three times today and I didn't see it. In all fairness, each time I was in there I was looking for something else, so I'm not really sure if it was there or not.

My wife happened to be nearby in the living room sitting with our two boys watching a Christmas special on TV. "Honey? Do you know if we have any flour in the cold cellar?" I ask. She hummed and hawed for a moment and then said that she thought she remembered that there was a bag in there somewhere.

"I thought so too, but I've been in there a few times already and I didn't see it. Do you know where it might be in there?" I ask. She wasn't really sure but restated that she was pretty sure there was a bag in there.

At this point, I should add that this was near the end of the day and I was pretty tired. I don't think that I had slept very well over the previous few days, so in all I was feeling pretty run-down. Oh, and it was absolutely freezing in the cold cellar and I didn't really want to go in there again not knowing exactly where I was going to find what I needed. "Honey? Since you seem to think you know where it is, do you think you could go in and check for me please?" I plead.

She tells me that she didn't really want to get up and check at that particular moment. (In all fairness, when I'm spending time with the boys I usually defer such requests too.) That was too bad. I had started my shopping list. Once I started, I wanted to finish it. I can't just stop the list now and get back to it later. I need to know if we have some so that I can move onto the next item on the list!

Arrg! Fine. I'll go check myself. So I go in there, I check where I think it should be - nothing. I check the shelves - nope. I look in various plastic bags and underneath some bags with Christmas presents that the boys don't know about - nada. No luck. I'm freezing. Okay, back up to the warmth of the kitchen.

I march on up and mention to my wife in passing that I didn't see any flour so I'll just add it to the list. She asked me if I had checked the shelf above the wine bottles. I said that I looked there in passing, but I'm pretty sure it wasn't there. In fact, I was pretty sure that the bags on that top shelf contained leftover Halloween candy. She seemed surprised at me when I said this and told me that we shouldn't have any of that stuff left.

Damn. I have a doubt. Arrg. Back down into the cold cellar I go.

I go in and check the top shelf. Sure enough... no candy. One (plastic shopping) bag contained a bag of whole wheat flour (I can't use that for the cakes I want to make), and another bag contained some rice. (Wow, I didn't know we had extra rice. This is a good thing to know too.) No Halloween candy. And definitely no white flour. I can't feel my toes. Gotta get back into the warmth.

Up I go again. Again, when I pass my wife I mention that I checked and that she was right about the bags not containing candy, but that I still didn't find the flour I needed.

I sit back down in the kitchen and scribble "flour" onto the shopping list. I had checked. I double-checked. Didn't find any. We will definitely need some. Ahh, I can now happily move onto the next item.

I finish the list and go onto doing something else. About an hour later I found myself sitting pretty much where my wife was in the living room doing something with the boys. I heard a rustling noise coming from downstairs followed by some laughing. (Hmm, do I want to know what she's laughing about?)

My wife returned to the living room to let me know that there was indeed a bag of white flour sitting on the shelf in the cold cellar -- exactly where I had looked. (Sigh. It can't be true. Can it?)

"Really?" I ask. "Yes, really." She replied. "You're not just pulling a fast one on me?" I counter. "No, I'm not. It is sitting there in the middle of that shelf and you just didn't see it."

Doubt returns. Of course I have to go and see for myself.

I walk into the cold cellar and sitting there staring straight at me is this big bag of flour - right in the middle of the shelf. Some fleeting silly thoughts entered my mind: maybe a flour fairy came by and put it there after I had left; maybe my wife found the bag buried somewhere else and she just put it there so that I would think that I had missed it. No. I shake my head. I know exactly what had happened.

The Moral of the Story (a.k.a. "Lesson Learned"):

I was tired and my observation skills were clearly not up to the task at hand.

Also, I did not want to go in there and look for it. This feeling was so strong that I pretty much believed that there was NO bag in there to begin with.

As a result I didn't see the bag even when I was looking directly at it. I knew precisely what I was looking for, but I had the wrong disposition or frame of mind for looking (at that particular moment). In fact, upon reflection, I think I had even moved the bag of flour out of the way at one point in my search so that I could check to see what was behind it.

What changed my frame of mind? I had to believe my wife. Unlike me, she believed that there was a bag in there. She had an idea of where to look. She just opened the door and saw it sitting there plain as the nose on your face.

Sigh. I shut the door and went back up and scratched "flour" off the shopping list. We clearly have enough.

The Software-Testing Tie-In:

Over the years, I've always been very vocal about making sure that testers aren't forced to work overtime to make up for really stupid last-minute schedule crunches. "Just because development was late doesn't mean that the testers have to work overtime every night for the next four weeks to make up the lost schedule time."

I know that when you're tired you make mistakes. To compensate at work, I have always employed a risk-based testing strategy to help me clearly prioritise and communicate what we will (and won't) test under the new schedule timeline. No overtime - that is not an option.

Until the flour-in-the-pantry incident, I cannot recall such a blatant example of this phenomenon ever happening to me. I'm sure it has. This time it was easy to check though.

I can only imagine some poor tired (tester) soul trying to look for a particular bug (or class of bugs) but being too tired to see what is directly in front of them!

I didn't need this "flour" event to happen to me to drive the point home, but it certainly did. In the future, not only will I continue to force the "no overtime" issue, but I will also try to ensure some "recovery" time between testing projects to make sure that the testers have enough time to recover from the intense think-work involved on big testing projects.

Tired brains are just no good to anyone.

To Blog or Not To Blog...

Don't mind if I do, thank you. =)

After much ado from many of my friends, family, and coworkers over the last year or so, I have finally gotten around to starting a journal again. It's all about the writing. Gotta keep up the writing.

So, dear reader, what can you expect from this journal of thoughts?

To begin with, I am a student of life. Always with the learning am I. As a result, I'm big on analogies. It's like everything in life can somehow be compared to something else.. to some degree or other, that is. Analogies are my coping mechanisms to help me see if I understand something well enough, as well as provide quick and dirty mental models to help me describe something to someone else.

So what is it that I'm mostly learning about now? Software Testing is taking up most of my actual thinking brain cells these days. For most of the rest of things in life I'm kind of winging it as I go along. ;)

This spot will be reserved for my thoughts on what I'm learning, what I'm thinking, and what is generally going on with me in this grand adventure. You see, Software Testing is an emerging discipline.. uncharted territory.. undiscovered country. I have the privilege of partaking in discussions with many of the Pioneers in this field and sometimes I can't help but feel a bit overwhelmed at the prospect of helping to shape the future of Software Engineering in some small way. Cool. =)

There's so much to say.. so much to do..

And so it begins..