3 April Maintenance Reverse Engineering Ethics Cathedral and Bazaar

Dilemma Calendar Review of Online Course Evaluation System

Maintenance: the Final Chapter

Cost of Maintenance Estimates of percentage of total life cycle cost: 40% - 90% Cost of fixing a bug Requirements 1x Design 5x Coding 10x Testing 20x Delivery 200x

Problems of Maintenance Organizational Alignment with objectives Cost benefit analysis Process Impact Documentation Regression testing Technical Building software that is maintainable Professional hierarchy

Objectives of Maintenance Change over time! At release: bug-free Six months later: competitive or competition-leading features Two years later: reduce maintenance cost

Building Maintainable Software Code Well documented code Names, headers, style, … Decoupled code Documentation Architecture, design documentation, use cases, requirements, … But only if maintained!!!!!

Software Maintenance Types Adaptive maintenance: changes needed as a consequence of operation system, hardware, or DBMS changes Corrective maintenance: the identification and removal of faults in the software Perfective maintenance: changes required as a result of user requests Preventive maintenance: changes made to software to make it more maintainable

Why adaptation? Lehman’s Law (1985): if a program doesn’t adapt, it becomes increasingly useless Example: programs that didn’t adapt to the web The majority of maintenance is concerned with evolution deriving from user requested changes

Lehman’s Second Law As an evolving program changes, its structure tends to become more complex Extra resources must be devoted to preserving the semantic and simplifying the structure For most software, nothing has been done about it, so changes are increasingly more expensive and difficult

Reengineering Code gets messy over time Extreme programming re-factoring At some point, quality suffers Changes slow Fixes introducing errors Need to invest in the code! Rules as to when to rewrite a module Abstractions: variables -> methods Harder: when is REDESIGN needed?

Lehman’s Five Laws 1.The law of continuing change: A program that is used in a real-world environment necessarily must change or become less and less useful in that environment. 2.The law of increasing complexity: As an evolving program changes, its structure becomes more complex unless active efforts are made to avoid this phenomenon. 3.The law of large program evolution: Program evolution is a self-regulating process and measurement of system attributes such as size, time between releases, number of reported errors, etc., reveals statistically significant trends and invariances. 4.The law of organizational stability: Over the lifetime of a program, the rate of development of that program is approximately constant and independent of the resources devoted to system development. 5.The law of conservation of familiarity: Over the lifetime of a system, the incremental system change in each release is approximately constant. Lehman, M. and Belady, L. (1985). Program Evolution: Processes of Software Change, volume 27 of A.P.I.C. Studies in Data Processing. Academic Press.

Steps for handling a change Understand the problem Design the changes Analyze impact Implement changes Update documentation Regression test Release

Cost Benefit (Risk) Analysis Will this problem reduce the number of programs that I sell? Will this problem impact future sales? How many people will it affect? How important are the customers it will affect? Is it a “show stopper” or an annoyance?

Patches What is a patch? Quick fix that doesn’t go through the full process When should it be used? Error that is preventing use of the system Problems with use Multiple patches can be order dependent Users can barely track which ones have been applied Code version explosion Permanent fix may or may not be compatible

Legacy Systems Existing systems that are still useful May not want to invest in enhancements Future functions will use new process May not be able to easily modify Unsupported language or libraries Lack of skills No source code available!

Handling Legacy Systems Incorporation Business as usual Encapsulation Accessed from new system Adapters Wrapper around the legacy system Adapters in new system

Reverse Engineering

What is it? Discovering the technology through analysis of a program’s structure and operation Analyzing a system to identify its components and interrelationships in order to create a higher abstraction Is it legal? Associated with hackers and crackers

Fundamental Problem Understanding code with … no comments meaningless variable names no visible structure void p (int M) { int c = 2; while (c <= M) { int t = 2; boolean f = true; while (t ** 2 <= c) { if (c % t == 0) { f = false; break; } t++; } if (f) l(c); c++; } }

Reverse Engineering Lots of tools for simple translation Disassemblers, decompilers, hex editors, … How useful are these? What can they do and not do? Approaches to Understanding Source-to-source translation Object recovery and specification Incremental approaches Component-based approaches Wikibook on the topic

Uses of Reverse Engineering Reasonably legal managing clearly owned code recovery of data from proprietary file formats creation of hardware documentation from binary drivers (often used for producing Linux drivers) enhancing consumer electronics devices malware analysis discovery of undocumented APIs (but probably a bad idea) criminal investigation copyright and patent litigation Probably unethical even when legal malware creation, often involving a search for security holes breaking software copy protection (games and expensive engineering software)

Digital Millennium Copyright Act (1998) Criminalizes production and dissemination of technology that can circumvent measures taken to protect copyright Exceptions Interoperability between software components Retrieval of data from proprietary software Full text

Ethics

ACM Code of Ethics and Professionalism (Excerpt) GENERAL MORAL IMPERATIVES Contribute to society and human well-being Avoid harm to others Be honest and trustworthy Be fair and take action not to discriminate Honor property rights including copyrights and patent Give proper credit for intellectual property Respect the privacy of others Honor confidentiality ORGANIZATIONAL LEADERSHIP IMPERATIVES Articulate social responsibilities Enhance the quality of working life Proper and authorized uses of computing and communication resources Ensure that those affected by a system have their needs clearly articulated; validate the system to meet requirements Protect the dignity of users

Intellectual Honesty (McConnell, Code Complete) Refusing to pretend you’re an expert when you’re not Readily admitting your mistakes Trying to understand a compiler warning rather than suppressing the message Clearly understanding your program – not compiling it to see if it works Providing realistic status reports Providing realistic schedule estimates and holding your ground when management asks you to adjust them

Whistle Blowing What are the alternatives? When is it okay? When is it not a choice?

Ethics of a project intended use potential misuse consequences fairness to the knowing users implications for unknowing users

Cathedral and Bazaar

Open Source What is open source? What is different about open source? Who are the developers? Why is it beneficial?

The Cathedral and the Bazaar Eric Raymond Different open source models Cathedral Code developed between releases by exclusive set of developers Bazaar Code developed openly in public view Introduced by Linux and Linus Torvalds

Raymond’s Principles 1.Every good work of software starts by scratching a developer's personal itch. 2.Good programmers know what to write. Great ones know what to rewrite (and reuse). 3.“Plan to throw one away; you will, anyhow.'' (Brooks) 4.If you have the right attitude, interesting problems will find you. 5.When you lose interest in a program, your last duty to it is to hand it off to a competent successor. 6.Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. 7.Release early. Release often. And listen to your customers.

Raymond’s Principles (cont.) 8.Given enough eyeballs, all bugs are shallow. 9.Smart data structures and dumb code works a lot better than the other way around. 10.If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. 11.The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. 12.Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. 13.“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.'' (Saint-Exupery)

Raymond’s Principles (cont.) 14.Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. 15.When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to! 16.When your language is nowhere near Turing-complete, syntactic sugar can be your friend. 17.A security system is only as secure as its secret. Beware of pseudo-secrets. 18.To solve an interesting problem, start by finding a problem that is interesting to you. 19.Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Two Other Gems

Mythical Man-Month Book of essays Very readable Still most heavily used software engineering book

No Silver Bullet Essence vs. Accident Essence is what makes it hard specification, design, and testing of this conceptual construct Accidents have been fixed labor of representing it and testing the fidelity of the representation