C:\Fakepath\Combating Software Entropy 2

Editor's Notes

• #3: In this session we are going to talk about how to tackle inherently complex nature of a software. I am going to show you 'most important principles, tools and techniques you can use to 'combat software entropy'. Together, we will gain an insight in to the heart of the software design. We will talk about the heuristics associated with the software design and architectural patterns and practices. Intended audience of this session in-general includes all the stake holders in software development process i.e. from Developer to Architect to Project and Program Manager and even CTOs and CIOs. However I have focused specially on targeting Software and Solutions Architects, i.e. individuals or teams responsible for the overall design and architecture of the solution. So, if you consider yourself as a stake holder in Software development process then you have come to the right place. Before I proceed further I would like to request you that feel free to participate in the discussion. I am very keen to hear from you and answer your questions as we walkthrough the slides. However if we run out of time, which tends to happen a lot :), then I should be available at the community lounge to answer your questions.
• #5: Lets get rolling then, shall we?Heres an agenda:
• #6: Using the term software in its broadest possible sense.There are two broad categories that software development falls into. First and the foremost is the 'Writing new code' classification. - Use-Case 1: Writing new code In this scenario we are mandated to develop new systems, mostly from the scratch but usually using some existing pieces of code e.g. Class libraries, frameworks, services etc etc. In this scenario we have more freedom and control over design and we can implement patterns and practices the way we would like it to be. Generally speaking, we are trying to solve real world problems, like business automation, weather forecasting, algorithmic trading etc etc. There is an inherent disconnect between the real world and our software programming model and that very fact is at the heart of software complexity. - Use-Case 2: Now, how many time do we get to write new software? Lets do a show of hands here. I am guessing that most of the time we end up working on existing code bases, where we have to - find that tormenting bug and fix it. - add a new exciting feature - and if you are lucky or unlucky like me then review it and refactor it so that i can handle change in a better way This scenario is complex because. 1- We generally find it difficult to understand some one else’s code 2- We believe ‘we would have done it in a different/better way’ 3- 2 is true even if we ourselves were the author of that code few years back
• #7: As Architects how do we identify the good, the bad and the ugly of Software Design.For that perhaps we need some metrics such that we can always measure and identify which side of the fence our software belongs to.
• #8: How many times have you come across the code that you can qualify as a ‘bad design’? Or atlease and most commonly would have said, That’s not the way I would have done it.Before we move on. Lets agree on what's a bad design? Ok it’s a bit difficult to be exact about the metrics of bad design in software. But lets agree on some common aspects of bad design.Rigidity FragilityImmobilityCode that’s hard to change is bad… Rigid code is bad!Code that has lots of ripple effects.. A single change break lots of other code. Fragile code is bad!Code that cant be re-used… Code that cant be ‘extended’ is bad.. Immobile
• #9: Now that we know what the bad design is. Lets see how we can fix it? Would you be interested in identifying the principles and practices that will help you make sure that your design, architecture and code is not rigid, your solutions are not fragile and your frameworks are not immobile.Wouldn’t you like to have flexibility in your design, resiliency in your architecture and agility in your frameworks such that they can adapt to the ever changing business requirements.Lets drill down to each of these principles and see what can we do to fix our bad design.
• #11: If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.
• #12: What is responsibility? … It is a reason for change.We should consider each responsibility as an axis of change. The more axis of changes the more dimension effected.As a right hand rule, there should never be more than one reason for a class to change.The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought"[1].Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained --on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.
• #13: BusinessPartner
• #14: Example do demonstrate role based interfaces IVE examples
• #15: Mention ronald’s session here.
• #17: Classes should have a single responsibility or jobDevelopers should have that job in mind when they work on a classA developer should easily be able to write a block comment at the top of a class identifying its job.That comment should not have the word AND in it.As architects and leads we should be able to ask this question.. Whats the job of this class? a developer should always have this job in mind use intuitive and simple names remember! no conjunctions (ANDS)
• #18: Add an example
• #19: - “All systems change during their life cycles. This must beborne in mind when developing systems expected to last longer than the first version.” - SOFTWARE ENTITIES(CLASSES,MODULES,FUNCTIONS,ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION- Bertrand Myers in 1988It says that you should design modules that never change . When requirements change, you extend the behaviour of such modules by adding new code, not by changing old code that already works.When a single change to a program results in a cascade of changes to dependent modules,that program exhibits the undesirable attributes that we have come to associate with “bad”design. The program becomes fragile, rigid, unpredictable and unreusable. The openclosedprinciple attacks this in a very straightforward way. It says that you should designmodules that never change. When requirements change, you extend the behavior of suchmodules by adding new code, not by changing old code that already works.The modules that follow OCP have the following two characteristics:=-1. They are “Open For Extension”.This means that the behaviour of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.2. They are “Closed for Modification”.The source code of such a module is inviolate. No one is allowed to make source code changes to it.
• #21: Composabilityvsinheritence
• #25: Define degenrate methodsShow an example here.
• #29: *Uml compatible.
• #31: - Inversion of control is the basic feature of any framework in a way that frameworks are differentiated from libraries by offering the support for ‘Hollywood Principal’ (‘Don’t call us , we will call you’)- One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.--Ralph Johnson and Brian Foote
• #33: Afferent Couplings (Ca): The number of other packages that depend upon classes within the package is an indicator of the package's responsibility. -------------Show how visual studio does it.
• #34: Efferent Couplings (Ce): The number of other packages that the classes in the package depend upon is an indicator of the package's independence.
• #35: Instability (I): The ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce / (Ce + Ca). This metric is an indicator of the package's resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable package and I=1 indicating a completely instable package.
• #36: MI: http://blogs.msdn.com/fxcop/archive/2007/11/20/maintainability-index-range-and-meaning.aspx 0-100 range.20-100 is green.The maintainability index has been re-set to lie between 0 and 100.  How and why was this done?The metric originally was calculated as follows (based on the work in Carnegie Mellon University although we modified the Halstead Volume calculation a little since we don't include comments anywhere in our calculation): Maintainability Index = 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code)This meant that it ranged from 171 to an unbounded negative number.  We noticed that as code tended toward 0 it was clearly hard to maintain code and the difference between code at 0 and some negative value was not useful.   I'll post some tech ed sample code showing very low maintainability or you can try on your own code to verify.  As a result of the decreasing usefulness of the negative numbers and a desire to keep the metric as clear as possible we decided to treat all 0 or less indexes as 0 and then re-base the 171 or less range to be from 0 to 100. Thus, the formula we use is:Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)On top of that we decided to be conservative with the thresholds.  The desire was that if the index showed red then we would be saying with a high degree of confidence that there was an issue with the code.  This gave us the following thresholds (as mentioned in this blog previously):For the thresholds we decided to break down this 0-100 range 80-20 so that we kept the noise level low and only flagged code that was really suspicious. We have:0-9 = Red 10-19 = Yellow 20-100 = Green-----------------------------------------------------------------------------------------------------------------------------------------------CC: http://en.wikipedia.org/wiki/Cyclomatic_complexityCyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.Limiting complexity during developmentOne of McCabe's original applications was to limit the complexity of routines during program development; he recommended that programmers should count the complexity of the modules they are developing, and split them into smaller modules whenever the cyclomatic complexity of the module exceeded 10.[2] This practice was adopted by the NIST Structured Testing methodology, with an observation that since McCabe's original publication, the figure of 10 had received substantial corroborating evidence, but that in some circumstances it may be appropriate to relax the restriction and permit modules with a complexity as high as 15. As the methodology acknowledged that there were occasional reasons for going beyond the agreed-upon limit, it phrased its recommendation as: "For each module, either limit cyclomatic complexity to [the agreed-upon limit] or provide a written explanation of why the limit was exceeded."[5]
• #39: Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.So in a way its not just the language and the compiler and the ide itself. But the effort on the part of the designer to think and re think about these aspects and then do/refactor the design
• #40: We believe we have given you an insight into the heart of the software complexity and stability in the face of change.Now, not only you can judge your design using these principals.you can measure them quality of your design using software design metrics. What are those metrics and how do they work is beyond the scope of this discussion but definitely worth looking at.Code metrics:Maintainability IndexCyclomatic Complexity Depth of InheritenceClass Coupling http://msdn.microsoft.com/en-us/library/bb385914(VS.100).aspx VS has it,