Big Ball of Mud: Software Maintenance Nightmares

Big Ball of Mud
Software Maintenance Nightmares
Nov 2013

Gonzalo Fernández Rodríguez (gfr@tid.es)

BBM: Software Maintenance Nightmares
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

MAINTAINABILITY

Performance

Security

1


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.

Original Paper: http://www.laputan.org/mud
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.

2


Big Ball of Mud seems like….

Haphazardly
structured

Spaguetti code

Sprawling

Duplicate data

Sloppy

Duplicate
behaviour

Duct-tape

Unregulated
grotwh

Bailing wire

Repeated
expedient repair
3


Causes

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

q 
q 
q 
q 

Software architecture is seldom discussed.
Unconcerned about architecture: If doesn’t matter if it works….
THROWAWAY CODE is Good!! The real problem comes when it isn't thrown away.
Systems that were once tidy, become overgrown as PIECEMEAL GROWTH gradually
allows elements of the system to sprawl in an uncontrolled fashion.

4


Alarming Symptoms

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

q  Every

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

5


Alarming Symptoms

FRAGILE
Make a change here, break the code there
This happen when we enter a change in software and cause it to
misbehave in some places
q 

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.

6


Alarming Symptoms

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

7


Alarming Symptoms

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.
8


But…. how can we get the maintainability ?

HIGH COHESION!!!
LOW COUPLING!!!
SEPARATION OF CONCERNS!!!

9


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

S

•  Single Responsibility

O

•  Open/Closed Principles

L

•  Liskov’s Principle

I

•  Interface Segregation

D

•  Dependency Inversion

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.
10


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

11


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.

12



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?
13



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.

Template Method Pattern
Strategy Pattern

14


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.

15


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.
16



Poorly designed interface
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.

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

(Example extracted from Wallet Server. PDI)
17



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

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)
18


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.

19


Code Smells

How Can I realize out my
code is getting to a
Big Ball of Mud?

20


Code Smells
Long Method

Long
Parameter
List

Difficult to read,
u nerstand and
troubleshoot

More paremeters
à More complex

Refactor into
smaller methods

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

Duplicate
code

Combinatorial
Explosion

Large Class

Take care of
large conditional
logic blocks.

Lots of code that
does almost the
same.

Difficult to read,
understand, and
troubleshoot

Consider to
refactor

Refactor:
generics,
template,
interpreter...

Refactor into
smaller classes

Dead Code

Speculative
Generality

Oddball Solution

Temporary Field

YAGNI

Don’t Repeat
Yourself

Are they useful?

Type Embedded in
Name

Conditional
Complexity

Delete code that
isn't being used.

Comments

Limit the number
of parameters or
combine them in
an object

Uncommunicative
Names

Inconsistent
Names

Are they selfexplanatory?

Agree a set of
consistent
names

Avoid
innecessary
fields in objects
Suspects of rare
solutions

Use Version
control systems

Don't worry
about tomorrow's
problems until
they come.

Not cherrypicking single
fields when
passing objects

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


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.

22

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.
23


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.
24


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
25


Big Ball of Mud: Software Maintenance Nightmares

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Big Ball of Mud: Software Maintenance Nightmares

Semelhante a Big Ball of Mud: Software Maintenance Nightmares (20)

Último

Último (20)

Big Ball of Mud: Software Maintenance Nightmares