7. In 2016 the most popular design
in software engineering is …
8.
9. Big ball of mud symptoms
• Throwaway code
• Merciless deadlines
• Cut and paste
• Sheer neglect
• Afraid to change parts of the system
• Brittle / fragile tests
• Data shared promiscuously among distant parts of the
system
10. Guiding Principles
• Last Responsible Moment
• Continuous Integration
• Lightweight, Living Documentation
• Continuous Delivery
• Adapt for Organisational Structure
• Design for Replacability
12. • Decisions made too early in a project are hugely risky
• Delay decisions as long as you can but no longer !
• Every additional tool / technology you add will slow you
down….
15. • Without adequate tests your architecture won’t evolve freely
• Code coverage stats are absolutely useless !
• TDD – writing tests first changes the shape of your code…
• Be prepared to throw away old tests over time who cares !
• Code that is easier to test its easier to change, easier to understand
16. The simplest branching strategy ever!
• Use (VERY) short lived feature branches
• When you merge with master its ready for production
• Continuously deploy from master
21. • agile does not mean doing no documentation !
• No technical discussions / decisions in emails !
• Prefer , wiki’s & collaborative tools – e.g. yammer / slack / confluence
• What to document
- System diagrams (napkin sketches)
- Design decisions
- Operational instructions
23. • Embrace continuous delivery as an organisation
• Deployments should be boring !
• Feature Switches
• Takes the fear out of releasing software
• Forces you to deal with versioning API’s from the start
26. Conway’s Law
“Organizations which design
systems ... are constrained to
produce designs which are copies of
the communication structures of
these organizations”
— M. Conway 1967
30. Robustness
"Be liberal in what you accept, and
conservative in what you send“
- Jon Postel (God of the Internet)
31. Summary
• Last Responsible Moment
• Continuous Integration
• Lightweight, Living Documentation
• Continuous Delivery
• Adapt for Organisational Structure
• Design for Replacability
Editor's Notes
Always looking at new frameworks and most of us don’t spend enough time thinking about better ways to make software and teams work better
Always looking at new frameworks and most of us don’t spend enough time thinking about better ways to make software and teams work better
Despite the emergence of development methods that encourage and facilitate well-factored code, and the growth of the Software Craftsmanship movement, the Big Ball of Mud remains the most popular design for software, including greenfield development that has the full benefit of hindsight regarding the bad design approaches of the past.
Here are a number of useful techniques and principles that will help you to maintain a clean architecture through the lifetime of your product.
When we make decisions, delay then as long as possible but no longer !
The longer you wait the more you know, it minimises the
Not about procrastination…
Encorporating tools or technologies you don’t need slows you down
Not all parts of your system need to be fully redundant , there is a cost you encur doing this etc..
Example – report designer – defer till a few forms built
To absorb change and allow late decisions you need to build the smallest thing possible to gain more knowledge ( MCVP)
Example stat reporter – report evaluation process is time comsuming so it needs to be queue based and asynchronous… no it doesn’t !
Nothing builds or destroys agility more than a team’s commitment to continuous integration
The Agile Manifesto prefers “working software over comprehensive documentation”. This doesn’t mean that you can ditch documentation entirely.
Wiki’s living breathing
The Agile Manifesto prefers “working software over comprehensive documentation”. This doesn’t mean that you can ditch documentation entirely.
Wiki’s living breathing
- Helps you get your thoughts straight by putting it down on paper
Needs to be light enough if its any chance of surviving a project
NEVER make important decisions in emails !
you should be looking for opportunities to split monolithic systems up around organizational boundaries …..
Who has lunch together, if as people they don’t talk to eachether their code wont either
Broken communication results in silo’s…
Don’t build silos based on technology into your organisation
Having one group responsible for a piece of functionality E2E is the best
Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system.
Two-Pizza Team Rule Works
These independent teams can own the whole lifecycle of the services they create, affording them a greater degree of autonomy than is possible for larger teams with more monolithic codebases
As soon as there is data in the message people rely on it and its harder to change…
If all you need is a post code in an address then ignore the rest of the payload…
Not all API’s need to be versioned the same way, who relies on it and who are the consumers,
When it comes to exposing data you should expose the bare minimum and no more and you should version all message contracts. Conversely when consuming an API its best to ignore parts of the message you aren’t interested in, you don’t care if these change over time.