To create a project schedule, we have to model the project’s activities and their dependencies. Or, if you prefer, their relationships. A project schedule is typically drawn as a graph — arrows joining circles. The fancy way saying this is, edges for the arrows (a.k.a links) and vertices for the circles (a.k.a nodes). This type of graph is typically drawn from left to right, with the project’s starting date on the left.

So, what do the circles and arrows mean? Well, it depends.

Activity-on-node

This is a simple graph where the circles represent the activities and the arrows the dependencies. It is also known as a precedence network. We call it a precedence network because a node, or activity, cannot be executed until all of its preceding activities executed.

To draw an activity-on-node graph, we have to follow some rules:

• only one starting node;
• only one ending node;
• each activity has a duration;
• links have no durations;
• time moves from left to right;
• the graph may not contain any loops;
• the graph may not contain any dangles – a node that just stops in the middle of nowhere.

By the way, this activity label is based on British Standard BS 4335.

Critical Path applied to Activity-on-node

A critical path is the order in which we should execute activities, so that we can get the project done as fast as possible. Not only that, it also shows us which activities will cause us to miss the end date, if they are delayed. How do we determine the critical path?

Well, for each activity we need to have some idea of, how long it will take to do, what is the earliest we can start and complete the activity as well as the latest we can start and complete it. That is the Duration, Early Start, Early Finish, Late Start and Late Finish parts of the activity label.

To calculate the earliest dates, we need to do something called a forward pass. That is, we look at every activity and calculate its early start and early finish dates. The first activity’s early start values always starts at zero.

In the network graph above, we see that Task A and Task C can start immediately. However, Task B must wait until Task A and Task C completes (it’s predecessors). Since Task C has the longest duration (10 days) between Task A and Task C, Task B can only start in 10 days and will complete on day 13. The earliest that Task D can start is in 2 days time, after Task A completed. With this in mind, the earliest that the project can complete is in 13 days time.

Next, we need to do a backward pass on the same network to calculate the Late Start and Late Finish values. This gives us the latest date at which an activity must start and complete without delaying the end date of the project. The late finish date for the project is the same as the early finish date.

In this example, we see that the project will complete in 13 days. So, we work from the end date backwards. Starting at 13 days, we can see that Task B will take 3 days to complete and so the latest start date is 10 days (13-3). Task D also needs to finish on day 13.  This task takes 4 days to complete and so the latest date to start this task is in 9 days time (13-4). Task C on the other hand must finish within 10 days and has to start immediately (10-10). Since Task A will take 2 days to complete and we know that the latest finish date is only in 9 days time, we only have to start this task on day 7 (9-2).

To find the critical path in the graph, we find the sequence of tasks that will move the end date, if there is a delay in any of its activities.

If there is a delay in Task C so that it only completes on day 11, it will delay Task B and ultimately the end date. We have to pay special attention to the critical path throughout the project so that we can handle any delays as soon as possible. The critical path sets the activity span. That is, the shortest time in which we can complete the project. If we want to shorten the time of the project, we have to cut the time of the activities in the critical path.

Activity-on-arrow

In activity-on-arrow networks, the arrows, or links, represent the activities. The nodes represent events of activities starting or finishing. Just like the activity-on-node graph, so too activity-on-arrow graphs have rules when it comes to drawing the network graph. They are:

• only one starting node;
• only one ending node;
• duration is on the link;
• nodes have no duration;
• time moves from left to right;
• nodes are numbered sequentially;
• graph may not contain any loops;
• graph may not contain any dangles.

Critical Path applied to Activity-on-arrow

Before we can find the critical path in an Activity-on-arrow graph, we need to do a forward pass. It follows the same principles as activity-on-node. The only exception is that in activity-on-arrow we use the events and not the activity start and end dates.

Let’s look at an example (Hughes and Cotterell, 2009):

The earliest date when an event can start is the date when all the events that it depends on is complete. In the example above, activities A, B and F can start immediately. So, the earliest date for event 1 is zero. Since activity A takes 6 weeks to complete, we can only start activity 2 in 6 weeks time at the earliest. Activity B takes 4 weeks to complete and so event 3 can only be achieved in week 4. Activity F is dependent on the ending date of activity E and so we only know that activity F will complete in 10 weeks. Activity E can start in 4 weeks time and will take 3 weeks to complete. From that we know that activity E will only end in 7 weeks time. We then take the longer of the two ending dates (between E and F) and find that event 5 will only be achieved in 10 weeks time. Event 4 can only start in week 9 (6 + 3) > (4 + 4).  We now see that the project will only finish at the end of week 13, at the earliest.

