Monthly Archives: July 2010

Knowledge You Expect To Learn

,

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.

Humans, Multitasking, and Context Switching

,

The modern age demands from all of us to deliver more in shorter time. The easy solution to this problem is to multitask. However, as an article by Roger Brown points out: “Multitasking Gets You There Later.” At the bottom of the article he provides a good list of references as well.

Even if you manage to keep yourself and your team focused on one project at a time, you still have to ensure that you keep your day “defragmented.” Let’s suppose that you intend to do 6 hours of work today on your project. You can achieve the 6 hours total if you work:

  1. 40 blocks of time, 9 minutes each, or
  2. 4 blocks of time, 90 minutes each.

You will get way more done working the 4 blocks of 90 minutes. The simple reason is that you have minimized your context switches. Therefore you could focus on the task and finish it. Don’t take my word for it: try it out yourself today.

What Makes a Good Wiki Page?

,

Groups large and small use Wikis to capture and share knowledge. As you read page after page of a Wiki, you notice that some pages are good, but others not so much. What traits distinguish a good Wiki page from its mediocre cousins? Here are the four key factors that make a Wiki page good.

A good Wiki page:

  1. Focuses on one idea,
  2. Provides context for all outgoing links and attachments,
  3. Uses attachments wisely, and is
  4. Short (500 to 1,000 words).

1. Focus the page on one idea only. Help your reader quickly realize that they are looking at the right page by focusing the page on a well identified topic, subject, or idea. For all the ideas that lay outside of its focus use references to other pages. This will help provide additional material to your readers and will clearly delineate the boundaries of your page.

2. Provide context in the body of the page for all outgoing links and attachments. Weave your content together into a coherent whole with links in context. See my previous post on why a good Wiki tells a story. You need to weave your pages together by providing a context for each outgoing link. The context doesn’t have to be much: a half sentence describing where your link is going, a short paragraph describing the attachment, or a heading for a list of links.

While it easy to quickly create additional pages (sometimes also known as child-pages, or sub-pages) without the link in context, they are not very helpful, and often are difficult to find. Your readers need to know in what order to look at the other pages, or why should they look at those pages. You must provide the necessary guidance by explaining the reasons for any link, and creating a context for them as well. The context will aid searching, and more-importantly, finding, your pages, too.

3. Use attachments wisely, that is: sparingly. When you have a plain text, or rich text document, you need to import that document as a Wiki page. Do not turn the document into an attachment. Just one extra step between your readers and the knowledge they seek may stop them from looking.

Most Wikis still have trouble indexing attachments. Some attachments, notably pictures, drawings don’t lend themselves to easy indexing, therefore if you want to find an attachment, you’ll have to find it based on the context of the page that it is attached to.

4. Keep the page short (500 to 1,000 words). Your readers access the Wiki pages on the screen. Make it easy on them. Short pages help the reader see the entire page at once, or bookmark just the right information for later reference.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupery

Here are some good Wiki pages from Wikipedia:

  1. Atomic Commit: Concise, to the point, with links in context and focused.
  2. Two-Phase Commit Protocol: Not short, however kept focused on the topic, with links in context for further information. If the subject demands, you can go longer, just keep in mind that you might loose your reader…

Help your team by writing outstanding Wiki pages! Your team will thank you for them.

Effective On-Task Time

, ,

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: