Hinweis: Die aktuelle OOP-Konferenz 2016 finden Sie hier!
SIGS DATACOM Fachinformationen für IT-Professionals

RESPONSIBILITY:
Building Reliable Environments

München, 26. - 30. Januar 2015

Conference

Worse Is Better, for Better or for Worse

Date:29.01.2015
Time:09:00 - 10:30
Session: Do 2.1
cart

A quarter of a century ago, Richard P Gabriel, a key member of the patterns community, proposed „Worse Is Better“ to explain why some things that are designed to be pure and perfect are eclipsed by solutions that are seemingly limited and incomplete. In this talk two other members of the patterns community revisit the original premise and question, and consider that it is an approach that can still teach us something surprising and new when it comes to development practice, software architecture, Agile development and Lean thinking.

Target Audience: Architects, Developers, Project Managers, Product Managers
Prerequisites: Non-theoretical experience of software development
Level: Practicing

You will learn:
Understand a product- and architecture-centric way to think about iterative and incremental development
Appreciate the role of quality and scope management in creating successful software
Learn that there is nothing new under the sun and that many new ideas are old!

Extended Abstract:
A quarter of a century ago, Richard P Gabriel, a key member of the patterns community, proposed the thesis of "Worse Is Better" to explain why some things that are designed to be pure and perfect are eclipsed by solutions that are seemingly limited and incomplete.
This is not simply the observation that things that should be better are not, but that many solutions designed to be complete and correct fail to achieve either, and solutions developed more modestly and incrementally are more likely to be effective. The "Worse Is Better" approach is often confused with the "Good Enough Software" approach, whereas in many respects they are polar opposites: "Worse Is Better" describes working incrementally to an incomplete scope, but to a high level of intrinsic quality rather than buggy with high technical debt, which is the implication of the "Good Enough Software" approach.
In this talk two other members of the patterns community revisit the original premise and question, and consider that it is an approach that can still teach us something surprising and new when it comes to development practice, software architecture, Agile development and Lean thinking.