Archive for November, 2008

What I Want in a Process

Saturday, November 29th, 2008

I have been a part of a number of different development styles and processes.? Some were well suited for the task at hand, and others were broad strokes that were applied in the sake of either consistency or simplicity.? Still others were simply band-aids applied to address some disaster in the projects past.?

I much prefer an organization that has taken the time and effort to find and fit a development process that matches their development style as opposed to mandating down from on high the one true process.? Of course, these projects are often in conflict with the so-called “process-nazis”.?

I have encountered 2 types of “process-nazis”.? The first type is usually a new employee or project member that comes from a team or school that used the “one true process”.? This person will inevitably attempt to discredit any guidelines that are different from the process they are accustomed to simply because of their difference.

The second type is usually a believer.? These are folks who are always looking for a quick-fix to their problems.? They usually latch onto the current “in” process and promote that for every situation.? They are identified by their blind devotion to the strict tenants of whichever process they are promoting.? No impurities are allowed to pollute their vision.

I tend to avoid these “process-nazis” like the plague.? I have found that the longer I spend with them, the more sense they begin to make, until slowly the reality that each project is different begins to fade into a blurry thought that is easily swept away.? This inevitably ends in disaster.? If you have ever shipped a release that failed to even install you will understand the dangers that occur when you blindly apply processes without respect to the actual needs of the software.

This happened to me on my last project.? Our build process was essentially brought forward from the build engineer's previous project.? It emphasized speed and assumed a large QA component along with rapid turn-around? The problem was that the new project needed to emphasize perfection, because once the software was released, our customers would not be able to receive another version for weeks.? So the build process that worked perfectly when you could simply rebuild a new release at any time, failed spectacularly when the rebuild process could not occur until much later.

In hind-sight, this failure surprised no one, but at the time, no one thought to ask questions about the process.? We were all more concerned about simply having a process.? These days, I am far less worried about what the process is as opposed to why the process is the way it is.? When I encounter a new process, I try to determine why the guidelines exist.? I ask the team why they do things the way they do things.? If I see an opportunity to suggest an improvement, I will attempt to determine why the current requirements exist, and, depending on the response, I may suggest the improvement.

Chances are that if the team has already taken the time to tailor their process, they will be receptive to new ideas, especially if you take the time to determine why things are the way they are.

If the change is approached simply as “this isn't mine and so isn't right”, you will probably not make much headway, but by being pragmatic about the benefits you can likely make some substantial improvements.? Of course, most of the time, when I find a team that is interested in customizing their process, they generally have compelling reasons for each step in the process, and when they don't they are always eager to re-evaluate and re-visit any and every step.

This is what I want.

Posted in Development, Process | Comments Off

How Long Will It Take Me?

Friday, November 28th, 2008

So now that you know what do, the next question that comes up is how long will it take me?? Estimating software is notoriously difficult – a lot of people don’t think it is worthwhile because developers are often so bad at it that their estimates don’t seem to have any connection to reality.? I think this is a mistake.? The only way to get better at estimating software is to estimate how long it will take to implement different features.? Eventually, with practice and feedback, you should learn to get fairly accurate with your estimates.

Estimating tasks offers diminishing returns, which is likely why it has such a bad reputation among developers.? There is little point in attempting to accurately estimate a feature that is months away from being started.? By the time you actually begin work on that item, the environment is likely to be different enough that the original estimate is useless.?

Of course, you want some idea of how long everything will take, so I recommend running through every item and putting together a rough order-of-magnitude type estimate for each one.? Don’t spend more than a minute or two thinking about each item, the point is to just give an idea of the total length of the schedule, not to accurately estimate it.? I will usually just split the items into one of three categories:

  • Long (1+ weeks)
  • Medium (1+ days)
  • Short (1+ hours)

Once I pick a category, I can usually take a stab at the number of hours, days, or weeks.? It is often way off base, but with enough items, on average I have found it to be as accurate as any other schedule, and I don’t have to worry about specifics just yet.

Of course, now I have an idea of my overall schedule, but I need some more accurate short-term forecasting.? To do this, I select about 4 weeks worth of tasks using the rough order-of-magnitude estimates.? Usually, the items in the “Short” category are fairly accurate already, so I focus on the “Medium” and “Long” categories.? To estimate these items, I break them up into smaller and smaller tasks until I only need to provide “Short” estimates for any given task.? Add up the length of all the decomposed tasks, and you have a fairly accurate estimate of the overall task.

