Architect’s Master Class – A Rewarding Experience
When I came to Don’t Panic Labs (and Nebraska Global) in late 2012, I was less than two years out of college in my career as a software engineer. I had heard about not only the exciting projects that were taking place at Don’t Panic Labs, but also the great processes and structure around these projects. And, for the first time in my career, I was introduced to software architecture.
The first thing I was told to do when I started at Don’t Panic Labs was to watch the Zen of Architecture video. The presenter in this specific video was Juval Lowy. Who was that? WCF? People still use that? What is “The Method”? “The Method” and “IDesign” were common terms during my first few weeks that I had to learn.
Over the next three years, my view of software was completely changed. I had been a part of numerous projects architected using “The Method”. This was amazing. Our code wasn’t “wild-west-like” anymore. We had a strict set of rules defined to design our software around. There was no more chaos, and no more madness. Our software was iterative, highly testable, and not a casualty to change. I had realized the whole concept sought after by “The Method” was entirely usable, attainable, and successful.
I had heard about the Architect’s Master Class taught by Juval Lowy since a group from Don’t Panic Labs had previously attended several years ago. The experiences had during this initial attendance were the foundation for all software built by Don’t Panic Labs. In early August, four others and myself were given the opportunity to attend the Architect’s Master Class taught by Juval in California. I didn’t think twice about saying “yes”. I was more than excited to go. We were California-bound for the Architect’s Master Class.
Architect’s Master Class
The class was five days of non-stop process, planning, leadership, and architecture experience taught by Juval. He spoke of many years of experiences and successes across many domains of software. The five days covered everything I could think of – core use case development and reduction, project planning and resource allocation, service oriented architecture, service contract design – all encapsulated by the term “The Method”.
I was continuously amazed by his stories and insight. I have never been to a class so sobering and humbling – Juval really makes you think about why you’ve done things incorrectly in the past. But, he immediately picks you back up and demonstrates the correct patterns and processes for software development.
The Number One Rule of Software Engineering
By the end of our week, Juval had rattled off ten or so “rules” of software engineering, each more commonsensical than the last. These rules were becoming obvious to the point they were hilarious, yet sadly many of us as developers were not following them. However, the single rule that stood out the most was this:
$ > ;
This rule is so simple; it should be second nature to all developers. But most software engineers usually do not realize this until late in their careers, if at all. The rule describes that there must always be a proven and profitable business need for building any piece of software. Business use cases should decide software functionality. I am glad to have had this mentality instilled in me from the start at Don’t Panic Labs. Our developers have always been focused on building businesses, not language frameworks. If you find yourself spending weeks to achieve the slightest millisecond performance gain, or feel like you’re in a rabbit hole of code, ask yourself – does the customer care? You will hopefully realize this before implementing features that are not important to the customer.
Embrace Change
Juval talks about how functional decomposition is most prevalent in software engineering, yet it is the most flawed. Quite often building software this way will achieve an immediate goal or feature, but does not allow the system to evolve over time. Juval stresses decomposition of software by volatilities – encapsulating areas in the software that are susceptible to change. If we design software this way, we can embrace and encourage change in software systems that are exposed to ever-changing technologies. These areas of volatilities can be encapsulated and combined into fully-functional software systems.
Isn’t that a crazy thought? Designing software for change?! Once you accept the possibility, you will begin to design your software this way. No longer will you have to turn a manager away because they want new feature X.
Afterthoughts
I feel like my experiences with software architecture are still green, and I still have much to learn. But, I will never forget the opportunity I had to attend Juval’s class. If you seriously want to consider a career as an architect, attending a session at a local conference will not do justice. I completely recommend attending Juval’s Architect’s Master Class if you ever get the chance. The class fills up fast, with only 40 or so attendees each time. You will need to make your reservation many months in advance. But, it has been by far the best learning experience I have had in my career.
