CSE 110 Software

Engineering

Some Thoughts on 

Software Architecture
with Thomas Powell
CSE 110 Software
Engineering

with Thomas Powell

CSE 110 Software
Engineering

What is Architecture

“An architect”
• Literally (in Greek) “the first builder/craftsman”
• The one who begins, leads, and guides the work


“To architect”
• To plan, organize, or structure something


“Architecture”
• A kind of knowledge that comes before and marks out what
will be built; a design

CSE 110 Software

Engineering

Words of warning

• Architecture is about how the system work

• What goes where, what talks to what & how, etc.
• Can be seductively interesting


• Rarely more important than what the system doe

• Except when it proves inadequate
• Can be a good, or very bad, problem to have
• Scalability, new environments, etc.


• Even then, the how should serve the wha

• Good architecture keeps it that way t

CSE 110 Software

Engineering

https://cadams.ca/blog/post/2017/03/03/architectus-oryzus/
CSE 110 Software
Engineering

Architecture and Execution

http://www.eoi.es/blogs/cristinagarcia-ochoa/2012/01/14/the-sidney-opera-
house-construction-a-case-of-project-management-failure/


http://www.couriermail.com.au/news/why-sydneys-opera-house-was-the-
worlds-biggest-planning-disaster/story-e6freon6-1226744769556
CSE 110 Software
Engineering

Opera House Outcomes

Design and construction were closely intertwined. Utzon’s radical approach to the
construction of the building fostered an exceptional collaborative and innovative
environment. The design solution and construction of the shell structure took eight
years to complete and the development of the special ceramic tiles for the shells
took over three years. The project was not helped by the changes to the
brief. Construction of the shells was one of the most difficult
engineering tasks ever to be attempted.

So yes it was super hard, kind of not correct for the problem, totally blown out

in timeline and budget but yet is still it is considered one of the most important

structures of the 20th century architecturally speaking. Do the ends justify these
means? If so why bother with architectural at all…just get ‘er done!?
CSE 110 Software
Engineering
Anti-Architecture: Scrap-Heap
Programming
• Aka MacGyver, Cowboy, coding with
Google, Stack Overflo
• Work bottom up, finding, scavenging,
stealing and working something out
• Negotiate towards good enough
changing the requirements if necessary
• Scrap Heap is all about the GETS
(‘Good Enough’ To Ship)
w

CSE 110 Software

Engineering

What is Software Architecture

• The theory or design for how a specific software system will be

implemente
• Tends to come first, but is often revised
• Different emphasis than the spec (how not what
• Ideally, connects the spec and the implementation 


• Can overlap a lot with both


• Many aspects, depending on circumstance

• Identification and definition of layers, components, classes; API design;
service descriptions; interface & information design; data modeling; etc.
d

CSE 110 Software

Engineering

Why Bother

Because we don’t know everything about our

future software, especially when we think we do.
◦ Having a design doesn’t mean knowing everything
◦ It means knowing that we don’t (can’t) know a lot of the implementation
details yet (they’re not written!)
◦ Instead of ignoring that, we accept it, and compensate for our ignorance
◦ The design replaces missing actual details with useful generalizations
about them--aka, models

CSE 110 Software

Engineering

Software Architecture Effects

Good/Bad software architecture affects many things though not effect varie
Be aware of “emergent properties” - what are those?

 CSE 110 Software

Engineering

Why Bother With An Architect

Spolsky:
◦ “The only thing harder than trying to design software is
trying to design software as a team.”

Even highly-decentralized systems have architects

◦ At a minimum, someone always “goes first” to model and
give shape to all the efforts that come after
◦ Examples: Vinton Cerf, Robert Kahn, Tim Berners-Lee,
Linus Torvalds, etc.



CSE 110 Software

Engineering

Waldo the Architect

CSE 110 Software
Engineering

Form Follows Function

Easy to say but hard to do
◦ Is the “function” what the software does internally, or what the user
expects it to do?
■ Remember Spolsky’s Cardinal Axiom!
◦ Or the original form might have followed function, but then gets
generalized into something else
■ Architects like to say: “Wouldn’t a more generic solution be
better?”
◦ Overgeneralization comes with the territory
■ To architect is to abstract (“to pull away” a bunch of detail to see
a general picture)
■ This is both its strength and its weakness

CSE 110 Software

Engineering

Architecture Astronauts

Spolsky:
◦ The hallmark of an architecture astronaut is that they don't solve an actual problem... they solve
something that appears to be the template of a lot of problems.

Avoid Solution First Architecture

Ex: The peer-to-peer fad, circa. 1999

◦ Because of Napster, P2P sync was all the rage
■ See Scott Rosenberg’s Dreaming in Code
◦ But compare:
■ “I want to get my music files from a peer-to-peer network.”
■ “I want to find the songs I like fast and download them right away.”
■ I wonder if we have this again with “let’s do it in chat with messaging”

Class Question: Can you think of others?

CSE 110 Software

Engineering

Over-Engineering

• When software engineering is taken

to an obsessive extreme we end up
over-engineering our progra
• Buying into the siren song of perfect
bug free ‘DONE’ software
• Corner cases overemphasize
• Always finding another featur

• Beware of anything non-trivial being

“perfect” remember my
admonishment about testing
anything above simple “Hello
World” completely

CSE 110 Software

Engineering

“Good Ideas”
• There is never a shortage of “good ideas” of things to add to a piece
of softwar
• Air quotes = yes possibly good, but not important


• “Good ideas” become the feature creep that leads to the ball of mud


• However to get projects started especially with unclear requirements

we often have to use the wish list of ”good ideas” to start the effort.
It seems we have a double edged sword with this approach!
e

CSE 110 Software

Engineering

Feature Creep

• Users often want more feature

• Market loss or user rejection
can happen do to (perceived)
product feature scarcit
• Unfortunately more features
• May harm UI and/or usabilit
• May cause architectural trade-
offs that harm the whole
y

CSE 110 Software

Engineering

KISS
• To avoid feature creep we
often hear the suggestion of
KISS (Keep it simple, stupid)!


• The phrase has become quite

trite. However, many with
experience will point out that in
actuality deliberate simplicity is
quite hard to achieve
CSE 110 Software
Engineering

YAGNI

• YAGNI = You (Probably) Ain’t Gonna Need It


• Always implement things when you actually
need them, not when you foresee eventually
needing them

• Reasoning: Even if sure feature later is
needed, don’t implement yet because late
a. You find out you don’t really need i
b. What you need becomes different than
what you thought you’d need
t

CSE 110 Software

Engineering

Yet Tons of Features Happen

• Despite all these admonishments many features are

jammed i

• Possible Reason
• Market consideration
• Predictable Consumer Irrationalit
• Mistaking Dev Ideas for User Ideas
n

CSE 110 Software

Engineering

Under Engineering

• “Over doing it” is mentioned quite often. but under

doing software isn’
• Yet under doing it is quite observable particularly
in open source repo
• My example: Charting software



• Agile and Lean methodologies often convince
adoptees to take this path to their potential doom
t

CSE 110 Software

Engineering

The Fast, Slow, Slower Pattern

• Common pattern in software developmen

• Quickly get 1.0, but it is junk
• Try to get 2.0, but the junk makes things har
• Stick with the code, faith and velocity is los
• Dump the code and you wasted tim
• Don’t do it fast enough = out of resources
y

CSE 110 Software

Engineering

The Fast, Slower, Slow Pattern?

• The first 80% we did in 2 week
• The next 10% took 2 month
• The next 5% took 1 yea
• Continue until
• This seems to be the effort curve I run into a lot, it justifies the under
engineering observation.
• “At X LOC the boredom realization set in
• Example: ZingGri
• Architecture can’t solve the marathon-sprint dichotom
• Prof often says at work “Run up the middle - 1-3 yard plays mostly!”
Hey we heard this in the soft skills part…yes you did!
…

CSE 110 Software

Engineering

Monoliths

“A software system is called ‘monolithic’ if it has a

monolithic architecture, in which functionally
distinguishable aspects (for example data input and
output, data processing, error handling, and the user
interface), are not architecturally separate components
but are all interwoven
Als
“…single-tiered software application in which the user
interface and data access code are combined into a
single program from a single platform
- Our friend Wikipedia
o

CSE 110 Software

Engineering

What it really means…

• Degree of feature/complexity/implementation exposed quite

limited - not decomposabl
• It can be a good thin
• Black Box principl
• Simple to use?
e

CSE 110 Software

Engineering

App Example

Engineering Software as a Service, Fox & Patterson, 2013

CSE 110 Software
Engineering

Monoliths ~ Solid?

• If something is meant to be non-decomposabl

• They are problems when we would like / need to
access / modify components within monolith and
can’
• Solutions
• Crack it open leads to busted open or at least
leaky abstractio
• Redo work to get the functionality - not DRY
t

CSE 110 Software

Engineering

Service Oriented Architecture (SOA)

• Definitions vary but roughly the components of a SOA style

application act as interoperable services (APIs if you like) and can be
used independently and recombined in other applications
• Yet another variation on our endless effort for code/
functional Legos in SE - this time with more an API and
network flavor

CSE 110 Software

Engineering

SOA App

Engineering Software as a Service, Fox & Patterson, 2013

CSE 110 Software
Engineering

What it can mean…

• Much more exposed functionality to more “atom” leve

• It can be a bad thin
• Abstraction break
• Complexity
s

CSE 110 Software

Engineering

Architectural Principles

• Lots of slogans that try to encourage us to do the

right thing to improve software quality at the
architectural leve
• Hopefully if done wel
• leads to easier changes (flexibility
• lower cost
• faster release
• more stability and quality
s

CSE 110 Software

Engineering

The Three Rs

• Reduc
• Less code (unless it is too tricky) tends to be bette
• Reus
• Use other people’s cod
• Recycle*
• Recycle old (or other people’s) ideas
• *Refactor would make more sense but just didn’t fit with my silly aim
e

CSE 110 Software

Engineering

Reduce

• Theory: Clarity comes from concisenes

• Theory: Programs that are easier to understand have fewer
bug
• Theory: Programs that are easier to understand are easier
to evolv
• Q: Can you think of debunking examples for each of these
ideas?
s

CSE 110 Software

Engineering

Reduce - Realities

• Less code is certainly desirabl

• Yet we don’t often end up with this, despite our intention
• Life isn’t always neat and tid
• Edge cases bloat our cod
• The problem really is that bi
• We just didn’t know that at the start
e

CSE 110 Software

Engineering

Reuse

• Theory: It is better to use existing code than write new code

• Theory: Many common even complex problems have been
solved so often it is a matter of finding the previous solution
• Reuse Examples: code snippets, software libraries, design
patterns, application frameworks, code generator

• Reuse while good in theory can have a dirty secret in real

life

CSE 110 Software

Engineering

Reuse Realities

• Time to reuse something is non-trivial

• Learning the detail
• Evaluation done too quickly leading to sub-optimal choice
and faith los
• Often selection by inspectio
• Social proof signals widely use
• “Not invented here” effects org, legal and people issues
s

CSE 110 Software

Engineering

Convention Over Configuration

• Default conventions are used and only specify unconventional aspects
of a system


• When a tool/framework matches a desired behavior it will act as

expected immediately, only deviate when some explicit configuration is
needed


• Rails is commonly mentioned around this, but it is a general idea - see

common Web app generated patterns (ex. Bootstrap, Tailwind, Create
React CLI)
CSE 110 Software
Engineering

SRP – Single Responsibility Principle

• Things (objects, functions, etc.) should be singularly

focused

• SRP tends to make things easier to reason about and

easier to test

• Related Code Smel

• Large code units tend to suggest broken SRP

CSE 110 Software

Engineering

DRY - Don’t Repeat Yourself

• Avoid repeating yoursel

• Keep things in one place ( a single sensible place hopefully !

• Single place tends to make it easier to find and adjust an idea in

code, leads to better maintainabilit

• Code Smell: Duplicated code (Ctrl-C/V) tends to suggest breaking

DRY
f

CSE 110 Software

Engineering

Keeping DRY

• DRY - Don’t Repeat Yoursel

• In the small reuse seems so obviou
• Repeated slightly different code suggests room for abstract
solutio
• Single source encourages easier change
• Update one place, effect man
• Is there a trade-off?
n

CSE 110 Software

Engineering

Orthogonalit

• Orthogonality is the idea of how a relatively small number of

components can be combined in a relatively small number
of ways to get the desired results
• Sounds KISS like or DRY like or
• Why is it that all these things are the same!?
y
…

CSE 110 Software

Engineering

Getting WET

• WET = We enjoy typing

• Not DR
• Lots of repeated similar cod
• Multiple locations for feature making change difficult
Y

CSE 110 Software

Engineering

Single Responsibility Principle

• Keep elements (classes, modules, or even functions)
focused on a single concer
• One responsibility for the elemen
• Entirely encapsulated within elemen
• If an element can be changed for two reasons maybe it
should be two elements
• Is this DRY?
?

CSE 110 Software

Engineering

Dependency Graph

• We can see this last idea done well or no

• In case of software this is a directed graph showing the
dependencies between classes, modules, systems, etc
• Make before - architectural pla
• Make after - road map
• Some belief that in a well designed system the dependency
graph should be logical
?

CSE 110 Software

Engineering

What we want?
CSE 110 Software
Engineering

Starts to devolve
CSE 110 Software
Engineering

And here we are...

CSE 110 Software
Engineering

Visualized sure, but what do we see?

CSE 110 Software
Engineering

And here?
CSE 110 Software
Engineering

Thread and Button Problem

• Metapho
• Button = (Module/Class/Function
• Thread = Call / Dependenc
• More buttons, threads or both = Problems

http://akvo.org/blog/the-ball-of-mud-transition/
r

CSE 110 Software

Engineering

Balls of Mud

“A Big Ball of Mud is a haphazardly structured,

sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-
code jungle. These systems show unmistakable signs of
unregulated growth, and repeated, expedient repair.
Information is shared promiscuously among distant
elements of the system, often to the point where nearly
all the important information becomes global or
duplicated. The overall structure of the system may
never have been well defined. If it was, it may have
eroded beyond recognition.”
http://laputan.org/mud/
CSE 110 Software
Engineering

Dealing with Mud

• Reality is often this is the de facto state


• Rewrite! —> Eventually die or maybe reborn?


• Struggle with changes —> Eventually die


• Do nothing —>Eventually die

CSE 110 Software
Engineering

Except when it isn’t

Source: Personal history related to me about 


this wildly successful and influential “ball of mud”
CSE 110 Software
Engineering

Helicopter Problem

• The higher you go up the more you se

• shared classes, types, scopes, etc
• common “patterns” across different case
• more “complete” solutions


• But also the higher up you go, the less you se

• detail, context, key differences, generalization leads to
overgeneralizatio
• users don’t live at 30,000 feet, but on the groun
• very easy to start solving problems no one has
n

CSE 110 Software

Engineering

Helicopters Can Move

• Hairballs and trouble is inevitable when we are trying to see

too much at once


• Treating the system as a whole as opposed to making there

be levels with components 


• Should we consolidate to the appropriate view level?

CSE 110 Software
Engineering

At 30,000ft

• System level desig

• Boxes may represent full programs, services, or at smallest
maybe module
• Goal here is to understand data flows and general
components in the larg
• Example: System Diagram
s

CSE 110 Software

Engineering

At 10,000ft

• General Service / Program level descriptio

• Present more details of how service/program work
• May show general call name
• Describe general inputs/output
• Example: Service Overview
s

CSE 110 Software

Engineering

At 1,000ft

• Individual services are broken down in detai

• Full list of possible calls, allowed values, typical outputs,
error cases, etc
• No indication of how it is built withi
• Ex: API documentation of a Service
.

CSE 110 Software

Engineering

At 100ft

• Code level of classes including privat

• Comments might be this artifac
• At this level code guidelines become important
t

CSE 110 Software

Engineering

Code Smell
• Code smell - the hint that something may be wron
• There are tell tale signs to look for that suggest bad
architecture a foot

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

CSE 110 Software

Engineering

Smell: Too Much

• Method, Class, File is too lon

• Measure by LOC or screen ful
• Problem: Hard to digest and keep in hea
• Counterpoint: Could be the atom level for the ide
• Too many comment
• Comment line to code line
• Problems: Hard to see code, unneeded comment =
wasted time/effort (WET) if needed -> complexity
s

CSE 110 Software

Engineering

Smell: Too Much

• Method/Function signature has too many parameter

• Ex: function doIt(x,y,z,p,d,q,a,b,c) { }
• Problem: Suggests complexity, mismatch possibilitie
• Solution: Break up, change to mandatory + object/collection
function doIt(x,y,options)

CSE 110 Software

Engineering

Smell: Too Little

• Entry is too shor

• 2 line function, 4 line file, etc
• May not be a problem if widely use
• Method may be short, but it is invoked by everything = DRY principle in
effect
t

CSE 110 Software

Engineering

At Zero Feet

• This is the surface - this is where the user meets the ap

• Maybe this should have been a below the surface metaphor
• Artifacts here are the UX wireframes and then eventually the
actual interfac
• This of course is everything to some people but it greatly
depends on other architecture points
e

CSE 110 Software

Engineering

Summary

• Architecture is importan
• Yet Architecture is difficult to exactly define since it is
encompasses many thing
• Bad architecture can significantly hamper the success of a
projec
• Sadly good architecture does not mean a project will
succeed though
t