Big Ball of Mud: Software Maintenance Nightmares

Big Ball of Mud Software Maintenance Nightmares

Nov 2013

Gonzalo Fernández Rodríguez ([email protected])

BBM: Software Maintenance Nightmares

1

The importance of maintainability

A large part of a developer’s work consist of spending time in MAINTENANCE tasks MANTAINABILITY is the best compromise that architects and developers might get.

Scalability

Performance

Security

MAINTAINABILITY


2

The Big Ball of Mud: what is?

Big Ball of Mud (BBM) is a term coined by Briand Food and Joseph Yooder in 1999 that indicates a clear antipattern for architects and developers. The expresion Big Ball of Mud refers to a software code that lacks a good desing. Wikipedia - A big ball of mud is a software system that lacks a perceivable architecture. Although undesirable from an engineering point of view, such systems are common in practice due to business pressures and developer turnover. They have therefore been declared a design anti-pattern. Wikipedia - BIG BALL OF MUD systems have usually been developed over a long period of time, with different individuals working on various pieces and parts. Systems developed by people with no formal architecture or programming training often fall into this pattern.

Original Paper: http://www.laputan.org/mud



3

Big Ball of Mud seems like….

Haphazardly structured

Sprawling

Sloppy

Duct-tape

Bailing wire

Spaguetti code

Duplicate data

Duplicate behaviour

Unregulated grotwh

Repeated expedient repair



4

q The limited skills of the team q Frequent changing of requirements q High rate of turnover among team members

q  Software architecture is seldom discussed. q  Unconcerned about architecture: If doesn’t matter if it works…. q  THROWAWAY CODE is Good!! The real problem comes when it isn't thrown away. q  Systems that were once tidy, become overgrown as PIECEMEAL GROWTH gradually

allows elements of the system to sprawl in an uncontrolled fashion.

BBM: Software Maintenance Nightmares Causes


5

Alarming Symptoms

q  Every change causes a cascade of subsequent changes in dependent modules. q  Managers fear to allow engineers to fix non-critical problems

RIGIDITY A simple two day change grows into a multiweek of changes



6

FRAGILE Make a change here, break the code there

q  This happen when we enter a change in software and cause it to misbehave in some places q  When a change in a software module breaks other modules (because of hidden dependencies), we are facing to a bad design and we should repair it ASAP.

Alarming Symptoms



7

INMOBILITY Easier to use than reuse

q  If the same code doesn’t work when it’s moved to another project, it’s because of dependencies.

q  Disadvantages: •  We have to import a much larger set of functions to use this functionality in other project. •  Increases duplication

Alarming Symptoms



8

VISCOSITY Easier to work around than to fix

q  We have several ways to add a new feature or to solve a problem in the software but ….

•  The scalable and elegant ways to do it are very difficult to apply because we have a lot of restrictions. •  The only way to do it is with a sort of trick that is a temporary rather than a scalable solution.

Alarming Symptoms



9

But…. how can we get the maintainability ?

HIGH COHESION!!!

LOW COUPLING!!!

SEPARATION OF CONCERNS!!!



10

SOLID PRINCIPLES

Is a mnemonic acronym introduced by Robert C. Martin in the early 2000s which stands for five basic principles of object-oriented programming and design.

S •  Single Responsibility

O •  Open/Closed Principles

L •  Liskov’s Principle

I •  Interface Segregation

D •  Dependency Inversion


An experienced programmer doesn’t use solid as a checklist - he INTERNALISES it


11

Single Responsibility

Only one reason for a class to change GOAL: Keeping the code simple. (Effective way to simplify maintenance)



12

Open / Closed principle

Software Entities (Classes, Modules, Functions, etc.) should be open for Extension, but closed for Modification (Bertrand Meyer, the creator of Eiffel Language).

GOAL: Low Coupling.



13


Open for Extension q The behavior of the module can be extended. We can make the module behave in a new and different ways as the requirements of the application change, or to meet the needs of new applications.

Closed for Modification q The source code of such a module is inviolate. No one is allowed to make source code changes to it.

…. How can these two oposing attributes be resolved?



14

The key is… ABSTRACTION q  It is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstraction could be got by abstract base classes or by implementing an interface, and the unbounded group of possible behaviors is represented by all the possible derivative classes or all the possible classes that implement the inteface.

Strategy Pattern

Template Method Pattern




15

Liskov’s Principle

The Objects of subtypes should behave like those of supertypes if used via supertype methods.

