Agile Zone is brought to you in partnership with:

Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

The Project Date - Kill It!

07.22.2009
| 6357 views |
  • submit to reddit

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?

From http://techdistrict.kirkk.com

Published at DZone with permission of its author, Kirk Knoernschild.
Tags:

Comments

Bruno Vernay replied on Wed, 2009/07/22 - 5:40am

It is even more profond than just the release date. It is the idea that industrial software development can be productive.

Would you prefer a well understood and mesured failure or an non-reproductible success ?

 As a side note, it is sad that IEEE site is not social friendly.The article is sell on some pages and freely downloadable on others. I couldn't find an RSS feed featuring this article.

Raging Infernoz replied on Sat, 2009/08/01 - 4:59am

That's nice, unfortunately:

  • time and resources cost money for a software development business, so have to be charged via invoices for products, or services.
  • cost plus contracts will not fly for many customers, so we have to quote them a fixed cost, and only charge extra for out-of-specifiaction changes.
  • customers often have fixed deadlines because consumer facing businesses have fixed business deadlines to meet, so variable delivery dates for software could wreck havoc with project timeline planning to meet an eventual fixed deadline e.g. having system ready and tested for the Christamas Sales, or some other major event!
  • I think it quite naive to assume you can do frequent 'heavy duty' testing, because the resources can be very costly to have, and use lots, also these tests can be very time consuming!
  • I also question how a project products can be released at any time without frequent clearly defined milestones in a project (good luck getting those agreed), this could be very difficult for a complex project, with lots of components which have to be done separately, then integrated to form intermediary or final products.

As a developer I do not like time pressures for tricky work, so like more flexiblility, however really I detest wooly 'agile' chatty development ideas and much prefer clearly agreed requirements, given it can be torture having to fight to get unambiguous requirements out of customer during a project, then have to scrap large sections of code because they can't make their damned minds up!

 

Walter Bogaardt replied on Thu, 2009/08/13 - 7:35pm in response to: Raging Infernoz

Tend to disagree with the idea that 'Heavy duty' testing is not necessary. They may or may not be heavy on resources, but it's much more costly if you release and have holes in your application that you can drive a truck through them. Customers go away and you have crapy software. There is definetly a middle ground as I don't think subject to pure test driven development is a good thing for a software either, because that makes for refactoring hell especially when you talk about agile development.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.