The Project Date – Kill It!

Tom DeMarco recently published an article in IEEE Software suggesting he may have been wrong in stating that metrics are a requirement for successful software development.

He questions his timeless statement, “You can’t control what you can’t measure”, realizing that control is not the most important aspect of a software project.

But there was a small section on the second page of the article that was especially thought provoking. DeMarco makes the following hypothetical statement.

“I have a finish date in mind, and I’m not even going to share it with you. When I come in one day and tell you the project will end in one week, you  have to be ready to package up and deliver what you’ve got as the final product.”

Imagine for a moment how this would change the software development landscape. So much of software development is dominated by that single date – the date the project must be finished. It dictates most of what we do, and when we do it. It’s typically one of the first things we know about the project – when we need to be finished. The date drives the project. Every software development team strives to finish by that preconceived date, often making significant compromises along the way. Sadly, these dates are often pulled out of thin air (the CEO’s birthday, perhaps?), yet are written in stone as the date we have to be done.

The date makes agility counter-intuitive and encourages development practices that we know don’t work. Removing the date makes agility intuitive. Seems kinda far-fetched, heh? I’m not so sure. Having thought about this for a while, I’m not convinced it’s too far away from the notion of internal and external releases.

Imagine the profound affect it would have on how we went about developing software if there was no date. Imagine if that date was unknown to us. It could be tomorrow or it could be a year from tomorrow. Imagine how we’d be forced to change how we work. We’d be forced to emphasize software quality throughout the development process. We’d be forced to ensure we always have a functional product. It might go something like this.

We kickstart the project by hosting a meeting with our customers. In this meeting, we establish some high level goals for what the system must do. Basically, a sketch. We’ll call this our initial project plan. The development team is already busy setting up their development infrastructure – the version control repository, the IDE, test harnesses, automated build script, some code inspection tools, the datasources, and the important frameworks we’ll use to develop the system. We don’t have time for waste, so we only do what’s going to provide value.

At the same time, we put together some wireframes and mock-ups, and a week after that first meeting, we share these mock-ups with our customers. They may like them or they may hate them. For those they like, we start implementation. We know we must move quickly, but we must be careful to ensure we have a functional product at all times. If the build fails, we have to fix it. We can’t let quality degrade beneath acceptable levels. We have to be ready at all times to package the system, and make it available to our customer. We have to establish our cadence – our sustainable pace.

It’s obvious that we have to show value early and often. Our customer can demand the system anytime they wish. They can also cancel the project at anytime, as well. The only way to ensure the future of the project is to demonstrate value. Intense and frequent collaboration is in our best interest. It’s in the best interest of the project, too!

To afford ourselves the slightest possibility to deliver the system in one week after the customer’s request, we have to test early. Quality must be baked in from day one. We have to ensure we can package and deploy the system quickly. We must have the ability to perform the entire lifecycle on a moment’s notice. We can’t wait to run our load tests, capacity tests, or failover tests. It’s in our best interest to do this as often as we possibly can. To ensure we have the ability to test as often as we’d like, we’ll want to automate as much of this as possible.

In general, we only have time to perform practices that directly contribute to the delivery of software. Estimates? We don’t have time to estimate, nor is there a reason to. The business gives us their highest priority scenarios, and we implement them to the best of our ability. If they like the direction we’re headed, we keep funding. If not, the project’s over. And when the customer feels they have a system that’s going to provide value, they get it when they want it. Requirements signoff? We don’t have time to signoff on requirements and then resist change. In this world, it’s in our best interest to serve the customer, embrace change, and prove that we can respond to their needs quickly.

Doesn’t that sound productive, intuitive…and fun? There are so many fascinating and amazing ways to build upon this scenario. Imagine it for a moment. How do you see it playing out. Good? Bad? Ugly?

9 thoughts on “The Project Date – Kill It!

  1. without requirement sign off is first step to hell.

    one of my project fail to roll out after monthly of development due to the indecision customer, keep changing the system scope, and flow.

    till now, they still fail to answer us the most basic question, “who is the user…”

  2. Seems good, but I would believe it would be hard for people to accept.

    The only way that most people can be convinced is that, if you can say its your cash burning the man days, how sure enough are you doing this? If you can convince you are okay with your cash with on the line, then you can make your case.

    Government projects especially have a certain date for the release. Other businesses have release date for their marketing, which probably have other different business purpose. In such case, I don’t know how you do not plan your budget to meet the requirement. Shorter period will dictate you would be burning more man days per calendar day.

  3. I think you missed a step:

    Step 0 – Deploy to production.

    The first thing to do is get “Hello World” into production. From then on, the entire process is dedicated to adding value to a working product.

    Every time I’ve built a product before deploying it, I’ve discovered problems at deploy time that should have influenced my architecture, development environment, or process. If deployment happens first, then production colors every decision that follows – as it should.

  4. Michael,

    Partially agree. But deploying to production is not always possible early in the project. There are some serious risks that must be considered. Especially if it’s not a greenfield project and is instead an update to an existing system. On large projects, it’s especially risky because systems don’t stand alone. They integrate with other systems that may have to be deployed simultaneously, may require database schema changes, and more.

    I do agree that the system must be deployed as quickly as possible, but it’s ok to deploy to an environment that is as close to production as is possible. Sometimes, that’s just the best we can do. But that’s certainly better than what the majority do – which is never deploy until the end and never prove to themselves that they can quickly deploy.

    In fact, this has always been one of the biggest obstacles I’ve seen surrounding iterative development. Teams can’t figure out what to do at the end of an iteration. It’s not always feasible to deploy to production at the end of each iteration. Nor is it necessary. But they should deploy it to a production-like environment. They should get feedback from their customers. They should do a lot of things. Sadly, they often stop short. They develop in timeboxed iterations (which are flawed, btw), but don’t follow through and realize the value of what they’re doing. It’s strange, but understandable. We’ve been told to develop iteratively. We’ve been told how to develop iteratively. But we haven’t been told how to cap off an iteration.

  5. Kirk,

    You bring up exactly the points that need to be addressed early on. And these points can only be addressed with a focus on production.

    Integration with external systems, promotion from dev to test to staging to prod, user acceptance testing … These are all high-risk concerns that must be answered up front.

    By deploy to production, I don’t necessarily mean final production hardware. But package something (*anything*) such that it can be rolled out to a new environment. And then roll it out.

    All software development (greenfield, brownfield, whatever) should be about iteratively adding value to a working system. “Hello, World” is a working system, and a perfect place to start. So put “Hello, World” into production.

Leave a Reply

Your email address will not be published.