Skip to main content

Home/ Agilesparks/ Group items tagged evolutionary design

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

James Shore: The Art of Agile Development: Incremental Design and Architecture - 1 views

www.jamesshore.com/...incremental_design.html

eng-practices-list james shore evolutionary design agilearchitecture

shared by Yuval Yeret on 10 Dec 14 - No Cached
  • when you first create a design element—whether it's a new method, a new class, or a new architecture—be completely specific. Create a simple design that solves only the problem you face at the moment, no matter how easy it may seem to solve more general problems
  • Waiting to create abstractions will enable you to create designs that are simple and powerful.
  • The second time you work with a design element, modify the design to make it more general—but only general enough to solve the two problems it needs to solve. Next, review the design and make improvements. Simplify and clarify the code. The third time you work with a design element, generalize it further—but again, just enough to solve the three problems at hand. A small tweak to the design is usually enough. It will be pretty general at this point. Again, review the design, simplify, and clarify. Continue this pattern. By the fourth or fifth time you work with a design element—be it a method, a class, or something bigger—you'll typically find that its abstraction is perfect for your needs. Best of all, because you allowed practical needs to drive your design, it will be simple yet powerful.
  • ...12 more annotations...
  • This is difficult! Experienced programmers think in abstractions. In fact, the ability to think in abstractions is often a sign of a good programmer. Coding for one specific scenario will seem strange, even unprofessional.
  • Continuous Design Incremental design initially creates every design element—method, class, namespace, or even architecture—to solve a specific problem. Additional customer requests guide the incremental evolution of the design. This requires continuous attention to the design, albeit at different time-scales. Methods evolve in minutes; architectures evolve over months. No matter what level of design you're looking at, the design tends to improve in bursts. Typically, you'll implement code into the existing design for several cycles, making minor changes as you go. Then something will give you an idea for a new design approach, requiring a series of refactorings to support it. [Evans] calls this a breakthrough (see Figure). Breakthroughs happen at all levels of the design, from methods to architectures.
  • Don't let design discussions turn into long, drawn-out disagreements. Follow the ten-minute rule: if you disagree on a design direction for ten minutes, try one and see how it works in practice. If you have a particularly strong disagreement, split up and try both as spike solutions. Nothing clarifies a design issue like working code.
  • Risk-Driven Architecture Architecture may seem too essential not to design up front. Some problems do seem too expensive to solve incrementally, but I've found that nearly everything is easy to change if you eliminate duplication and embrace simplicity. Common thought is that distributed processing, persistence, internationalization, security, and transaction structure are so complex that you must consider them from the start of your project. I disagree; I've dealt with all of them incrementally [Shore 2004a]. Two issues that remain difficult to change are choice of programming language and platform. I wouldn't want to make those decisions incrementally!
    • Yuval Yeret
      Yuval Yeret on 12 Jan 15
       
      Possible exercise - Try to come up with various things that are risky to YAGNI. And then order them according to level of risk. Use the examples here to seed the list
  • Limit your efforts to improving your existing design
  • To apply risk-driven architecture, consider what it is about your design that concerns you and eliminate duplication around those concepts
  • Your power lies in your ability to chooose which refactorings to work on. Although it would be inappropriate to implement features your customers haven't asked for, you can direct your refactoring efforts towards reducing risk. Anything that improves the current design is okay—so choose improvements that also reduce future risk.
  • design is so important in XP that we do it all the time
  • Don't try to use incremental design without a commitment to continuous daily improvement (in XP terms, merciless refactoring.) This requires self-discipline and a strong desire for high-quality code from at least one team member. Because nobody can do that all the time, pair programming, collective code ownership, energized work, and slack are important support mechanisms.
  • Test-driven development is also important for incremental design. Its explicit refactoring step, repeated every few minutes, gives pairs continual opportunities to stop and make design improvements. Pair programming helps in this area, too, by making sure that half of the team's programmers—as navigators—always have an opportunity to consider design improvements.
  • Alternatives If you are uncomfortable with XP's approach to incremental design, you can hedge your bets by combining it with up-front design. Start with an up-front design stage and then commit completely to XP-style incremental design. Although it will delay the start of your first iteration (and may require some up-front requirements work, too), this approach has the advantage of providing a safety net without incurring too much risk.
