avoiding software insanity

Download Avoiding Software Insanity

Post on 27-May-2015




0 download

Embed Size (px)


  • 1. Avoiding Software InsanityJoseph NaveenExtended Enterprise Pte Ltd.,20:21 1

2. Code Quality?Nice to have, but we can address that later Does that sound familiar? Interactive poll: Do you have binding rules for code quality? Is your architecture defined in a formal way? Do you measure quality rule violations on a daily base? Do you measure architecture violations on a daily base? Does quality management happen at the end of development? Do you think, that more needs to be done in that area and that this would be beneficial for the team and the company?24.04.122 3. Part I: Well Known Symptoms of Complexity20:21 3 4. What is Software Entropy?The tendency for software, over time, to become difficult and costly tomaintain.A software system that undergoes continuous change, such as havingnew functionality added to its original design, will eventually become morecomplex and can become disorganized as it grows, losing its originaldesign structure.20:21 4 5. Erosion of Architecture Symptoms (Robert C. Martin)Rigidity The system is hard to change because every changeforces many other changes.Fragility Changes cause the system to break in conceptuallyunrelated places.Immobility Its hard to disentangle the system into reusablecomponents.Viscosity Doing things right is harder than doing things wrong.Opacity It is hard to read and understand. It does not expressits intent well.Overall: The software starts to rot like a bad piece of meat20:21 5 6. Erosion of Architecture ReasonsSystem knowledge and skills are not evenly distributedComplexity grows faster than system sizeUnwanted dependencies are created without being noticedCoupling and complexity are growing quickly. When you realizeit, it is often too lateMost projects dont measure quality on a regular baseManagement considers software as a black boxQuality measurement is done at the end of developmentTime pressure is always a good excuse to sacrifice structureThe Law of Entropy?20:21 6 7. Part II: Technical Quality24.04.127 8. What is Technical QualityTechnical quality of software can be defined as the level of conformance ofa software system to a set of rules and guidelines derived from commonsense and best practices. Those rules should cover software architecture,programming in general, testing and coding style.Technical quality affects: Testability, Expandability, Maintainability, ComprehensibilityIt cannot be achieved by testing onlyTechnical quality has the following aspects Architecture and dependency structure of the code Software metrics Common sense coding rules Test coverage24.04.128 9. Cost of Structural Erosion / Technical Debt20:21 9 10. Structure vs. DefectsStructure vs. Time to Change Structure vs. Cost to Change24.04.12Courtesy: NIST 10 11. How to Measure Technical QualityArchitectureMeasure number of dependencies violating architecture rulesStructureMeasure size and coupling of package cycle groups in relation to the size of thesystemMetricsDefine a reasonably (small) number of metric thresholds and measure thenumber of threshold violationsCoding rulesUse automated rule checkers and configure a reasonable set of guidelines andrules. Measure number of rule violationsTest CoverageRun your unit tests with a coverage tool to measure the test coverage. Focusefforts to improve coverage on complex code24.04.12 11 12. How to model Architecture Your System Natural subsystems User InterfaceCustomerContractsCommon UserBusiness LogicData Access Step 1: Cut horizontally into Layers Step 2: Cut vertically into vertical slices by functional aspects Step 3: Defines the rules of engagement20:21 12 13. 24.04.12 13 14. Cyclic dependencies are evil"Guideline: No Cycles between Packages. If a group of packages havecyclic dependency then they may need to be treated as one largerpackage in terms of a release unit. This is undesirable becausereleasing larger packages (or package aggregates) increases thelikelihood of affecting something." [AUP]"The dependencies between packages must not form cycles." [ASD]"Cyclic physical dependencies among components inhibitunderstanding, testing and reuse. Every directed a-cyclic graph can beassigned unique level numbers; a graph with cycles cannot. A physicaldependency graph that can be assigned unique level numbers is said tobe levelizable. In most real-world situations, large designs must belevelizable if they are to be tested effectively. Independent testingreduces part of the risk associated with software integration " [LSD] 15. How to measure couplingACD = Average Component DependencyNCCD: normalized cumulated component dependencyGraph 2 (CCD=19)Graph 1 (CCD=23)ACD = 3.29 ACD = 2.7120:2115 16. Example : Cyclic DependencyPresentation ModelMain AlarmClock AlarmHandlerAlarmToConsole AlarmToFile 17. Breaking the Cycle PresentationModel Main AlarmClock AlarmHandler IAlarmHandlerAlarmToConsoleAlarmToFile 18. Example : Another Cyclic DependencyOrderCustomer Order__________________CustomerCustomer cust; ___________________ Order[] listOrders() { } 19. Example : Breaking the Cycle Order CustomerOrder __________________Customer cust;Customerstatic Order[] listOrders(Customer c) { } ___________________ 20. Structural Debt IndexThis metric measures structural erosion by analyzing cyclicpackage dependencies. Very good for tracking project health.24.04.12 20 21. Part III: How to Create a Master Piece ?24.04.1221 22. Improvement requires AwarenessSix Sigma for Software24.04.1222 23. Measurable Quality must be a Process Goal You cant reach high quality if you do not measure it (daily !) It is also of no use if you do measure, but dont use the measurements (why do I have to mention that ??) Quality as a goal must be backed an enforced by the management (requiring more than just getting the job done) Things will always get worse, before they get better (getting rid of old habits is always difficult) Its all about people, processes and tools (in that order) But it also does not work without tools the process must be automated as much as possible Potential gains are tremendous Start simple fewer rules are better24.04.12 23 24. Some Simple Rules for a MasterpieceRule 1:Define a cycle free logical architecture down to the level of subsystemsand a strict and consistent package naming conventionRule 2:Do not allow cyclic dependencies between different packagesRule 3:Keep the relative ACD low (< 7% for 500 compilation units, NCCD < 6)Rule 4:Limit the size of Java files (700 LOC is a reasonable value)Rule 5:Limit the cyclomatic complexity of methods (e.g. 15)Rule 6:Limit the size of a Java package (e.g. less than 50 types)20:21 2005-2011,24 25. Designing Quality Software RefcardDownload from www.ext-ent.com24.04.1225 2005-2011, 26. Relevant White-Papers:Download from www.ext-ent.com24.04.12 26 2005-2011, 27. QUESTIONS?Contact Joseph Naveenjoseph@ext-ent.comwww.ext-ent.com+91900303502520:2127