1 / 22

Does Code Decay? Assessing the Evidence from Change Management Data

Does Code Decay? Assessing the Evidence from Change Management Data. The CISC 864 Analysis By Lionel Marks. My General Thoughts. Good paper in general Could relate to many of their points and see their validity – strong correlation to reality

georgejohnson
Download Presentation

Does Code Decay? Assessing the Evidence from Change Management Data

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Does Code Decay? Assessing the Evidence from Change Management Data The CISC 864 Analysis By Lionel Marks

  2. My General Thoughts • Good paper in general • Could relate to many of their points and see their validity – strong correlation to reality • Some definitions fuzzy – potentially weakening for thesis

  3. Agenda • Does Code Really Decay? • Evidence • General Points on Decay • Causes • Symptoms • Mathematical Equation • Relations to Other Work

  4. Does Code Really Decay? • One type is when code becomes obsolete • Important to notice the world is constantly changing • Hardware: 286, Pentium, Dual-Core Chips. Faster clock, RAM, larger hard drives, etc. • Greater opportunity, but others can leave you in the dust • e.g. No one wants to use Windows 3.x anymore, even though it will still run on old machines.

  5. Does Code Really Decay? • Features can become less popular over time • Requires new programming to be done • Decay can be represented as the difficulty in making new changes to the code. • How hard is it to make the new changes? • e.g. You want your browser to allow support for hover text bubbles. How hard is it to change your code?

  6. Evidence of Code Decay • The Span of Changes • More files covered • Good point: when have to change code in many different files, code can get more buggy and difficult to update • e.g. When I worked at IBM, and I had to change multiple files for a feature change/addition. When the span of files needed to be changed becomes too much for one feature change, you know you need to refactor.

  7. Evidence of Code Decay • Breakdown of Modularity • Clear divisions of where things start and end becomes blurred • Modules become more intertwined • Good Point: Harder to update • e.g. When you clearly know what each module is supposed to do, this is easier to maintain. But we don’t always have that clear distinction.

  8. Evidence of Code Decay • Fault Potential Rises • When you make lots of changes in a program that was once working fine with no bugs, errors are more likely to crop up during large changes to the program • Obvious: The point needed to be made for completeness.

  9. General Points on Code Decay • Code has decayed when you experience a temporal phenomenon – a change is more difficult than it used to be • This is ambiguous. “used to be” can be relative to which developer is looking at the code. Cannot be truly objective. • Possible to have increase in difficulty without decay, difficulty of the change itself could be increasing • Given our current state of affairs and how we keep increasing our complexity, not unreasonable • The code could be perfectly set for what it is currently doing that it becomes excessively difficult to add new functionality. • Architecture decayed due to inflexibility

  10. General Points on Code Decay • Software currently decaying can still rise in value • True. By adding new functionality that decays the code, you are making the program more useful for users (Windows Code) • Generally, implied that decay caused by changes in code. Not always the case. • True. Can happen by environment changing. (New versions from competitors) • The primary definition of code decay is that it is “harder than it should be” • Very ambiguous. Could not be tested objectively (Developer dependent – Expert/Sr. Dev. vs. New Programmer)

  11. Causes of Code Decay • Inappropriate Architecture • True. If you initially chose a bad architecture, it will always be hard to make changes. Not intuitive. **Even a good architecture for the now, could become bad for the later!** • Violations of Original Design Architecture • Good point! Many developer footprints. Hard to make changes. To stay with poor architecture or change? • Imprecise Requirements • Very valid. Cause you to change your system when customer says, “I didn’t want that” and you don’t want to scrap what you have done so far. Architecture becomes distorted and bent out of shape.

  12. Causes of Code Decay • Time pressure • Fact of life, but important to mention. Code written at 11:30pm to submit for a midnight deadline generally not well thought out. • Inadequate Programming Tools • True for increasingly complex SW. High expectations of knowledge of program without ability to see “the big picture” or find connections between classes can lead to lack of information to make good decisions. • Organizational Environment • Interesting point! Unhappy workers, large numbers of layoffs and re-hiring, or lack of communication can cause frustration and poorly coded work

  13. Causes of Code Decay • Programmer Variability • Fact of any organization. Different levels of programmers. Programs written by highly skilled developers sometimes are hard to read for junior developers. Cannot see architecture or plan for program. • Inadequate Change Process • Always nice to have for relatively small programs, for large ones versioning control is a must to facilitate “delta” changes in code between different developers.

  14. Symptoms of Code Decay • Excessively Complex (Bloated Code) • True too complex is bad, but at times, a little extra complexity can make changes easier later on. • History of Frequent Changes & Faults • Constantly changing your code is like having a “buggy” area. We think our changes independent from bugs, but this is a good point. • Widely Dispersed Changes • When you have to change many files, it’s very true that it is harder to make your new code bug-free. I’ve experienced this as a developer in industry.

  15. Symptoms of Code Decay • Kludges • Lazy or thoughtless coding where it may work, but is not in the appropriate place. This is a reality of coding when not everyone understands your architecture – or if it were poorly documented. • Numerous Interfaces • This can happen with different roles in a program with different privileges. Code re-use is good, but can also hurt you if not careful. Many entry points into a method is problematic because changes can cascade when you do not want them to, which creates a domino effect of changes

  16. The Mathematical Equation Important even though simple. If we can quantify things, we can then compare them objectively to others

  17. Relation to “FreeBSD Project” Paper • OSS seems to do okay, despite multiple developers’ footprints, and less formal design and architecture. Also, not as sophisticated development tools. Results suggest Linux has “decayed” and might require restructuring. • The first two hypothesis of successful OSS development revolve around minimizing “Code Decay” of code becoming too complex to continue development

  18. Relation to “FreeBSD Project” Paper • In choosing “committers”, you want the people who understand code best and know good code looks like to be committers. These are the people who will safe guard against buggy code or code that will decay. • In choosing “core developers”, one of the things you want in a person is the ability to code within the architecture and keep the code easy to understand and maintainable to prevent code decay. Want to make it easy for others to continue development on the OSS.

  19. Relation to “Evolution of Patterns of OSS Systems Communities” Paper • If the lead developer of the OSS who starts it all codes it with a poor architecture or in a sloppy fashion, the project will not take off, as other developers might decide to start fresh or not deal with the project at all • The GNU Project has a central version of code that is managed well. Core members do the bug fixing. This helps to keep down confusion of code structures, and ensures quality code. • Linux Kernel has centralized control, rest is done in “bazaar style”

  20. Relation to “Evolution of Patterns of OSS SW Systems Communities” Paper OSS Community Members • Bug Fixers, Active Developers, Core Members, and the Project Leader are all people who should watch out for Code Decay • The Passive User, Reader, and Bug Reporter, and Peripheral Developer would most likely not care about Code Decay.

  21. Conclusion • Code Decay is real, and it is important to maintain your code; otherwise, the project might run-overtime and be a lot harder to make changes to. • The paper written on Code Decay was a good one and made a fair number of valid points.

  22. Thank-you! Any questions or comments?

More Related