Monthly Archives: July 2009

The fight from the trenches

Posted on by

In war, trenches are a fortified position soldiers use to defend against enemy attacks. They help keep soldiers safer than they would be out in the open, making enemy attacks much easier to fend off. The problem with trenches is they don’t allow progress. You can’t just move a trench, you have to get out, move forward, and build another one.

Software developers often have a similar, albeit less deadly, problem. The enemy is all the inefficiencies that get developed over the course of a software development project. In order for the project to survive, it is important for developers to get in the trenches and work through the inefficiencies to keep things afloat. In order to win, the developers have to eliminate the inefficiences, which means getting out of the trenches and making progress on the root of the problem.

How many times have you dealt with customer support about a minor bug before you fix it?

How many times have you manually built and tested your application before you automate it?

How many times have you spent hours doing deployments before you make it push button?

Most inefficiencies only hurt the long term success, and not the short term. How do you eliminate them? Managers need to be in the trenches with their people. They may not do any fighting, but they have to feel the pain and understand the problems, otherwise they won’t help their team move forward.

What are your teams fighting with in the trenches?

A night of firsts: VS2010, Dynamics, Python

Posted on by

Tonight, I installed Visual Studio 2010 beta 1 for the first time. I know I am late to the game, but I had to give it a whirl since I found some free time this afternoon. One feature of .NET 4.0 I wanted to try out was the dynamic keyword with Python scripting. So, here is my first hello world program using dynamic, with the help of this walk-through.

class HelloWorldDemo:
 
    def run(self):
        return "hello world"

Here is the C# code needed to run it. Yes, I used WPF as my driver, but don’t worry about that.

...
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
 
namespace WpfWithPython
{
    public partial class Window1 : Window
    {
        ScriptRuntime py;
        public Window1()
        {
            InitializeComponent();
            py = Python.CreateRuntime();
        }
 
        private void MyBtn_Click(object sender, RoutedEventArgs e)
        {
            //Instantiate an instance of this file?!  Yes, it is weird at first.  
            // All the methods and classes in the file will be members.
            dynamic demo = py.UseFile("HelloWorldDemo.py");
 
            //This is the tricky step.  To create a new object, call it like a member...
            // I think
            dynamic instance = demo.HelloWorldDemo();
            MyText.Text = instance.run();
        }
    }
}

It took me a while to get this little bit of code working unfortunately. If you read the comments, you can see where some of my confusion was found. Overall, it is pretty awesome. I loved LINQ and I am already loving dynamic. There is something new to learn everyday. Maybe F# next…

Unfortunately, I have to say that VS2010, while pretty, is slower than 2008. And, IronPython took nearly 2 or 3 minutes to run some sample code it provided, which is crazy. If the performance problems can be overcome, then I see myself learning more Python and Ruby.

Interview/Resume Tip: Depth

Posted on by

Resumes are a necessary evil. In no way can they fully represent a person’s qualifications, but they need to come close. Resumes contain a list of skills and experiences. As an interviewer, I use a resume as the guidebook on interviewing someone. So it is important to put things that matter on there.

One key goal I have in an interview is to talk in depth on some project, concept, or technology that I am familiar with. Doing this helps me gauge how smart an interviewee is. Going in depth and asking the hard questions can be the Yes or No moment for an interview. When I continually hear answers like, Another employee worked on that technology or That was a long time ago, I can’t remember too well, I am very disheartened.

What this means is BE CAREFUL WHAT IS ON YOUR RESUME! If you don’t know much about Hibernate, be wary about putting it on your resume. I will grill you on it.

Put items on your resume that you want to talk about, and can talk about in length. It is ok to put things you are familiar with, but make sure you help direct the interviewer to the areas you are strong.

Scrum Idea: Volatility Factor

Posted on by

Over the past few months, I have been working a lot on release planning for my teams. Not only have I seen the light on its importance, but it has also helped me realize problems with my own prioritization. Each time I change my release roadmap based on additions/modifications to the backlog, I realize how hard planning for the future is.

My solution, the Volatility Factor.

Here is the scenario. You have a team with a velocity of 15. In doing their release planning, you have the next three sprints planned out. After the first sprint planning, the roadmap hasn’t changed. By the time the second sprint planning roles around, the backlog has changed by 5 points. Maybe a large scalability issue was encountered, or your largest customer requested a must have feature or they were leaving. It doesn’t matter what the reason, 33% of your next sprint has changed. This ripples down through the rest of the backlog.

For this team, they have a volatility factor of 33%.

Now, what is the point you might ask? Well, it helps you understand a few things.

  1. How accurate are your roadmaps going to be when you show them to the rest of the company?
  2. How much should you plan for future release?

This last point is very important. In the above example, I should have only planned sprint 2 for 67% capacity and sprint 3 at 33% capacity. This is until the volatility factor starts increasing. It will save time, and give a more accurate results. That way I am not planning for something that is probably not going to happen.

Is volatility a good thing or a bad thing? I don’t really know. I would like to say it is bad, and the lower the volatility the better. But, in an agile world, this volatility may be the difference between building something great, or waiting until someone else has already built it to get started. All I know is it needs to be understood.

Unfortunately, I just thought of doing this today and figured I would blog about it. I haven’t done it yet. I do think it will help expose teams that are hard to plan for and help bring those problems up with the rest of the organization if nothing else, and maybe save me a little time.

Anyone think it is a good metric to track? Or am I wasting my time?