Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Software is Like Pornography

05.20.2010
| 13412 views |
  • submit to reddit
There's a famous quote from the United States Supreme Court a few years ago. They were trying to determine what was art and what was pornography. Lawyers being what they are, they were trying to quantify what pornography was so they could write it down... encode the definition into rules. Unfortunately this is a very difficult task. One of the judges expressed his frustration by saying that he couldn't tell you what pornography was, but he knew it when he saw it (link).

Software is a lot like pornography. It's difficult to quantify and write down in the form of requirements and design documents. It's very difficult, if not impossible, to completely extract a project's requirements and details, but we keep trying. At some point we need to step back and understand the only way to really understand what software is, and what it should be, is to see it.

That's where the Agilist's time-boxed iterations (link http://agile.dzone.com/articles/hard-stop-iterations-no-where ) come into play. The goal of time-boxing is to have a product completed and ready for a demonstration in a very short period of time. In practice most teams don't have a demo each week, but some do. And it puts your team in a position of being able to show the customer the product much more quickly than our traditional timeline. And by showing the product to your customer, you can find out what it is they really meant by their original descriptions. You'll understand exactly where the words didn't work, and only seeing the project will allow you to make this evaluation.

After all, software is very difficult to write down perfectly. It's often fuzzy, the requirements change, and people aren't sure what they want. If you want to define it, you'll need to show it to your customer... it's the only way to know for sure.
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Thomas Eichberger replied on Sat, 2010/05/22 - 6:26pm

I like this argumentation. Sometimes it's necessary to show a piece of software in action to understand what it is all about.

Daniel Lourenço replied on Tue, 2010/05/25 - 8:34am

Thank you Jared for the great article. Being able to prove the true value behind the "software" produced by the delivery team is in fact one of the biggest challenges in a software project.

I agree that Agile Methodology can in fact play a key role in emphasizing the value that "software" has carved in its by the long hours of work of the development team. With intense communication among all parties and by showing a working version of the software at the end of each iteration, the business users understand the software development process and recognize how their knowledge is key in the creation of "software" with real "business value". On the other hand, the intense iteration and communication among the teams also makes the delivery team much more "business value driven", highly increasing the ability to get a successful project. This type of interaction results in software where everybody can in fact identify and quantify the true "value" - they will know when they see it.

On other thing that can play an important role in emphasizing the true value of the software is having it speaking for itself:

  • Applications should have clear "Use Cases" or "Business Workflows" that work as the documentation of the requirements themselves;
  • The source code should "document" the the business requirements and hide the underlying "business irrelevant" details - high level Model Driven Development and "Business Process Modelling" techniques can play a key role here
Thanks again for the cool article.

Daniel Lourenço

Jared Richardson replied on Tue, 2010/05/25 - 1:22pm in response to: Thomas Eichberger

Thanks Thomas. That's a very nice summary, but too short for an article. ;)

Jared Richardson replied on Tue, 2010/05/25 - 1:25pm in response to: Daniel Lourenço

Hey Daniel,

I agree completely with hiding the irrelevant details. Writing code and tests that way brings a completely different understanding to the code. I love watching people's jaws drop in shock when I help them refactor code this way.

I also agree with your comments on Use Cases, but be careful of letting the process of documenting all the use cases turn into BDUF. I like to do as little as possible up front *but as much as is needed*. If I can, I create use cases just before an iteration starts. This leaves the customer the maximum amount of time to change their minds.

Comment viewing options

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