5884RE: [scrumdevelopment] Re: design practices
- Jan 5, 2005The argument that if you know what you are doing, you can create a perfectly good software using any methodology (or even no methodology) defeats anything we say here. Given the current state of software today, this is not a very realistic or productive argument.
It is common sense that a design that has had new requirements added to it dozens of times in a principled way can be more trusted to be able to accommodate new requirements of similar kinds than a design that has never had any new requirements added to it.
From: todd [mailto:todd@...]
Sent: Wed 1/5/2005 10:53 AM
Subject: Re: [scrumdevelopment] Re: design practices
Steven Gordon wrote:
> Emergent design has other benefits over up-front design besides beingThis is a bit of FUD. There's nothing in top down design that makes it
> able to handle changing/uncertain/emergent requirements:
> 1. Emergent designs force the code to be easily changable, whereas
> top-down holistic design can easily create code that is monolithically
> dependent on the current design. Even if requirements never changed,
> implementing the system a few requirements at a time results in a
> system that will be battle tested at being able to accommodate
> additional requirements after deployment.
any more monolithic or dependent or less changeable than any other
design approach. If you know how to design your code to be testable and
changeable then it will be. And it can be far easier to add in new
requirements, depending on the nature of the new requirements. If people
add useless over complicated code that doesn't work then that's there
own issue, it's not required by any design methodology that i know of.
Nor will any design methodology prevent someone from doing stupid stuff.
- << Previous post in topic Next post in topic >>