Next, we do a backward pass on the same graph to calculate the latest date at which each event should be achieved. It follows the same principles as the backward pass for activity-on-node.

To find the critical path, we make use of slack. Slack is the difference between the earliest date and latest date. It tells us how late an event can be without affecting the end date of the project. The critical path is that path with all the nodes having a zero slack.

References

1. Hughes, B. & Cotterell, M. 2009. Software Project Management, 5e. Berkshire: McGraw-Hill Education.

How then do you estimate the effort of a project with such uncertainties?

At the start of the project we should be able to get some idea of what the end-product will look like. From that, we can start estimating how long the bits and pieces will take to develop. Now that seems easy, but estimating how long the bits and pieces will take is not as simple as it seems.

Over- and under-estimating effort

Let’s look at Parkinson’s Law. It says that “Work expands so as to fill the time available for its completion.” If the task ends up being easy, then we will waste time and work less hard.

On the other hand, under-estimating effort will result in an unreliable and poor quality system. This is a manifestation of Weinberg’s Zeroth Law of Unreliability which says that “If a system doesn’t have to be reliable, it can meet any other objective.” Many people will make this sacrifice simply to complete the product before the deadline.

When a project starts falling behind, project managers will typically add more people to the project. Brook’s Law explains that “Putting more people on a late job makes it later.” Why is that?

Let’s look at an example. In a team of three members we have 3 “communication channels”. Add two more people and we have a team of five. This means that we now have 10 “communication channels” between people. We calculate it using [n * (n - 1)] / 2 where n is the number of people. Frederick P. Brooks covers this in his book The Mythical Man-Month.

Estimation techniques

In his book Software Engineering Economics by Barry Boehm he suggests a few ways in which effort estimates can be derived.

Bottom-up breaks the project into it’s components and those components into it’s components and so on. Take each of the components and estimate the lines of code and multiply this with some factor that adds fat for complexity. Based on that number, calculate the number of days it will take using a ratio between lines of code and effort. [It is called bottom-up because the effort accumulates upward.]

Top-down is based on two parameters, size and productivity. Effort is then calculated as effort = size * productivity. Where size is an estimate of the number of lines of code and productivity is the time spent by the developer doing the work. The productivity parameter is scaled according the developers experience. There is a more advanced calculation. It uses the least squares regression model which is calculated as effort = constant1 + (size * constant2).

Expert judgement relies on the knowledge and experience of someone who is already involved in the project. This estimation doesn’t only rely on the person but also takes into account similar projects and supplemented by the bottom-up approach.

Case-based reasoning finds the differences and similarities between completed projects, or source cases, with the new project, the target case. Take the similarities and differences and adjust the source cases so that you get an estimate for the target case. There’s a fancy way of doing this by using the Euclidean distance between the cases. This technique is also called estimation by analogy.

Function point analysis assigns a complexity value to each instance for each of the following components, which is then summed to get the function point processing size:

• External input types – inputs that change the internal data;
• External output types – outputs from the system, such as reports;
• External inquiry types – inputs that point the system to information without modifying it;
• Logical internal file types – the information system’s data store;
• External interface file types – input and output exchanged by the information system.

Function points MarkII is an improvement on the original Allan Albrecht function point analysis technique. Create three weightings, one for input (Wi=0.58), one for entity types (We=1.66) and one for output (Wo=0.26). Then, multiply the weightings with the number of elements corresponding to each of the weightings and calculate the proportions of effort. [The values for the variables Wi, We and Wo have been set based on industry averages.]

COSMIC full function points is used for sizing real-time and embedded systems. Typically, these systems are made up of component layers which may communicate with each other. Assign a value to each data group and sum the counts to calculate the functional size units.

There are four data groups which are the  inputs and outputs of these components:

• Entries – moves the data group into the component;
• Exits – moved the data group from the component;
• Reads – moves data from storage into the component;
• Writes – moves data to storage from the component.

COCOMO II is a constructive cost model where effort is calculated as person-months based on 152 hours and it’s size is measured in lines of code. Effort is calculated using the formula effort = c(size) ^ k where the constants c and k are dependent on the nature of the product and the development environment:

