architecture wars - yolk recruitment2).pdf · bingo mvp fail fast pivot low hanging fruit. buzzword...
Post on 17-Sep-2018
219 Views
Preview:
TRANSCRIPT
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?
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
Phase 1Hero Programmer
Small projectOwn boss… do what you want when you want!
All in one mind“Plan? What plan?”
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
NPD in an established business is different from a
Start-Up
Bigger group of stakeholders to keep happy
Bigger plans
Balance Business V Technical
Architecture
Hero Programmer v TeamLong term plan
Keep track of known HACKSCode Reviews & Coding StandardsProject Management Methodology
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!
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
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?
top related