Comments on: Agile software development, the principles. Principle 3: Deliver working software frequently https://technology.amis.nl/2007/12/02/agile-software-development-the-principles-principle-3-deliver-working-software-frequently/ Friends of Oracle and Java Wed, 27 May 2015 22:00:57 +0000 hourly 1 http://wordpress.org/?v=4.2.2 By: Dan Rudman https://technology.amis.nl/2007/12/02/agile-software-development-the-principles-principle-3-deliver-working-software-frequently/#comment-5060 Fri, 21 Dec 2007 19:01:45 +0000 http://technology.amis.nl/blog/?p=2624#comment-5060 And yet there is another principle to pay attention to in agile development: YAGNI (You Aren’t Going to Need It). You cannot start with a normalized, well-designed database from an overall perspective because you typically do not know, in the beginning, what the requirements are going to be. You have a set of things from the backlog you are going to work on and you can peek into the future to see what else MIGHT come down the pipe, but outside of that, it is irresponsible to spend time now to develop things that have not yet established themselves as requirements. So you build what makes sense now. And you do that *well* — which may mean a normalized, well-designed database for what you know now. But the odds are you will need to revisit it throughout the development of the product because new things will come up and no design can withstand the onslaught of changing requirements and new feature requests.

]]>
By: Robbrecht van Amerongen https://technology.amis.nl/2007/12/02/agile-software-development-the-principles-principle-3-deliver-working-software-frequently/#comment-5059 Thu, 06 Dec 2007 19:29:39 +0000 http://technology.amis.nl/blog/?p=2624#comment-5059 John, you are right. Working agile with frequent delivery of working software does not mean you do not have to think about the fundamental design. You have to wait for my blog #9 Continuous attention to technical excellence and good design enhances agility.

But implementing the complete correct functionality in the first iteration is hardly possible. It is better to strive at a 80% implementation of the functionality in the first delivery and converging tot final desired solution in the next deliveries. Working this way you will notice that the end-users will begin using the system before all alternative scenarios are implemented. This means that the database design will also be completed for a large part (e.g. 80%) in the first delivery and converges to the final model in the next iterations.

]]>
By: John Flack https://technology.amis.nl/2007/12/02/agile-software-development-the-principles-principle-3-deliver-working-software-frequently/#comment-5058 Mon, 03 Dec 2007 15:02:39 +0000 http://technology.amis.nl/blog/?p=2624#comment-5058 Change happens. Change is good. But, it is VERY important to put the project on a firm foundation that readily accommodates change. To me, that has to begin with a normalized, well-designed database. This cannot be created with a short-term view of just the next delivery – it must take into account the direction of future pieces of the project.

For instance, in a purchase request there are line items for the various articles being requested, but they are all part of the same request. Looking at the delivery of a sub-system to send the request through its various approvals and ending at the purchasing office, you might design this as a single purchase request object with multiple line items. But when designing the database, you must consider that the purchasing office may now want to combine items from this request with items from other requests and create several purchase orders to various suppliers. When the items arrive, they need to be distributed back to the original requesters. Obviously, purchase request line items need to be considered as separate entities so that they can be placed in a many to many relationship with order line items. You might not discover this if you are looking at the request process by itself.

]]>