• Organic mode (small system developed in-house) [c=2.4, k=1 .05];
• Embedded mode (tight constraints, expensive to change) [c=3.0, k=1.12];
• Semi-detached mode (hybrid of organic and embedded) [c=3.6, k=1.20].

The way in which we calculate the effort is dependent on where we are in the development process. During application composition (user interface design) we use the number of physical features of the product such as screens, reports and so on. This is known as object points.

At the early design stage (architecture) we use function points to estimate the size of the system. There is a neat little trick here to convert the function points to the equivalent number of lines of code. To do that, we multiply the function points by a factor for the programming language used.

After we have gathered all the data we can now calculate the effort in person-months using the formula pm = 2.94(size) ^ (sf) * (e1) *…* (en)† where size is the number of lines of code in thousands (kdsi) and sf is the scale factor which is calculated by sf = 0.91 + 0.01 * Σ(exponent driver ratings)†. Exponent driver ratings are there so that we can compensate for the loss of productivity on large projects.

Determine the scale factor (sf) by assigning points from the table below to each of the following exponent drivers:

• Precedentedness - how novel is the system? The more novel, the more uncertainty, the higher the exponent;
• Development flexibility – how easy is it to meet the requirements? If it’s tough assign a higher exponent value;
• Architecture/risk resolution – how likely are the requirements to change? Very likely, up the exponent;
• Team cohesion – are your team members friends? If not, up the exponent;
• Process maturity – do you know what you are doing? If you do, go low on the exponent.

Here’s a table to help you out on the exponent driver values:

†Pssst… I changed the formula’s a little. There are variables which have been set for many years and so the formulas should really be pm = A(size) ^ (sf) * (e1)*…*(en) and sf = B + 0.01 * Σ(exponent driver ratings).
References

1. Hughes, B. & Cotterell, M. 2009. Software Project Management, 5e. Berkshire: McGraw-Hill Education.

pragmatic 1540s, from M.Fr. pragmatique , from L. pragmaticus  ”skilled in business or law,” from Gk. pragmatikos  ”versed in business,” from pragma  (gen. pragmatos ) “civil business, deed, act,” from prassein  ”to do, act, perform.” (1)

Pragmatic programmer

So, what makes a pragmatic programmer? A pragmatic programmer is someone who exhibits certain attitudes and practices when thinking, writing, testing and deploying software. This includes being an early adopter or fast adapter, being inquisitive and thinking critically. It also means being realistic and being anything-ready. And to be anything -ready one must learn continuously.

One of the major philosophies is to always place the problem and the solution in a larger context. This means to always think beyond the immediate problem and see the bigger picture. Why? Simply, so that you can make informed decisions such as deciding where to comprise and where to apply the Pareto principle.

A pragmatic programmer takes responsibility for everything they do. They don’t just sit there and watch the code rot. A pragmatic programmer will always endeavor to keep the code pristine.

Instigating change is another important skill that a pragmatic programmer must learn to apply. People are naturally opposed to change and in order to be a pragmatic in a software project, it is sometimes necessary to break the “we have always done it like this” mentality.

Skills and Tools

Using the appropriate tools is one of the best ways to amplify your productivity. Try various tools and pick the ones that work for you. Then, learn them extremely well. Mold them to the shape of your hand. Consider the following categories of tools:

• Source control
• Text manipulation
• Debugging

Another important tool is to be able to touch type. This is a worthwhile skill to learn, so be prepared to put in a lot of time.

Life as a pragmatic programmer

Being a pragmatic programmer does not make you write perfect programs. Accept it. Things will go wrong and when they do, we should ensure that the data always remain consistent. As the book says “dead programs tell no lies” and sometimes it is best to just simply kill it.

As long as there are people, software will change, continuously. That’s life. Pragmatic programmers guard themselves against the impact of these changes by observing the Law of Demeter (it’s not a dot counting exercise) and decoupling dependencies. Keep separate concepts separate.

Coding is not just a matter of transcribing requirements into source code. It is a continuous process of making decisions. Decisions that will either pave your way or cause you grief later on. The choice is yours. Think critically about every line of code and remember to refactor continuously. Test, test and test some more.

While building software, there are two important principles that a pragmatic programmer always observes. These are avoiding duplication at all costs and avoid splitting a piece of knowledge across multiple components. Failing to observe these two principles will invariably bring you headaches in the future as the source code spirals out of control.

This is the way of the pragmatic programmer.

By the way, there are loads of tips in the book that will not only benefit you now, but for as long you write code.

