Practical Software Engineering

strat-e-gy: a plan of action or policy designed to achieve a major or overall aim.
–The New Oxford American Dictionary

The dictionary definition points us in the right direction. The software development strategy is your highest level plan for achieving your software project’s objectives. According to Watts Humphrey, the strategy is “the order in which product functions features or requirements are defined, designed, implemented, and tested.”

What does this mean? This means that the plan of action part of your strategy lays out what you build first, what you build next, and so on. It also lays out how are you going to validate the strategy. The strategy also lays out the policies for risk mitigation and decision making. Sections of the strategy may exists both along the developer – customer continuum and also along the system abstraction levels continuum. For details about these continuums see: Multilevel Planning and Component-Based Development.

The System Architect is responsible for the overall strategy. The strategy has to be sound enough that designers and implementors working on parts of the system receive from it the necessary guidance to aid their technical decisions. A well conceived strategy pushes the decision making down to the lowest possible level, closest to where the problems are encountered, while at the same time provides for the oversight necessary to build a coherent system.

Accompanying the development strategy is the testing strategy. The testing strategy focuses on the various testing activities, including the system validation and verification activities. It is constructed similarly and serves the same purpose as the development strategy, only for testing. The owner of the testing strategy may be the System Test Architect, if there is one, otherwise this is also owned by the System Architect.

Why do you need a strategy? Without a strategy it is difficult, if not impossible, to execute an iterative, incremental development process. The strategy ties the iterations into a coherent whole, and allows the team to move confidently toward the goal. Your first attempt at creating a strategy may feel awkward, but with practice you’ll get better at it. Why don’t you get started today?

Regardless of the organization you work in, this question probably comes up daily, but at least weekly. To answer the often dreaded status question you need minimum 4 pieces of information.

1. When did the project start? This is the Start Date.
2. When is the project expected to end? This is the Expected, Planned, or Estimated End Date.
3. Where should we be today based on the plan? This is the Expected, Planned, or Estimated % Complete.
4. Where are we today? This is the Actual % Complete.

If you have the above information then you are able to judge how well you are doing relative to what you said you’d be doing. There is a lot more to project management, but this is a good start.

To get started make a plan for the work you intend to do this week. Write down at least 2 tasks for each day: one task for the morning, one task for the afternoon. This gives you a total of 10 tasks for the week. As you check off the completed tasks, you’ll see your progress bar move. Once you are able to plan your work for a week, plan the next month. Collect your data and adjust.

There is no need for you to wait for your entire organization or team to start doing this. You can get started alone. You’ll be surprised how much better your work will go and how much better you’ll be able to help your team.

Writing an individual project plan for your project work can be difficult. The secret of creating a workable task plan is to consider not only the work you will complete, but also the knowledge you expect to learn as you perform each task.

As you complete tasks from your plan, two things happen:

1. you create deliverables, and
2. you learn.

On a short project you may not be able to learn much. If your project is short, only a week long, then to improve the odds of success, you have to make a plan considering only the knowledge you have at the beginning of the project. One week is generally not sufficient to learn something of consequence that will help you get your project done on time. When you make your plan, focus on the deliverables created by each task. When all tasks are done, the output created must add up to a completed project.

If you notice that you have lots of short projects, then you need to take a more systematic view, and find ways to include learning into your work. Teams that fight fires, each fire being a short project, tend to believe that they don’t have time to learn. They feel that there is never time for learning. However, firefighting is really one long project with lots of short iterations. More on this another time.

On a longer project you must learn. If your project is longer, 2 to 4 months or more, then you must factor learning in the work you are planning to do. More so, you may even want to include deliverables that allow you to verify that learning has occurred. Such deliverables are prototypes, proof of concepts, sample code that you create to demonstrate to yourself (sometimes to others) that you indeed understand the work, the requirements, the API, or some other things related to the project.

Outside of explicit learning-oriented deliverables you also must factor learning into the regular project tasks. Let’s look at an example. You make a plan to create component A and component B. B will be using A through A’s public interface. However, at the time of planning you don’t know exactly how that interface will behave. So you plan for learning.

The knowledge you expect to learn is that you will know exactly how A will behave before you start work on B. This knowledge is pre-requisite for doing the correct work on B. Part of the tasks for creating component A include the writing of A’s unit tests. When you perform this task you will learn how to call A through its public interface. By the time you start work on B, you will have acquired the necessary knowledge to perform the work on B. You didn’t have this knowledge when you made the plan, but you planned for the learning to occur by the time you needed it.

After some practice, factoring into your plans the knowledge you expect to learn will enable you to make more detailed plans for longer horizons with higher accuracy. The challenge is that you need to change the way you think about project work. Plan for learning. Make learning an explicit and expected outcome of each task. You’ll surprise yourself, and your team. Your plans will become ever more accurate.

