Agile Design

How can you design the software which is built in tiny increments?

How can you ensure that the software has a good structure which is flexible, maintainable and reusable?

ARE'NT YOU GOING TO MISS THE BIG PICTURE?

Not really! In an agile team, the big picture evolves along with the software.

How? With each iteration, the team improves the design of the system so that it is as good as it can be for the system as it is now. They focus on the current structure of the system, making it as good as it can be.

How do we know if the design of software is good?

Avoiding these following symptoms of poor design (design smells) should be a way.

1. Rigidity - The design is hard to change.
2. Fragility - The design is easy to break.
3. Immobility - The design is hard to reuse.
4. Viscosity - It is hard to do the right thing.
5. Needless Complexity - Overdesign
6. Needless Repetition - Mouse abuse
7. Opacity - Disorganized expression

These symptoms are similar in nature to code smells, but they are at a higher level. They are smells that pervade the overall structure of the software rather than a small section of code.

How to avoid design smells?

The principles of object-oriented design that help developers eliminate design smells and build the best designs for the current set of features.

1. SRP - The Single Responsibility Principle
2. OCP - The Open-Closed Principle
3. LSP - The Liskov Substitution Principle
4. DIP - The Dependency Inversion Principle
5. ISP - The Interface Segregation Principle

These principles are not the product of a single mind, but they represent the integration of the thoughts and writings of a large number of software developers and researchers.

Agile teams apply principles to remove smells. They don't apply principles when there are no smells.

Often, a design smell is caused by the violation of one or more of the principles.

Principles are not a perfume to be liberally scattered all over the system. Overconformance to the principles leads to the design smell of Needless Complexity.

Reference:
Image result for agile software development book

Image result for agile software development book

Robert C.Martin, Agile Software Development, Principles, Patterns, and Practices; Section 2, Agile Design.

Comments

BIRT - Fix the size of an image

I use a dynamic image as a logo my report in pdf. At the beginning, I use table to align the logo in left or right. I meet a problem with some images with a large width or height. My customer requires that the logo should be displayed in original size. These following steps solves my problem: 1. Use Grid instead of Table 2. Set Grid "Height" is 100% and "Width" is blank 3. Set "Fit to container" for images are "true". Download the the template here .

When we don't see the sun, we see other stars

What are your motivations for creativity? - I want to make a change. - It makes me happy! It is a need of my mind. How to be creative for a thing? There are two steps: - See the thing as every people see it - Think about a new different thing from it How to think about a new different thing? There are two ways: - Forget all things you have already known. - A whack on the side of your head. ;) This was what I have learned from the following great book: source: Amazon.com Well! A physical whack on the side of your head is needed sometimes but the meaning behind is that you need to break these 9 following locks on your mind. Remove them! The lock #1: "The correct answer" We all learn from schools that there is only one correct answer to a question. For example, a proposition is only true or false in Algebra. In reality, there are always some answers to a question basing on a point of view. For example, number 6 becomes number 9 if you look it ...

The HelloWorld example of JSF 2.2 with Myfaces

I just did by myself create a very simple app "HelloWorld" of JSF 2.2 with a concrete implementation Myfaces that we can use it later on for our further JSF trying out. I attached the source code link at the end part. Just follow these steps below: 1. Create a Maven project in Eclipse (Kepler) with a simple Java web application archetype "maven-archetype-webapp". Maven should be the best choice for managing the dependencies , so far. JSF is a web framework that is the reason why I chose the mentioned archetype for my example. 2. Import dependencies for JSF implementation - Myfaces (v2.2.10) into file pom.xml . The following code that is easy to find from http://mvnrepository.com/ with key words "myfaces". <dependency> <groupId>org.apache.myfaces.core</groupId> <artifactId>myfaces-api</artifactId> <version>2.2.10</version> </dependency> <dependency> <groupId>org.apache.myfaces.core<...

Styling Sort Icons Using Font Awesome for Primefaces' Data Table

So far, Primefaces has used image sprites for displaying the sort icons. This leads to a problem if we want to make a different style for these icons; for example, I would make the icon "arrow up" more blurry at the first time the table loading because I want to highlight the icon "arrow down". I found a way that I can replace these icons with Font Awesome icons. We will use "CSS Pseudo-classes" to achieve it. The hardest thing here is that we should handle displaying icons in different cases. There is a case both "arrow up" and "arrow down" showing and other case is only one of these icons is shown. .ui-sortable-column-icon.ui-icon.ui-icon-carat-2-n-s { background-image: none; margin-left: 5px; font-size: 1.1666em; position: relative; } .ui-sortable-column-icon.ui-icon.ui-icon-carat-2-n-s:not(.ui-icon-triangle-1-s)::before { content: "\f106"; font-family: "FontAwesome"; position: ...

Avoiding Time-Wasting Pitfalls in Agile Estimation

If you do Scrum at work, you might be very familiar to the estimation in Planning 1 . My PO has once complained to my team that why it took too long for estimating just a story. Wasting time results in the planning timebox is violated. I give you some advice from my experience: Estimation is estimation, not measure. When you read some requirements, you see some risks but you actually don't know how complicated it will be. Don't try to influence the others by explaining how to do it in too detail. Just keep in mind that you know the business domain pertaining to customer needs and estimate how much effort you will spend for it. The effort should be compared to your baseline one that you use for a simple requirement. The bottom line is we do "relative estimation", not absolute estimation. For example, you are asked to estimate the height of a building. Basically, you just need to answer "how many times higher is the build than your height"; you do...

vhandit

Search This Blog