Category: Resources

Book List (And Other Resources)

Basic Resources For Developer

  1. The Pragmatic Programmer – by David Thomas, Andrew Hunt
  2. Test-Driven Development: By Example – by Kent Beck
  3. Code Complete – By Steve McConnell
  4. Refactoring: Improving the Design of Existing Code – by Martin Fowler
  5. Fix The Small Things – by Kent Beck
  6. Working Effectively with Legacy Code – by Michael Feathers
  7. Ian Cooper: TDD, where did it all go wrong (Video)
  8. Some Underrated Elements of Success for the Modern Programmer – J. B. Rainsberger
  9. 97 Things Every Programmer Should Know – by Kevin Henney

Architecture (and Business)

  1. Domain-Driven Design: Tackling Complexity in the Heart of Software – by Eric Evans
  2. Learning Domain-Driven Design – by Vlad Khononov
  3. Martin Fowler’s Blog
  4. Community Collection of Maps, Heuristics, Methods and more – Open Source
  5. Encouraging DDD Curiosity as a Product Owner – Zsófia Herendi – KanDDDinsky(video)

Resources For Everbody Caring For Product(Project) Development and Strategy

  1. Impact Mapping: Making a Big Impact with Software Products and Projects – by Gojko Adzic
  2. Specification by Example: How Successful Teams Deliver the Right Software – by Gojko Adzic
  3. The Bottleneck Rules: How To Get More Done at Work, Without Working Harder – by Clarke Ching
  4. Agile Conversations – by Douglas Squirrel and Jeffrey Fredrick (there also is a Meetup to practice)
  5. Nick Tune’s Strategic Technology Blog
  6. Accelerate: Building and Scaling High-Performing Technology Organizations – byNicole Forsgren, Jez Humble, Gene Kim
  7. Team Topologies: Organizing Business and Technology Teams for Fast Flow – by Matthew Skelton, Manuel Pais
  8. The Software Architect Elevator: Transforming Enterprises with Technology and Business Architecture – by Gregor Hohpe
  9. Visual Collaboration Tools – by many

Crime, History

  1. The Mythical Man-Month: Essays on Software Engineering – by Frederick P. Brooks Jr.
  2. Your Code As a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs – by Adam Tornhill
  3. The Phoenix Project – by Gene Kim, Kevin Behr, and George Spafford
  4. The Unicorn Project – by Gene Kim

THE FIRST IDEAL: Locality and Simplicity

THE SECOND IDEAL: Focus, Flow, and Joy

THE THIRD IDEAL: Improvement of Daily Work

THE FOURTH IDEAL: Psychological Safety

THE FIFTH IDEAL: Customer Focus

My Reading List @KanDDDinsky

Accelerate - Building and Scaling High Performing Technology Organizations

Accelerate by Nicole Forsgren, Gene Kim, Jez Humble

This book was referenced to in a lot of talks, mostly with the same phrase “hey folks, you have to read this!”

Domain Modeling Made Functional by Scott Wlaschin

The book was called as the only real currently published reference work for DDD for functional programming.

More books and videos to find on fsharpforfunandprofit

Functional Core, Imperative Shell by Gary Bernhard – a talk

The comments on this tweet are telling me, watching this video is long overdue …

37 Things One Architect Knows About IT Transformation by Gregor Hohpe

The name @ghohpe was also mentioned a few times at @KanDDDinsky

Domain Storytelling

A Collaborative Modeling Method

by Stefan Hofer and Henning Schwentner

Drive: The surprising truth about what motivates us by Daniel H Pink

There is also a TLDR-Version: a talk on vimeo

Sapiens – A Brief History of Humankind by Yuval Noah Harari

This book was recommended by @weltraumpirat after our short discussion about how broken or industry is. Thank you Tobias! I’m afraid, the book will give me no happy ending.

UPDATE:

It is not a take-away from KanDDDinsky but still a must have book (thank you Thomas): The Phoenix Project

Base your decisions on heuristics and not on gut feeling

As a developer we tackle very often problems which can be solved in various ways. It is ok not to know how to solve a problem. The real question is: how to decide which way to go 😯

In this situations often I rather have a feeling as a concrete logical reason for my decisions. This gut feelings are in most cases correct – but this fact doesn’t help me if I want to discuss it with others. It is not enough to KNOW something. If you are not a nerd from the 80’s (working alone in a den) it is crucial to be able to formulate and explain and share your thoughts leading to those decisions.

Finally I found a solution for this problem as I saw the session of Mathias Verraes about Design Heuristics held by the KanDDDinsky.

The biggest take away seems to be a no-brainer but it makes a huge difference: formulate and visualize your heuristics so that you can talk about concrete ideas instead of having to memorize everything what was said – or what you think it was said.

Using this methodology …

  • … unfounded opinions like “I think this is good and this is bad” won’t be discussed. The question is, why is something good or bad.
  • … loop backs to the same subjects are avoided (to something already discussed)
  • … the participants can see all criteria at once
  • … the participants can weight the heuristics and so to find the probably best solution

What is necessary for this method? Actually nothing but a whiteboard and/or some stickies. And maybe to take some time beforehand to list your design heuristics. These are mine (for now):

  • Is this a solution for my problem?
  • Do I have to build it or can I buy it?
  • Can it be rolled out without breaking neither my features as everything else out of my control?
  • Breaks any architecture rules, any clean code rules? Do I have a valid reason to break these rules?
  • Can lead to security leaks?
  • Is it over engineered?
  • Is it much to simple, does it feel like a short cut?
  • If it is a short cut, can be corrected in the near future without having to throw away everything? = Is my short cut implemented driving my code in the right direction, but in more shallow way?
  • Does this solution introduce a new stack = a new unknown complexity?
  • Is it fast enough (for now and the near future)?
  • … to be continued 🙂

The video for the talk can be found here. It was a workshop disguised as a talk (thanks again Mathias!!), we could have have continued for another hour if it weren’t for the cold beer waiting 🙂