architecture wars - yolk recruitment2).pdf · bingo mvp fail fast pivot low hanging fruit. buzzword...

48
Architecture Wars The Competition between Features and Technical Debt

Upload: nguyenquynh

Post on 17-Sep-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

Architecture Wars

The Competition between Features

and Technical Debt

FeaturesArchitecture Requestsand

TechnicalDebt

Richard WilsonTechnical Director

at Dezrez.com@trickywilson

Special Thanks:Matt DendleCliff Calcutt

AIM1. Fix Technical Debt…at the right time and place

2. Architect a solution… avoid ending up with one

3. Don’t just be a builder… be an architect with a set of plans

1. 5mins On Me! From hero programmer, to start-up, to over 100

employees, my experience and the mistakes I've (hopefully) learnt from!!!

2. 25mins Talk in Depth Technical debt and the competition with features

The lifecycle of a start-up

3. 10mins Common MistakesA quick fire list

4. 10mins + after! What is your experience?

1

ME

Phase 1: Hero programmerFortran77, C, VB6

Rolls Royce accredited testing laboratory

Phase 2: Start UpASP, HTML, VB6

Dezrez

Phase 3: GrowthC#, javascript

Phase 4: NPD within Established CompanyDezrezPM, Rezi

Right place, Right time

Best practice only makes sense when it’s tied to the organisational context

2

Features v

Technical Debt

Phase 1Hero Programmer

Phase 1Hero Programmer

Small projectOwn boss… do what you want when you want!

All in one mind“Plan? What plan?”

Phase 2 & 3Lifecycle of a start-up

But from the developer and codebase point of view

Buzzword Bingo

MVP

Fail Fast

Pivot

Low Hanging Fruit

Buzzword Bingo

MVS

Learn Quick

Low Hanging Fruit (“I’ll be back!”)

Stages of a Start Up3 different models61 stages identified1 concerned with dev!

https://www.techinasia.com/startup-stages/

1. Just Build Fun - Super fast - No Implications - Zero Clients

2. Pack with features Still fun - Fast - Some Thought - Few Happy Clients

3. User Requests Mmm - Slow - Thought Provoking - Lots of Contented Clients Until WE Have Problems Responding

4. More User Requests Annoying - Crawl - Frustrating - Mountain of Grumpy Complaining Customers

5. Dead

Technical DebtThe eventual consequences of poor system design.

If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on.

Technical DebtThe eventual consequences of poor system design.

If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on.

http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

Phase 4Start Again - NPD

New Product DevelopmentRE Product Development

NPD in an established business is different from a

Start-Up

Bigger group of stakeholders to keep happy

Bigger plans

Balance Business V Technical

Customer Development

3 Phases of Software Dev

Agile

https://www.youtube.com/watch?v=K1gij0JJV7A

Agile Discipline

Jeff Paton

Agile Discipline & Effort Profiles for NPD

Craig Larman

Water Scrum Fall

Architecture

EmergentOr

Planned

Architecture

Hero Programmer v TeamLong term plan

Keep track of known HACKSCode Reviews & Coding StandardsProject Management Methodology

3

Common Technical Debt Mistakes in Start Ups

Some Personal TD Examples

DR110 chars for first name field

REZI“I want to send an SMS”

or“I want to send an SMS through the provider of my choice”

Backups & RedundancyDev wants – Business never does!

Agile != No DesignFailing to plan

Don’t use the proof of concept as the product!

Failing to design for maintainabilityIt’s not a hotel… no one is going to clean up after you

The customer is NOT always right!https://gettingreal.37signals.com/ch04_Hire_the_Right_Customers.php

If you try to please everyone, you won’t please anyone

Avoid becoming sales led Should be design led at the start

Then marketing led

Frameworks - The double-edged sword Frameworks can be dangerous, Frameworks can be useful

Features != a ProductUser journeys are vital

Cut down feature != cut down architecture (or design)

Fixing without Understanding

But please STICK TO SOMETHING!

Have a long term technical plan from the startAnd make time to do it properly.

Vision?

Allow time to refactor, and do it regularly The plan will not be perfect

Don’t Reinvent the wheelAWS, Azure, others?

Design Patterns, Frameworks

Identify Gold Plated RequirementsDevelop V1 and a V2 for the Backlog

OODAbstraction is the principle of generalisation.

This requires that we move from a specific instance to a more generalised concept by thinking about the most basic information

and function of an object.

SOLIDSingle responsibility, Open-closed, Liskovsubstitution, Interface segregation and

Dependency inversion

MODULES

Web Application?Separate Front from Back

API SOA

REST does not mean CRUDThink “Commands”

ReUsableFrom a business perspective, not just coding!

Jeff Bezos, Amazon, 2002All teams will henceforth expose their data and functionality through service interfaces.

Teams must communicate with each other through these interfaces.

There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

It doesn’t matter what technology they use.

All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

Anyone who doesn’t do this will be fired.

Thank you; have a nice day!

Rezi Front End Architecture

Aim of talkOr, what have I tried to tell you?

Make time to look at Technical Debt But do it AT THE RIGHT TIME

Put some structure to your codeCreate a system - with a structure

Architects get paid more than bricklayers

4

What’s your experience?

Q & A in reverse!

1) If you could go back to the beginning of your current project what piece of advice would you

give yourself?

2) What’s your go-to framework? Why?

3) Where do you go to learn best practice?

NPD in an established business is different from

Business As Usual

Different source of requirements at different stages of life cycle

Coders who only live in NPD are probably scared of the underlying architecture they have constructed