10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
What Drives Design?
Presented by
Rebecca Wirfs-Brock
on
Jan 24, 2009
Length 01:18:11
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
In this presentation held during OOPSLA 2008, Rebecca Wirfs-Brock reviews various forms of driven development in order to understand the principles and values of several design practices used today. By comparing them, a designer will get a broader view over design and will better understand which design practice is more appropriate for him.
Bio
Rebecca Wirfs-Brock invented the way of thinking about objects known as Responsibility-Driven Design. She is lead author of the classic Designing Object-Oriented Software, and Object Design: Roles, Responsibilities and Collaborations. She is the design columnist for IEEE Software and past board member of the Agile Alliance.
About the conference
Starting in 1986, OOPSLA Conference has proven to be the cradle of many techniques and methodologies that have become mainstream over the years: OOP, Patterns, AOP, XP, Unit Testing, UML, Wiki, and Refactoring. Gaining its prestige with 3 academic tracks, OOPSLA Conference has managed to attract researchers, educators and developers every year. The event is sponsored by ACM.
In this presentation held during OOPSLA 2008, Rebecca Wirfs-Brock reviews various forms of driven development in order to understand the principles and values of several design practices used today. By comparing them, a designer will get a broader view over design and will better understand which design practice is more appropriate for him.
Bio
Rebecca Wirfs-Brock invented the way of thinking about objects known as Responsibility-Driven Design. She is lead author of the classic Designing Object-Oriented Software, and Object Design: Roles, Responsibilities and Collaborations. She is the design columnist for IEEE Software and past board member of the Agile Alliance.
About the conference
Starting in 1986, OOPSLA Conference has proven to be the cradle of many techniques and methodologies that have become mainstream over the years: OOP, Patterns, AOP, XP, Unit Testing, UML, Wiki, and Refactoring. Gaining its prestige with 3 academic tracks, OOPSLA Conference has managed to attract researchers, educators and developers every year. The event is sponsored by ACM.
RelatedVendorContent
A practical guide to choosing the right agile tools
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Requirements?
by
Mileta Cekovic
Posted
Re: Requirements?
by
Rebecca Wirfs-Brock
Posted
Re: Requirements?
by
Ricardo Limon
Posted
Design principles
by
Anders Sjöberg
Posted
Re: Design principles
by
Rebecca Wirfs-Brock
Posted
-
Funny, I thought that requirements are the main driving force for the design.
Author made me fill like I was blind all these years...
Kidding aside, all these forces author mentions are secondary forces, while requirements should be the primary and the commanding force. -
Of course requirements drive design, but in this talk I wanted to explore the values and practices that various "driven" methods have, their roots, and what they share in common and where they conflict.
It is all too simple to say "requirements drive design" and be done with it. What I am constantly amazed at are the myriad different ways people tackle software problems and all those subtle choices they make when crafting their solutions. I think it is good to reflect from time to time on why we do software design the way we do as well as what we personally value. I've just written a blog posting that might spur some discussion on this. www.wirfs-brock.com/2009/01/what-drives-design.... -
Curious thing that organizations sometimes missuse the word requirement, making it very difficult to understand the real needs. I have come across too many self acclaimed System Architects that "drive design" by requirement.
-
From Rebeccas blog; "But what then drives the way you approach your work?"
To me it is about implementing the design principles that Robert C Martin writes about in this article; www.objectmentor.com/resources/articles/Princip... . As he writes in the article I think it will help me create something which is "...flexible, robust, reusable, and developable.".
Is it a common and clear goal for all of the the design drivers to implement those principles? -
I think that most of the people who have advocated xDD approaches and even talk about use of patterns or refactoring techniques are all trying to get at SOLID (or solid) design. They just have different emphasis and also a slightly different set of values. For example, Domain Driven Design from Eric Evans talks a lot about capturing the "ubiquitous" language of the domain and representing it in domain objects. While Robert Martin's principles lead you more towards well-structured organizations of objects and good use of inheritance and interfaces.
Most designers and design approaches I know wouldn't argue much w/ Martin's principles.
5 comments
Watch Thread Reply