1. Agile Software Development
And how Patterns and Practices constitute

2. Agenda Why and what “Agile Software Development” Writing SOLID code
Framework Design Guidelines
Design Patterns
Practices
Real life

3. Why and what “Agile Software Development”

4. Why “Agile Software Development”
Customers:
Don’t know what they need
Define requirements based on existing systems
Need to be able to change requirements even late in the process
Developers:
Don’t know what customers need
Interpret requirements based on their experience
Must deliver working software

5. Results
The Dutch government looses four up to five billions of euro’s every year!
€ a year ==
€ 1.585,49 per second
€ 296,72 per resident

6. What is “Agile Software Development”?
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight iterations throughout the development cycle.

7. Agile Manifesto Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more
The Agile Manifesto
In February 2001, 17 software developers met at the Snowbird, Utah resort, to discuss lightweight development methods. They published the Manifesto for Agile Software Development to define the approach now known as agile software development. Some of the manifesto's authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto's values and principles.

8. Writing SOLID code

9. What is SOLID code Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the "first five principles" named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design. The principles, when applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile and adaptive programming.

10. Single Responsibility Principle
A class should have only a single responsibility
Only one potential change in the software's specification should be able to affect the specification of the class
single responsibility principle
states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

11. Open/Closed Principle
Software should be open for extension, but closed for modification.
Open/Closed Principle
Abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an
abstraction. Such a module can be closed for modification since it depends upon an
abstraction that is fixed. Yet the behavior of that module can be extended by creating new
derivatives of the abstraction.

12. Liskov Substitution Principle
Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program
Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy. It is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular.

13. Interface Segregation Principle
No client should be forced to depend on methods it does not use
Many client-specific interfaces are better than one general-purpose interface
The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.

14. Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
Dependency Inversion Principle
In conventional application architecture, lower-level components are designed to be consumed by higher-level components which enable increasingly complex systems to be built. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed), thus rendering high-level modules independent of the low-level module implementation details.

15. Result of writing SOLID code
Your code will be:
Maintainable
Extensible
Reusable
Testable
To be able to response to the changes that occur in agile projects all of the above are required!

16. Framework Design Guidelines

17. Framework Design Guidelines
The Framework Design Guidelines are defined in the book “Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries” by Krzysztof Cwalina and Brad Abrams.
These guidelines can also be found at the MSDN site:
The goal of the Framework Design Guidelines is to help library designers ensure API consistency and ease of use by providing a unified programming model that is independent of the programming language used for development. We recommend that you follow these design guidelines when developing classes and components that extend the .NET Framework.
Inconsistent library design adversely affects developer productivity and discourages adoption.

18. What is described in these guidelines? (1)
Naming Guidelines Provides guidelines for naming assemblies, namespaces, types, and members in class libraries.
Type Design Guidelines Provides guidelines for using static and abstract classes, interfaces, enumerations, structures, and other types.
Member Design Guidelines Provides guidelines for designing and using properties, methods, constructors, fields, events, operators, and parameters.
Designing for Extensibility Discusses extensibility mechanisms such as subclassing, using events, virtual members, and callbacks, and explains how to choose the mechanisms that best meet your framework's requirements.

19. What is described in these guidelines? (2)
Design Guidelines for Exceptions Describes design guidelines for designing, throwing, and catching exceptions.
Usage Guidelines Describes guidelines for using common types such as arrays, attributes, and collections, supporting serialization, and overloading equality operators.
Common Design Patterns Provides guidelines for choosing and implementing dependency properties and the dispose pattern.

20. Result of writing code that aligns with the Framework Design Guidelines
It is much more likely that the resulting code will be SOLID
Your code will be much more readable and understandable by anyone that is familiar with the .NET framework
To be able to work with a development team in agile projects all of the above are required!

21. Design Patterns

22. What is a design pattern?
A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design

23. 23 basic design patterns by the GoF.
Creational
Abstract Factory, Builder, Factory Method, Prototype, Singleton
Structural
Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy
Behavioral
Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

24. Singleton
Ensure a class only has one instance, and provide a global point of access to it

25. Proxy
Provide a surrogate or placeholder for another object to control access to it

26. Chain of Responsibility
Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it

27. Result of using Design Patterns
Assists in writing SOLID code
Prevents reinventing the wheel
Speeds up development
Allows others to understand your design
Allows you to understand the designs of others
To deliver a working solution with a team of developers on every sprint all of the above are required!

28. Practices

29. What do I mean with practices?
Being a good developer
Think first, then do
Really… think first, then do
Follow the framework design guidelines
Use existing patterns where possible
Design your code (pen and paper, visio, or Visual Studio class designer)
Spent extra time on naming conventions
Test your code
Write secure code (apply STRIDE)
Think about logging / error handling
Etc.

30. Result of following these practices?
Your code will be:
Maintainable, Extensible, Reusable, Testable, Debuggable, Secure, Understandable
Allows for much faster development while maintaining decent quality
It allows for agile development!

31. Real life

32. Understanding code MembershipProvider, ProfileProvider, ClaimsProvider
HttpContext.Current, SPContext.Current
DbProviderFactories, DbProviderFactory, SqlDbConnection, OleDbConnection, SqlDataAdapter
Trace -> Listeners -> EventLogTraceListener, TextWriterTraceListener
XmlWriter.Create(…)
System.Web.UI.WebControls
SPItemEventReceiver.OnAdded … OnAdding... SPItemEventProperties.Cancel

33. Sample NewsReaderWebPart
User story defines a news reader web part that displays news from an RSS Feed

34. Issues with this design
Web Part has to many responsibilities
Get data, display the data, store properties
Testable nor extensible

35. Changes in the user story
Customer likes to display Atom feeds as well and choose a different view
Bad design requires us to change the web part and this goes against the open/closed principle of solid design
While the new NewsReaderWebPart in the design below can display multiple feed types the same issues are still there

37. Results of the previous design
Our code implements the SOLID design principles (mostly)
If the customer wants news from yet another source, we can extend our solution by creating two new objects f.e. SharePointNewsProviderFactory and SharePointNewsAdapter
If we want to implement tests, we can create a TestNewsProviderFactory and TestNewsAdapter
Anyone that knows the basic design patterns or has experience with the .NET framework can understand our solution by just looking at the class diagram and the names of the classes
By first creating this basic design we are able to generate the code in a very short amount of time

38. Sample Client Information
User story defines a web part that displays and allows for editing client information from Microsoft CRM
Initial thought was to fetch the data through BCS in order to be able to also display external lists

39. Issues with this design
Web Part has to many responsibilities again
Get data, display the data, store properties
Testable nor extensible
Web Part has a direct dependency on BCS
Calling BCS from code relies on reflection
BCS is not strongly typed

40. Progressive insight
BCS could not deliver enough performance to display external lists
Client did not actually need external lists
The web part rendered to slow

41. If it was designed like this in the first place

42. We could change the design to this

43. Or even this…

44. Conclusion
Agile development is a farce if the code is not designed with the patterns and practices in mind
If you want to be a good developer you need to know the basic patterns and the framework design guidelines
Must reads
Framework Design Guidelines
Design Patterns: Elements of Reusable Object-Oriented Software
Writing Secure Code
Code Complete 2nd Edition