In reply to: Three Good Laws of Software Architecture

By August 16, 2012All 2 Comments

    This post comes from our friend and user Jonathan Fisher over at the CodeMechanicBlog.

    In reply to: Three Good Laws of Software Architecture

    What is the secret to good architecture? While there are plenty of posts written about this topic on the internet, I foundthis article on DZone (originally posted here) intriguing.

    The article is written by Niklas Schlimm, whom I do not know personally. The article can be summarized with three points:

    Three [proposed] Laws of Good Software Architecture

    1. Good architecture is one that enables architects to have a minimum of irrevocable decisions.
    2. To make decisions revocable you need to design for flexibility.
    3. To make use of flexibility one needs to refactor mercilessly.

    CYA Engineering?

    1. What I think Niklas is trying to say is: you will get it wrong, and sadly, you’ll get it wrong most of the time, so design an architecture where you can fix your mistakes with a couple of swaps. Is designing an architecture that allows you to revoke your decisions at whim really fair? Does the CEO get the same privilege?
    2. Flexible is not durable. They don’t build make buildings out of rubber. We’ve probably all worked on over-engineered legacy systems that were “flexible.” Most times, good intentions turning into dancing circles around libraries and frameworks in an unholy ritual of abstraction.
    3. You should be refactoring mercilessly, all the time. But do you need 10 layers of abstraction to do this? Do revocable decisions allow you to revoke custom code?

    Alternative laws

    Lets address the problem here. Code doesn’t age, or stop working, it’s Human’s that forget how things work, why decisions were made, and becomes disenchanted with the past. The input to the system changes, usage levels increase, and people leave the organization. The only real constant is the code itself!

    Given that, I present:

    Laws of software developed by Humans

    1. Humans cannot predict where software will be extended in the future. Instead trust in YAGNIand dependency injection.
    2. Humans cannot predict where software is slow. Instead we have profilers and the three rules of optimization.
    3. Humans cannot predict when or how business direction will change, the economy, or future technology enhancements. That’s why we have iterative development: Agile, <ahref=””>Scrum and XP.

    Refuting the laws given with the alternative laws

    1. Good architecture is one that enables architects to have a minimum of irrevocable decisions.
      Alternative law #3 says you won’t be able to predict which decisions are irrevocable. Instead of designing an architecture with revocable everything, design the minimum possible architecture that barely scrapes by to get the job done.Instead of developing your own bash build script, use Maven, and don’t do anything silly with it. “</amvn clean install” and “mvn clean deploy” should be all the commands you need to send your artifact onward.Instead of getting locked into a particular open source project or vendor, use JEE6 standards like JSF2.0, JPA2.0, JMS, and EJB3.1, or commit to using Guava and Guice. Simplicity is key, less is better. Using tools they way they were intended saves time.
    2. To make decisions revocable you need to design for flexibility.
      Alternative law #1 says you stink at designing for flexibility, so don’t do it. Rather than designing for flexibility, design an exit strategy document for each technology you use. This includes frameworks built in house: how will you exit from those once they become legacy code? (The best way is to abstain from writing them.)Alternative law #2 also applies here, don’t use obscure technology like a NoSQL database until you actually determine you’ll need a a NoSQL database by profiling. It you’ve truly designed minimum architecture and opted for simplicity, it will be simple to change out your backing store with a different database. It’s good to remember that you are not Google. If you design simple architecture, you’ll have plenty of time later on to switch to NoSQL when it’s needed, rather than rewriting a thousand lines of Redis specific JSON handling code upfront.
    3. To make use of flexibility one needs to refactor mercilessly.
      Given Alternative laws 1, 2, and 3, this brings old law #3 into new light. You should refactor mercilessly and eliminate technologies. Gage yourself: How many new technologies did you bring in versus how many exit plans did you execute?Develop a master engineering architecture plan. Every release should bring your closer to the master design, at which point, you should update your exit plans then update your master architecture plan. What technologies could minimize the architecture? Evaluate them… do they require glue code to be written? What frameworks can we exit from and what technologies aren’t working out? Get rid of them, quickly. What in-house utility projects (aka future “legacy code”) has been written? Open source it, replace them, or better yet, observe that YAGNI has manifested itself.

    Conclusion, flame wars

    When it doubt, don’t write it. Change your processes so you can use a tool without modification. Don’t dance around frameworks with unnecessary abstraction. Above all else, simplicity is key!

    Finally, remember this is an attack on complicated software, not the author of the original post. I’ve enjoyed reading his blog. I look forward to your comments!

    What do you think? Let us know in the comments below!


    • spiritual says:

      After exploring a handful of the blog articles on your web page,
      I truly appreciate your way of blogging. I saved it to my bookmark webpage
      list and will be checking back in the near future. Please
      check out my web site as well and tell me how you feel.

    • cblin says:

      IMHO, you are misinterpreting the original post and you say the exact same thing !

      You speak of an exit plan and this is the exact same thing as “minimizing irrevocable decision” + “refactoring mercilessly”.
      Because as soon as you envision that you will need to replace a technology with another one, you are avoiding the irrevocable decision…
      And of course, as soon as you write an exit plan you will need flexibility in order to execute it one day
      And as soon as you execute an exit plan, you are refactoring mercilessly…

    Leave a Reply

    Your email address will not be published.