Red Green Repeat Adventures of a Spec Driven Junkie

Clean Architecture: NYC

I hosted Robert “Uncle Bob” Martin at my company for his event Clean Architecture NYC. Hosting all started on June 4, 2018 when a coworker saw this tweet.

I reached out and Uncle Bob picked my company to host Clean Architecture NYC.

October 24 was the event date and October 23 felt like Christmas Eve, I couldn’t sleep as I was both excited and nervous. Excited to host one of my software heroes: Uncle Bob, nervous about operational details for hosting!

I am a big fan of Uncle Bob’s work. Clean Coder helped me get back into software development after burning out after seven years of code and taking a three year break from programming. Uncle Bob’s software philosophies helped me get back into programming in a sustainable manner.

Clean Architecture: the Book

Clean Architecture: the Book

I read/listened to Clean Architecture before the event and found half to be items covered in Agile: Principles, Patterns, and Practice, which is a fantastic book. The other half is new material to me, that I found I wished I learned last year.

I thought the event would be about the book, but Uncle Bob went through the material in a way that both introduces the book’s material and goes into more depth if you have read it.

Since I read the book, the event gave me a deeper understanding of key concepts from the book. Interacting with Uncle Bob on certain topics brought additional revelations I missed when reading the book.

These are some insights I gained from Clean Architecture: NYC and the Book.

Uncle Bob Design Principles

Software Industry Disservice

This message Uncle Bob delivered during the talk:

There have been groups in the software industry that has done a
great disservice to the industry by acting more as a labrorer
than as a professional.

We, as individuals in the software industry, need to act like other
professionals, like doctors or lawyers: People come hoping for good
news, expect bad news.

This clarified my disdain for new software developer training trends and outsourced work. Getting the first software job can be tough, we need to be professionals, be able to bring bad news in a professional manner.

If you want to learn how to give bad news, see how doctors developed their way give the worst news possible from this 99% Invisible podcast - Breaking Bad News

Refactor Architecture too!

In Test Driven Development, there’s a step in the process where after tests are passing, one can refactor code to be better (or more generic).

To have clean architecture, I learned I need to refactor the design as well as code. When there’s new requirements, re-evaluate the design and adjust as needed.

  • Is the current design stable for others to use and flexible for the current change?
  • Is there any adjustments to the architecture needed, such as a new interface for newly extracted drivers?

There can be “design debt” for the architecture just like there is “tech debt” for code.

Good Code and Architecture

I am finally able to qualify what is good code and architecture:

Code that is stable and flexible.

Stable that others can depend on it to act consistently and if it changes, the change is painful for the author, so they must justify any changes.

Hence, using a language’s standard library or built-in functions is a best practice. If a language changes these functions, the community would raise hell and the language / library maintainers would have to justify to everyone, which requires a good reason when it is widely used and depended on.

Flexible means other programmers can easily modify the code to meet the needs of requirements.

These two are diametrically opposing each other. When code is too flexible, how can it be stable? When code is too stable, how can it be stable? Make a balance or using SOLID techniques can help, especially interface segregation.


I am so glad Uncle Bob picked my company to host Clean Architecture: NYC. At times, being a host was stressful as I was doing work outside of my normal day-to-day. Having Uncle Bob go over the Clean Architecture book brought deeper insight than reading the book possibly could.

Learning how it is important that we as individuals in the software industry have to be professional, not labourers.

Refactoring architecture is as important as refactoring code too. There’s such a thing as architecture debt and I have run into it, even with well tested code.

Finally, understanding how to evaluate what is good code and architecture. There’s a world of difference between writing code that others can depend on, but still flexible enough for others to solve their problems.

Above all, I was glad to be a host as that allowed not just me and people from my company to attend, but also other software professionals in the region to attend. I am glad I can give back to the community that has given so much to me.

If you have an opportunity to attend, better yet, host, an event such as Clean Architecture I highly recommend you do. If you would like to talk to me directly about hosting, please contact me