Mark Gilbert's Blog

Science and technology, served light and fluffy.

Most Difficult

One of the companies that I applied to asked prospective employees to answer one of three questions, and if the team thought your answer was particularly insightful, you’d move on to the next step.  What attracted me to this company, Atomic Object in Grand Rapids, Michigan, was their fervent devotion to agile methodologies.  I have studied and read, and played with agile techniques such as test-driven development and pair programming for several years, but I haven’t had many opportunities to put those techniques into full practice on a full scale large (multi-month) development project.  Atomic Object does it daily, and that really interested me.

However, in all of my reading, I thought there was still an aspect of developing software that was really hard, and didn’t seem to be addressed well.  As it turns out, one of the three questions posed by Atomic was this one: “What is the most difficult aspect of writing software? What is the best way to address this reality of software development?”  It was this one that I selected to answer.

The vast majority of my software development experience has been in the role of a consultant.  Over the 12 years of filling that role, I’ve lost track of the number of times I’ve had my clients ask me some variation of The Question: “Can you solve my problem for X dollars and in Y time?”  Answering this question has become the single most difficult aspect of writing software.

This is an important question for the client because they don’t want to spend X dollars and Y time, and then not get their problem solved.  A development team can always answer The Question very precisely, but only after they’ve tried to solve that problem for X dollars and Y time.  However, how can they answer it before any real work has been done towards solving the problem?  Since divination was not an approved elective in my Computer Science program at WMU, I’ve been forced to find other means to answer The Question.

For the first few years of my professional career, I always thought about the problem for a few minutes, and then answered “Yes”.  After getting burned on several projects – either as the result of an unhappy client, a project budget firmly lodged in the red, or both – it began to dawn on me that perhaps I was missing an important, unspoken clause in The Question:  “and not go out of business doing it.”  Losing clients and losing money are two sure-fire ways to go out of business.

So, for the few years after that, I started doing pre-project consultations that would try to gather all of the requirements for the new system.  My thought was that if I could list up front everything that the client wanted, I could provide a better (albeit still imperfect) answer to The Question.  Perhaps then, the client would be less unhappy and my project budget less red.  While there was some benefit for both me and the client in this process, there were two main difficulties with it.

First, since the client usually had a fixed budget and/or timeframe in which to solve their problem, the dollars and days for the pre-project were inevitably included in the overall budget.  This meant the more effort we invested into figuring out the details of the problem to solve only took away from the resources available to actually solve it.

Second, even if we got through to the end of the “requirements” project with flying colors, and thought we could do the real project in the remaining time, those requirements would end up changing mid-stream.  It’s not that the client intentionally set out to rock the boat, or throw a wrench in the works, but stuff happens:

  • A key employee was left out of the initial discussions, and when they get wind of the project, they unearth critical problems in the proposed approach.
  • Something we thought would be easy from a technology-standpoint turns out to be very difficult, forcing us to change our approach.
  • The client puts the development on hold while they go through an employee restructuring, ending in the project being put onto the plate of someone who has completely new ideas on where the software should go.

The possible scenarios of what can cause change in a project goes on and on.

Over the last few years, then, I’ve looked for ways to address these “change” issues.  Agile methodologies seem to be better suited than most to handle change, and in fact expect change to occur during a project.  I especially love the process of working with the client to prioritize the tasks, and working on them in priority-order to get the highest-value ones done first, working in fixed-length time boxes to show regular progress.

Unfortunately, The Question can be brought to bear on our priority lists and our regular releases with only a slight modification: “Can you accomplish these first W tasks for X dollars and Y iterations, and not go out of business doing it?”  When change occurs, we can re-estimate, but there’s always a risk that the change will push a “critical” task out of reach of the previously approved dollars and timeframe, thus leading to an unhappy client, or a reddening budget.  Agile methodologies are great for providing visibility and feedback on progress, but they still don’t appear to be any better suited to answering The Question up front, before any real work has been done.

So, what’s the best way to address this?  Learn how to divine the future, obviously.  Short of that, I’ve begun to wonder if I’m letting the client ask a question that simply cannot be answered.  Perhaps what I need to be doing as their consultant is when they ask The Question, educate them about the futility of asking such a question, and then give them a better, more meaningful question to ask.  Whether this approach will work or not, and what The More Meaningful Question looks like remains to be seen.

Powered by Qumana

Advertisements

November 15, 2007 - Posted by | Agile

1 Comment

  1. The unfortunate answer to this question is always yes – we can meet any given requirements if the quality of the software is low enough. And often I find that this is where any development methodology falls down, as one of my old bosses used to say “everything is easy and cheap until it has to work…”
    The other drive is from management and sales to always answer “The Question” as yes and assume that the software guys can pull off a heroic effort yet again and make it all work at the end. So in my experience often the best process devolves into heroic effort when the end project squeeze happens.

    Comment by Tom Chizek | February 28, 2008


Sorry, the comment form is closed at this time.

%d bloggers like this: