Why do we rewrite software? SumUp. A better way to get paid 1 2 - - PowerPoint PPT Presentation

why do we rewrite software
SMART_READER_LITE
LIVE PREVIEW

Why do we rewrite software? SumUp. A better way to get paid 1 2 - - PowerPoint PPT Presentation

Why do we rewrite software? SumUp. A better way to get paid 1 2 Why do we usually Inexperience Its fun rewrite code? 3 4 Better solution Technical available Debt SumUp. A better way to get paid Code that negatively Old libraries?


slide-1
SLIDE 1
slide-2
SLIDE 2
  • SumUp. A better way to get paid

Why do we rewrite software?

slide-3
SLIDE 3
  • SumUp. A better way to get paid

Why do we usually rewrite code?

1 Inexperience 2 It’s fun 3 Better solution available 4 Technical Debt

slide-4
SLIDE 4
  • SumUp. A better way to get paid

Technical debt

Code I didn’t write? Old libraries?

Code that negatively and repeatedly affects the speed or quality of delivery

Code I wrote before I knew what I was doing? Features that no one uses

slide-5
SLIDE 5
  • SumUp. A better way to get paid

Time Speed

  • f adding

new features

😱

Technical debt

slide-6
SLIDE 6
  • SumUp. A better way to get paid

Time Speed

  • f adding

new features *refactor*

Recurring technical debt

😱

slide-7
SLIDE 7
  • SumUp. A better way to get paid

Second system effect

The tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems due to inflated expectations and

  • verconfidence.
“The Mythical Man Month: Essays on Software Engineering” - Frederick P. Brooks Jr.
slide-8
SLIDE 8
  • SumUp. A better way to get paid

“Legacy code” often difgers from its suggested alternative by actually working and scaling.”

  • Bjarne Stroustrup, Inventor of C++
slide-9
SLIDE 9
  • SumUp. A better way to get paid

R

https://www.vectorstock.com/royalty-free-vector/ouroboros-snake-eating-its-own-tail-eternity-or-vector-12076546

e w r i t e

Is this my destiny?

slide-10
SLIDE 10
  • SumUp. A better way to get paid

The real cost of software is not the initial development, but maintenance over time

HARD FACT

slide-11
SLIDE 11
  • SumUp. A better way to get paid

Why do we rewrite software?

THE QUESTION IS NOT

slide-12
SLIDE 12
  • SumUp. A better way to get paid

How can we make our systems more resilient to inevitable change ?

slide-13
SLIDE 13
  • SumUp. A better way to get paid

Time Speed

  • f adding

new features

😱

slide-14
SLIDE 14
  • SumUp. A better way to get paid

Time Speed

  • f adding

new features

🙄

slide-15
SLIDE 15
  • SumUp. A better way to get paid

“Good architecture” How do we reach this nirvana?

🙅

slide-16
SLIDE 16
  • SumUp. A better way to get paid

“Architecture” has become a dirty word

Sounds elite No clear definition Feels detached from daily problems Hard to spell What does a software architect even do?

slide-17
SLIDE 17
  • SumUp. A better way to get paid

Architecture as enabling constraints

Constraints about how we use data and code that help us move faster over time

slide-18
SLIDE 18
  • SumUp. A better way to get paid

🚙

Enabling constraints in real life

slide-19
SLIDE 19
  • SumUp. A better way to get paid

OOP Functional

Enabling constraints in Programming paradigms

Paradigm Constraint & Enablement

From function pointers to classes→ Independently deployable subcomponents From mutable to immutable data → Eliminate race conditions and concurrency problems

slide-20
SLIDE 20
  • SumUp. A better way to get paid

var → const

Enabling constraints in Frontend development

Paradigm Constraint & Enablement

No more reassignment → Predictable data jQuery → React No more DOM manipulation → Predictable UI CSS → CSS-in-JS No more naming / side-effects → Safety and fewer global clashes

slide-21
SLIDE 21
  • SumUp. A better way to get paid

We are constraining

  • urselves all the time
slide-22
SLIDE 22
  • SumUp. A better way to get paid

We trade constraints for safety and speed

slide-23
SLIDE 23
  • SumUp. A better way to get paid

3 constraints you can use today for more resilient frontend architecture N O T E X H A U S T I V E

slide-24
SLIDE 24
  • SumUp. A better way to get paid

1 2 3 Constraint Enables

Constraints for more resilient frontend architecture

slide-25
SLIDE 25
  • SumUp. A better way to get paid

1 2 3 Constraint Enables

Constraints for more resilient frontend architecture

Source code dependencies must point inward

slide-26
SLIDE 26
  • SumUp. A better way to get paid

A few ways of organizing our dependencies

Big Ball of Mud Modular Layered

slide-27
SLIDE 27
  • SumUp. A better way to get paid

Constraint Source code dependencies must point inwards

What’s the difference?

Big Ball of Mud Layered

slide-28
SLIDE 28
  • SumUp. A better way to get paid

Constraint Source code dependencies must point inwards

Big Ball of Mud Layered

*changed*

slide-29
SLIDE 29
  • SumUp. A better way to get paid

Constraint Source code dependencies must point inwards

Big Ball of Mud Layered

*changed* Huge or unknown regression scope Cross-team conflicts

slide-30
SLIDE 30
  • SumUp. A better way to get paid

Constraint Source code dependencies must point inwards

Ball of Mud Layered

*changed* *changed*

slide-31
SLIDE 31
  • SumUp. A better way to get paid

Constraint Source code dependencies must point inwards

Ball of Mud Layered

*changed* *changed* Limited regression scope (Usually) does not affect other teams

slide-32
SLIDE 32
  • SumUp. A better way to get paid

Key difference between a ball of mud and a well-organized monolith is dependency organization

slide-33
SLIDE 33
  • SumUp. A better way to get paid

Constraint Source code dependencies must point inwards

slide-34
SLIDE 34
  • SumUp. A better way to get paid

Constraint Source code dependencies must point inwards

API / Data UI Layer Business logic Router Page 1 Page 2 For each page, the rest of the application does not even exist

slide-35
SLIDE 35
  • SumUp. A better way to get paid

1 2 3 Constraint Enables

Constraints for more resilient frontend architecture

Source code dependencies must point inward Easier to isolate impact of changes

slide-36
SLIDE 36
  • SumUp. A better way to get paid

What about shared components?

Design system 🎩 -or- copy-paste ✂

slide-37
SLIDE 37
  • SumUp. A better way to get paid

1 2 3 Constraint Enables

Constraints for more resilient frontend architecture

Source code dependencies must point inward Easier to isolate impact of changes Be conservative about code reuse

slide-38
SLIDE 38
  • SumUp. A better way to get paid

WE ♥ DRY

slide-39
SLIDE 39
  • SumUp. A better way to get paid

The result is often brittle and side-effect ridden code in the name of code reuse

slide-40
SLIDE 40
  • SumUp. A better way to get paid

Impact of time on shared code

slide-41
SLIDE 41
  • SumUp. A better way to get paid

Impact of time on shared code

if, context, branches…

slide-42
SLIDE 42
  • SumUp. A better way to get paid

DECOUPLED > DRY

Code reuse is not a goal in and of itself

slide-43
SLIDE 43
  • SumUp. A better way to get paid

Sometimes you just need two glasses!

slide-44
SLIDE 44
  • SumUp. A better way to get paid

1 2 3 Constraint Enables

Constraints for more resilient frontend architecture

Source code dependencies must point inward Easier to isolate impact of changes Be conservative about code reuse Avoid coupling code that diverges

  • ver time
slide-45
SLIDE 45
  • SumUp. A better way to get paid

1 3 Constraint Enables

Constraints for more resilient frontend architecture

Source code dependencies must point inward Easier to isolate impact of changes Enforce your boundaries

2

Be conservative about code reuse Avoid coupling code that diverges

  • ver time
slide-46
SLIDE 46
  • SumUp. A better way to get paid

Router Page

import

Other Page Subcomponent Business logic Business logic

slide-47
SLIDE 47
  • SumUp. A better way to get paid

import

Router Page Other Page Business logic Business logic Subcomponent

slide-48
SLIDE 48
  • SumUp. A better way to get paid

Router Page Other Page Subcomponent Business logic Business logic

slide-49
SLIDE 49
  • SumUp. A better way to get paid

Router Page Other Page Subcomponent Business logic Business logic

slide-50
SLIDE 50
  • SumUp. A better way to get paid

Forbidden dependency tests

BUILD FAILING

slide-51
SLIDE 51
  • SumUp. A better way to get paid
{ "forbidden": [{ "name": "Your Page", "comment": "Should not depend on other pages", "severity": "error", "from": { "pathNot": "^pages/YourPage" }, "to": { "path": "^pages/YourPage" } }] } .dependency-cruiser.json

npm install --save-dev dependency-cruiser

Forbidden dependency tests

slide-52
SLIDE 52
  • SumUp. A better way to get paid

1 2 3 Constraint Enables

Constraints for more resilient frontend architecture

Source code dependencies must point inward Easier to isolate impact of changes Enforce your boundaries Preserve your architecture

  • ver time

Be conservative about code reuse Avoid coupling code that diverges

  • ver time
slide-53
SLIDE 53
  • SumUp. A better way to get paid

💱

The real cost of software is maintenance over time, because change is inevitable

🚙

Architecture is about applying enabling constraints to how we use code and data

👀

We can make small changes to make our projects more resilient (1. Think directionally,

  • 2. Be conservative on reuse,
  • 3. Enforce our boundaries)

What we’ve learned

slide-54
SLIDE 54
  • SumUp. A better way to get paid

Every time you write a function (or don’t), create a new module (or don’t), you’re making an architecture decision

👀

slide-55
SLIDE 55
  • SumUp. A better way to get paid

You don’t have to derive architecture from first principles

🚙

slide-56
SLIDE 56

👌 Thank you!

@monicalent