(1) Dictionary.com, “pragmatic,” in Online Etymology Dictionary. Source location: Douglas Harper, Historian. http://dictionary.reference.com/browse/pragmatic. Available: http://dictionary.reference.com. Accessed: June 13, 2010.

Ever received one of those emails that you just have to keep somewhere? That snippet of source code that might come in handy? That chocolate muffin recipe? Why not put all of it into your wiki?

My personal choice of this kind of wiki is TiddlyWiki. Simply because all of the content is in a single HTML file. Fan of Getting Things Done? TiddlyWiki can easily be configured to support the Getting Things Done methodology. Have a look at d-cubed for example.

Bear in mind that it has a learning curve to it, but if you are willing to stick to it you will surely reap the benefits.

Some of the features include:

• Tagging
• Searching
• Text formatting, including support for monospace
• Highlighting
• Block quotes
• Tables
• Headers
• Save with backups
• RSS feeds

I would suggest the following plugins to really spice-up TiddlyWiki:

• YourSearch
• CheckBox
• AttachFile
• Calendar

Check out TiddlyTools and TiddlyVault for other plugins. It supports themes, which can be downloaded from TiddlyThemes. There is also a great cheat sheat available.

From this quote, it is evident that if morale decreases, people will no longer pull together in pursuit of the common purpose. Following from that, we can then say that morale is the glue that keeps people united and focused on the given task.

Sustaining a healthy level of morale in the workplace should be one of the primary concerns of managers. I’d like to think that every workplace has a set of morale pumps that help to maintain a certain level of morale, whether it be great coffee, job security or an energizing work culture, which contribute to keeping employees focused and united.

In the current economic environment where most businesses have to consider cutting costs on most levels, be careful when cutting costs on the morale pumps. Consider the cost of reducing and taking away that which maintains this level of morale. I think investing into keeping morale high is probably more needed now than ever before.

Here are some factors that influence morale in the workplace, either positively or negatively :

• Job security;
• Management style;
• Staff feeling that their contribution is valued by their employer;
• Realistic opportunities for merit-based promotion;
• Team composition;
• The work culture;
• Compensation;
• Recognition and rewards;
• Work that isn’t challenging;
• Limited growth opportunities;
• Fun environment to work in

One more favourite tool that I have come to like a great deal is OneNote 2008. Straight from the box I got used to the ease and the flexibility that it provides to capture and layout my notes. It is almost easier than a notebook.

Currently I am designing a website and the way that OneNote helped me organize the research is amazing. Not only that, it has a very handy screen capturing utility that can be invoked at any time using the Windows Key + S.

It also allows you to capture side notes at any point in time by pressing Windows Key + N. Very handy stuff indeed.

Some features of OneNote 2008 includes:

• Gathering your notes and information in one place;
• Automatic saving of your notebooks;
  
• Organize information in the manner that you want with complete freedom;
• Prioritization and management of your tasks and your to-do list more efficiently;
• Themed notebook pages;
• Sharing of your notebooks;
• Text highlighting;
• Using pens on the note surface;
• Automatic source linking when pasting information;
  
• etc…
  

I think I might have abondoned my Moleskine for good after discovering OneNote.

The feature list and flexibility of this web application is outstanding. For starters, it integrates smoothly with the concepts of Getting Things Done. Here is a post on how to set it up for GTD.

You can add tasks from almost anywhere, be it mobile, Launchy, e-mail or even their own website. There are also a couple of ways to interact with your task lists, such as:

• Remember the Milk Tool – Lets you add tasks rapidly from the system tray
• RememberTheMilk provider for Thunderbird – Lets you access tasks from within Thunderbird
• Add tasks with Launchy – Lets you add tasks directly from Launchy
• Embedding tasks on your desktop – View your tasks embedded into your desktop
• Or, write your own, with their extensive API

For offline access it uses Google Gears, so that you can continue to work with your tasks offline, and then synchronize when you are online again!

Some of the features that just make it that much better, is that it supports:

• SMS reminders
• E-mail reminders
• Recurring tasks
• Multiple lists
• Tags for tasks
• Weekly planners
• Locations integrated with Google Maps
• Synchronize to BlackBerry and Windows Mobile
• Notes on tasks
• Contacts with whom tasks can be shared
• etc…

Well done to the Australian Team!

]]> http://thirdshelf.com/2008/03/30/productivity-heatmap/feed/ 0 Sydney Heatmap