Subclasses should be substitutable for their base classes. The Methods that use the references to base classes (interfaces) must be able to use objects of derived classes (implementer classes) without knowing it.

TWO CONCEPTS BEHIND: ABSTRACTION and POLYMORPHISM.



16

Interface Segregation

Components should not be forced to implement members of interfaces (or base classes) that they don’t plan to use.

Goal: High Cohesion & Low Coupling

Is OK to have methods with a void implementation?. It depends of…… - If we have a deliberately partial implementation, then is Acceptable for instance: we will release the implementation in a later version - If we have a bad designed interface, then is NOT OK for instance: we have held all the public interfaces in a only “interface” and forced to several classes to implement this interface even when some of them won’t be able to implement some of the methods.



17


ISupplier represents the interface for card service providers. ThreeVProvider manages payment cards. TisProvider manages non payments cards, but it has to implement all the payments methods defined in ISupplierProvider due to a poorly designed interface. All theses methos will throw a NotImplementedException.

Poorly designed interface

(Example extracted from Wallet Server. PDI)

Why do we have to implement these Methods when they are not needed?



18


Refactoring the previous interface

IServiceProvider: interface which expose the operations related with cards in “general”. IPaymentProvider: interface which expose the operations that will be implemented by credit cards. TisProvider: will implement only general operations for any card that are exposed on IServiceProvider. ThreeVProvider: implement both interfaces, because ThreeVProvider is a credit card. (Example extracted from Wallet Server. PDI)

TisProvider doesn’t comply the relation “is a” IPaymentProvider



19

Dependency Inversion

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

Goal: Reduce the interdependence of the modules, writing loosely coupled classes.



20

Code Smells


How Can I realize out my code is getting to a

Big Ball of Mud?


21

Code Smells


Comments

Are they useful?

Long Method

Difficult to read, u nerstand and troubleshoot

Refactor into smaller methods

Long Parameter

List

More paremeters à More complex

Limit the number of parameters or combine them in

an object

Duplicate code

Don’t Repeat Yourself

Conditional Complexity

Take care of large conditional

logic blocks.

Consider to refactor

Combinatorial Explosion

Lots of code that does almost the

same.

Refactor: generics, template,

interpreter...

Large Class

Difficult to read, understand, and

troubleshoot

Refactor into smaller classes

Type Embedded in Name

Redundant. (Forces you to change it if the type changes)

Uncommunicative Names

Are they self-explanatory?

Inconsistent Names

Agree a set of consistent

names

Dead Code

Delete code that isn't being used.

Use Version control systems

Speculative Generality

YAGNI

Don't worry about tomorrow's

problems until they come.

Oddball Solution

Suspects of rare solutions

Temporary Field

Avoid innecessary

fields in objects

Not cherry-picking single fields when

passing objects

http://www.codinghorror.com/blog/2006/05/code-smells.html


22

Success Keys

Managers Support q  Managers believing in the quality of code for the success of products and prioritizing it over the amount of functionality will help the team to adopt the use of this priniciples from the begining.

q Managers should let themselves to be advised by the team and to be able to take decissions to accomplish an improvement period if it is necessary.



23

Success Keys

The collaboration of Team Members q  This practice is not useful if it is not implemented by all the team members. q  It is necessary to throw away the idea that implement SOLID based software is more difficult and more expensive than to improvise code without follow these principles. q  Team members should get used to implement SOLID principles in their code in a implicit fashion, without thinking in it like when they are able to use a language they master.



24

Success Keys

The collective ownership of code q  It helps to maintain the uniformity of the code, fostering the best practices in all the involved modules in the project.

q  What happen if not all team members implement SOLID principles? • Some members will spend a lot of time refactoring wrong code. • The members that not follow this principles will contaminate the SOLID code generating a Big Ball of Mud again.



25

Bibliography

1. Programming Microsoft ASP.NET 4, Dino Esposito. Microsoft Press, March 2011. 2. http://www.laputan.org/mud/ 3. http://c2.com/cgi/wiki?CouplingAndCohesion 4. http://www.objectmentor.com/resources/articles/ocp.pdf 5. http://prashantbrall.wordpress.com 6. http://www.codinghorror.com/blog/2006/05/code-smells.html Code Examples in: https://github.com/lentregu/Solid



Big Ball of Mud: Software Maintenance Nightmares

Technology

Transcript of Big Ball of Mud: Software Maintenance Nightmares