Yuval Yeret

Is Design Dead? - 0 views

www.martinfowler.com/...designDead.html

eng-practices-list

shared by Yuval Yeret on 10 Dec 14 - Cached
  • In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the "code and fix" nightmare, where the bugs become exponentially more expensive to fix as the project goes on
  • the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it's impossible to think through all the issues that you need to deal with when you are programming. So it's inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn't gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There's usually a quicker fix and time pressure. Hence entropy (again).
  • One way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect. A design can be planned to deal with areas of volatility, but while that will help for foreseen requirements changes, it won't help (and can hurt) for unforeseen changes. So you have to understand the requirements well enough to separate the volatile areas, and my observation is that this is very hard. Now some of these requirements problems are due to not understanding requirements clearly enough. So a lot of people focus on requirements engineering processes to get better requirements in the hope that this will prevent the need to change the design later on. But even this direction is one that may not lead to a cure. Many unforeseen requirements changes occur due to changes in the business. Those can't be prevented, however careful your requirements engineering process.
  • ...6 more annotations...
  • The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work. This flattening is both enabled by XP and exploited by XP. This is part of the coupling of the XP practices: specifically you can't do those parts of XP that exploit the flattened curve without doing those things that enable the flattening. This is a common source of the controversy over XP. Many people criticize the exploitation without understanding the enabling. Often the criticisms stem from critics' own experience where they didn't do the enabling practices that allow the exploiting practices to work. As a result they got burned and when they see XP they remember the fire.
  • XP's advice is that you not build flexible components and frameworks for the first case that needs that functionality. Let these structures grow as they are needed. If I want a Money class today that handles addition but not multiplication then I build only addition into the Money class. Even if I'm sure I'll need multiplication in the next iteration, and understand how to do it easily, and think it'll be really quick to do, I'll still leave it till that next iteration.
  • You don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to add it because it increases the cost of modification even if it costs nothing to put in. However you can only sensibly behave this way when you are using XP, or a similar technique that lowers the cost of change.
  • My advice to XPers using patterns would be Invest time in learning about patterns Concentrate on when to apply the pattern (not too early) Concentrate on how to implement the pattern in its simplest form first, then add complexity later. If you put a pattern in, and later realize that it isn't pulling its weight - don't be afraid to take it out again.
  • begin by assessing what the likely architecture is. If you see a large amount of data with multiple users, go ahead and use a database from day 1. If you see complex business logic, put in a domain model. However in deference to the gods of YAGNI, when in doubt err on the side of simplicity. Also be ready to simplify your architecture as soon as you see that part of the architecture isn't adding anything.
  • XP design looks for the following skills A constant desire to keep code as clear and simple as possible Refactoring skills so you can confidently make improvements whenever you see the need. A good knowledge of patterns: not just the solutions but also appreciating when to use them and how to evolve into them. Designing with an eye to future changes, knowing that decisions taken now will have to be changed in the future. Knowing how to communicate the design to the people who need to understand it, using code, diagrams and above all: conversation.
Yuval Yeret

FDA Endorses Agile: What Does that Mean? | MDDI Medical Device and Diagnostic Industry ... - 0 views

www.mddionline.com/...-endorses-agile-what-does-mean

medical agile case study

shared by Yuval Yeret on 08 Dec 14 - No Cached
  • The guidance covers several key topics such as documentation, evolutionary design and architecture, traceability, verification and validation, managing changes and “done” criteria. the document has become a must-have reference document for every professional implementing Agile to develop medical devices software. It focuses on providing the following:
1 - 5 of 5
Showing 20▼ items per page