Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Stop Smashing Your Keyboard! Zoom Out and Think!

Stop Smashing Your Keyboard! Zoom Out and Think!

(Presentation from Spaces Summit 2018, bol.com)

Dirty little secret: most of the time as developers we have no clear picture of what we are doing; how we are doing it; and especially why we are doing it. We work without a clear perspective, ending up spending too much time building things and later re-building/refactoring them... This is all done in the name of "agility and speed", but we paradoxically end up getting the exact opposite result.

My answer to this? Create a basic design and understanding before starting a project... Then iterate on it, as you face new design decisions (and gain knowledge and insights).

Let me get you into this mindset with some very pragmatic ideas and tools, like: "visualization of problems and solutions", "just enough upfront design", "evolutionary architectures"... but especially why you should stop smashing your keyboard, zoom out, and THINK!

Presentation video here: https://youtu.be/FCqn9iHU9xo

Eduardo da Silva

June 07, 2018

More Decks by Eduardo da Silva

Other Decks in Technology


  1. even though in reality we do not go so fast…

    we are still expected to go “fast”
  2. Why do we need to move fast? Because businesses need

    “fast” to stay ahead! ...so, there is always a sense of urgency on what we are doing… ...and that “is not bad”
  3. How are we tackling this “need for speed”? Get our

    heads down and “just do it”! Be agile! Be lean! ... Deliver things fast! tuff
  4. (blind) Agile and Go Fast Too much focus on speed

    (rate of motion)… heads down, let’s move fast!! No time to define direction! “Go with the flow/instinct”
  5. Agile and Go Fast with clear(er) direction We must focus

    on “high velocity” We need direction (on our iterations)! Result = move fast towards the “end goal”! Decisions
  6. Framework for incremental architecture design 1) Start the project by

    addressing the “important decisions” (=Architecture) a) What/Why/How b) Initial plan of action (start...end) 2) At each new “important decision” a) Re-evaluate the what/why/how - with the end-goal in mind b) (re)define plan of action Decisions
  7. Visualization of Problems and Solutions When stuck on a problem…

    • go “offline”, (zoom-out-think) visualize your problems and solutions No need of UML and formal architecture languages • Whiteboarding is good Helps everyone get a common perspective faster
  8. Architecture Decision Records (ADR) (by Michael Nygard) Lightweight documentation of

    the “design decisions” These are “immutable” - a design decision is taken and executed ⇒ no more stale documentation Project documentation that seats on your codebase!