Software development is knowledge work. We use knowledge, take input as knowledge, and the output we produce is knowledge. Our output is executable knowledge. According to Peter Drucker, the 21st century’s defining characteristic is knowledge work. We, software engineers, are right in the middle of it. Drucker writes that manual worker productivity during the 20th century increased 50 times. He admonishes us to improve knowledge worker productivity during this century as much as we improved manual worker productivity during the last century. He postulates that the developed nations of the future will be those that will make their knowledge workers productive.

Unfortunately, we seem to have a hard time measuring productivity. Economists have a straightforward measure of productivity: the value of the output divided by the time required to create it, expressed in dollars per hour. We need to figure out how to make this definition operational for software developers. A component of this measure is time.

Let’s start with Effective On-Task Time or EOT. This is the time that you spend creating the deliverable that is the target of your task. You keep this number pure, devoid of anything that didn’t directly contribute to the output. Your objective is to measure the time that the task took. You can find references to the concept of “Task Time” in a number of places. Watts Humphrey writes that “task time is what engineers spend working on scheduled tasks.”

And herein lies the heart of the matter: EOT is about working on something that you planned to work on. It is about your ability to meet a commitment. The plan is your commitment. The time that it took to complete the task is reflective of your ability to understand the work required to meet that commitment.

EOT doesn’t include time for any activities that don’t matter to the work of creating that deliverable. The interruptions from your co-worker, phone calls, and breaks don’t count. Some of the activities may tangentially work toward it, but your objective is not to account for every minute, but rather to count those distinct minutes when you know that you are moving the needle forward.

At the end of the day, EOT matters first and foremost for you. It helps you understand how good you are, how well you understand your work. It builds your confidence. When you repeatedly make aggressive plans and meet them, you know that you are becoming the engineer that you always wanted to be: outstanding.

References:

• Drucker, Peter. Management Challenges for the 21st Century. Harper Business. New York, NY. 1999.
• Humphrey, Watts. Winning with Software. Addison Wesley. Boston, MA. 2002.

Planning is a topic that I find myself coming back to time and time again. I’m asked enough questions about it so I decided to write down some of the answers. Folks who have not had to do any planning are stumped when asked to make a plan. I found that planning can be rather intimidating until you start with writing down what are the deliverables and what is the time frame. This will get your thinking started in the right direction. This and upcoming notes are here to help you get started on planning your own work.

Consider this scenario: you get assigned to a project, but instead of being the one you dreaded, this is one that you are excited about! The technical lead held an effective iteration kick-off meeting. You picked up work on a couple of features that you thought were really cool. You are expected to make a commitment to deliver the features at the end of the two-week iteration. Can you do it? How sure are you? How do you begin to build a plan for your work?

The first step is to decide how much time you can afford to spend on each feature.

1. Kickoff (1 day)
2. First feature (4 days)
3. Second feature (4 days)
4. Wrap up and demo (1 day)

Next, estimate how you intend to spend the 4 days you budgeted for each feature. You must think of your time as money. Spend it well. Let’s suppose that your technical lead had done a good job coming up with granular features, and you can indeed implement each feature in 2-4 days. Here is how you can “spend” your time during the iteration:

1. Iteration kick-off meeting (1/2 day)
2. Plan the iteration (1/2 day)
3. Design the first feature (1 day)
4. Implement the first feature (1 1/2 days)
5. Test the first feature (1/2 days)
6. Prototype the second feature (1 day)
7. Design the second feature (1/2 day)
8. Implement the second feature (1 1/2 days)}
9. Test the second feature (1/2 day)
10. Fix the defects found in integration & system test (1 day)
11. Demo the iteration results to the team. (1/2 day)
12. Buffer (1 day)

That’s it. This is your rough plan for the iteration. If you wish, you can call this a time budget and not a plan. If you are to deliver the features at the end of the two weeks, this is all the time you have. The key point is that this plan, even with its limited details, shows you what time can you afford to spend on each feature. The presence of the buffer in your plan is the clearest acknowledgment that you don’t yet know enough. When new things come about, you won’t have to replan your entire plan. You can just eat into your buffer. However, once your buffer gets exhausted, then you need to rework your plan.

Looking at this plan you might think that you won’t be looking at times at both features. That should not be the case, especially if they are related. It just means that now you have a way to get the work started. As you get into the details of the work, you will refine this plan. For ideas on how to move forward take a look at What do you know? and Guidelines for Detailed Planning. There are many other aspects of planning, e.g. getting some data on how you are doing, and how to improve your planning skills. For now though, just get started. As the old Chinese proverb puts it:

“The one thousand mile journey starts with the first step.”

Ready! Set! Plan!