As an added benefit, this will force you to think of what a given task requires before you begin implementation, hopefully helping improve and refine your design.

Finally, this is an on-going process.? Every few weeks, you should revisit your tasks and re-estimate their magnitude.? As you pull items off the queue, you should be decomposing the tasks and providing accurate estimates.? This should provide you with an accurate short term (3-4 weeks) schedule, and a fuzzier long term schedule that will progressively get more accurate as your cycle progresses and you begin to understand the domain and intricacies of your design.

Posted in Best Practices, Development, Process | Comments Off

What Do I Do Now?

Friday, November 28th, 2008

Have you ever been working on a project and realized that your pile of TODO’s has far outpaced your ability to address them?? This is a common problem for projects and it can lead to all sorts of problems.? So how can you get this beast back under control and make sure that you are making progress on the things that are truly important?

Well, the first thing you have to do is make sure that all of your tasks are rated and prioritized.? I always rate items by severity first – if it is not obviously a defect I mark it as a feature and set it aside.? This first rating is always done as fast as possible.? I usually just go with my first impression – the key here is not to get it correct, you can always change it later, but rather to separate out the items that do not matter so I can focus my efforts on the items with the largest impact on the customer.?

Once I have all my defects rated, if I have any urgent items, I immediately begin work fixing those items.? The rest of the tasks can wait, but our customers should not.

Now that I have rated my features and defects, it is time to prioritize.? I usually prioritize each item based on its risk. Some things are easy to implement and others are difficult. All things being equal, you should always do the riskiest items first when your schedule is more flexible to meet any unanticipated problems. Wait until the end of your cycle, and Murphy’s law will strike you down.

With a small team, I would just send the list of items around and ask everyone to mark it if they consider it a risky or difficult feature to implement. A simple yes or no is sufficient.? Add up all the yes’es and you have your “risk assessment”, with the highest scoring items being the riskiest.

Alternatively, if you have easy access to your customer, ask them to rate the “risk” associated with each feature.? In this case, risk refers to the worst-case scenario of not having the feature or fixing the defect? – if not having something would be annoying, it is not risky. If not having the feature or fix would result in them not using your product, it is high-risk.

At this point, you have everything you need to begin assigning items from your TODO list.? Sort the items by priority and start assigning the items with the highest priority.? If items have the same priority, use the severity as a tie-breaker.? Every week or two, revisit the list and repeat this process to re-evaluate and prioritize new items.?

Using this process you can rapidly focus on the important items and maintain that focus throughout your development cycle.

Posted in Best Practices, Process | Comments Off

.NET Events (Part 3 – A Weak Solution)

Thursday, November 27th, 2008

So it has been a while since my last post, but its time to delve into solving the problem of the memory leak caused by events.?? In .NET Events (Part 2 – Problems Leak Through) I discussed some possible solutions and their shortcomings.? Fortunately for us, there is another way, and it all begins with a little known class called WeakReference.

The purpose of the WeakReference class is to hold a reference to an object without preventing the object from being garbage collected.? In order to use this, we need 2 things:

  • A “WeakDelegate” class that will wrap our event handlers up in a WeakReference so we no longer prevent the subscriber class from being garbage collected simply by subscribing to an event
  • A “WeakEvent” class that will maintain and invoke the WeakDelegates that we are wrapping our event handlers in.

Let's start by examining the WeakEvent class.? This class is made to replace the “event” keyword used to define events, so its usage is simple: 

this.NamedArgumentPublished.Invoke(this,new NamedEventArgs(name));

Finally adding and removing handlers should also be remarkably familiar: 

publisher.NamedArgumentPublished.AddHandler(this.HandleNamedArgumentPublished);

publisher.NamedArgumentPublished.RemoveHandler(this.HandleNamedArgumentPublished);

?

As you can see, the usage of the WeakEvent class is remarkably familiar, and as a bonus eliminates the need to test and avoid the race condition I discussed earlier.? So now that we have discussed how the class is used, we can peek under the hood to see how it works.

The heart and soul of the class is the WeakDelegate class I discussed earlier.? It works its magic by splitting an event handler into 2 parts:

  • The target object (the reference to the instance subscribing to the event)
  • The method information (the actual handler method)

Once it has split the event handler into those 2 parts, it stores the reference to the target object inside a WeakReference, preventing the event from keeping the target object alive.? The code to do this is handled by the constructor:

Code In Review is proudly powered by WordPress
Entries (RSS) and Comments (RSS).