Global Nerdy

On Tuesday, Venkat Subramaniam, author of a lot of great books, including the award-winning Practices of an Agile Developer, gave yet another one of his insightful, informing, and entertaining presentations at the joint meetup run by three of Tampa’s big tech meetup groups, Tampa Bay Techies, Tampa Devs, and Tampa Java User Group.

When I arrived at the venue, Kforce’s office — Tampa’s cushiest meetup venue — the cafeteria area just outside the presentation room was already packed.

In moving from Toronto to Tampa — ten years ago in March! — I had to get rid of most of my books, keeping only those that had either great meaning or great usefulness.

One of those books that I held onto was the first edition of Subramaniam’s Practices of an Agile Developer (there’ve been six editions in total).

So I did the natural thing: I brought it to the meetup so that I could get it autographed!

I love the photo above, which Ammar Yusuf took. It looks like a Bollywood buddy film!

The book was published in 2006, and even after all this time, a lot of it is still applicable, thanks to the book’s emphasis not on technology, but on people and practices. If you’re a software developer or manage them, you should read it!

I have never seen a meetup where not only every seat in Kforce’s presentation room was filled, but where they brought in additional seats, and the remainder gathered by the entrance.

It was great to see so many people from our developer community come out, as well as to see a great programmer, author, and presenter give a solid and entertaining presentation.

My thanks to Venkat Subramaniam for presenting, Kforce for hosting, and the organizers:

• Tampa Bay Techies
• Tampa Devs
• Tampa Java User Group

My notes from the presentation

• There are things I thought I knew that are no longer valid
• We need to constantly re-check our assertions and assumptions
• When building software, we need to consider:
  • Functional requirements, which stakeholders are quite focused on
  • We also need to spend time on non-functional requirements, such as performance and security
• There are a number of “ities” that we need to consider:
  • Scalability
  • Interoperability
  • Deployability
  • Configurability
  • Security
  • Accessibility (which we really need to pay more attention to)
• The answer to “What’s important?” can’t be “everything”

• Where’s the line between architecture and design?
  • Design decision changes hurt a little
  • Architectural decision changes can hurt a lot more
• What are the characteristics of good design?
• Consider the case of extensibility:
  • It’s a slippery slope
  • So much code has been written in the name of extensibility
  • I remember once writing code that modeled chemical reactions and thought I would extend it. The chemists who I worked with said that they only work with hydrocarbons, and those molecules would never behave in the ways my software would support
  • Extensibility requires the ability to anticipate really well
    • If we anticipate really well, we get extensibility
    • If we do it poorly, we get unnecessary complexity
    • Code is like a crowded train — the more people on the train, the harder it is to get in and move around
    • These days, I say wait until you see evidence of a need to change something before thinking too much about extensibility

• Reusability
  • Grady Booch says to make the code usable first, then think about reusability
  • Usability requires specificity; reusability requires genericity
  • Examples of reusability done badly:
    • Enterprise JavaBeans
    • The “PetStore” project
  • Standardization is important but has to follow innovation and active multiple users
  • Two phenomenal examples of reusability:
    • Ruby on Rails — based on hundreds of projects
    • Spring — what if we used POJOs, reflection, and XML?

• The SOLID principles
  • Consider the Single Responsibility Principle
    • Cohesion: code is narrow, focused, and does one thing really well
      • Like things are together, unlike things are apart
      • If you use design principles, try to keep in mind what value they provide
      • I found a sock and fork on a table. What questions would you ask about this?
        • What if I told you that the table was in a museum?
        • The lesson is that context matters
        • What may be right in a certain time may not be right in another
        • There is no one cohesion in general

• We do two kinds of partitioning all the time
  • Technology-based partitioning
  • Domain-based partitioning
• Which one is predominant?
• Most of us have been doing technology-based partitioning — it’s where we spend a lot of time and effort
  • Think of talking to a bank executive and saying that you’re building a client-server system — they’ll be confused, because as far as bankers are concerned, clients are customers
  • We have teams built around technology-based partitioning: “front-end developer, back-end developer, Angular developer,” and so on
  • Remember Conway’s Law!
  • In one example, I talked to a developer working for a bank who said they were on the front-end team. When I asked about making changes, they said “that’s back-end; you have to talk to them.” This is technology-based partitioning.
  • At another bank, I talked to another developer who said they were on the “move money” team. When I asked about making changes, they said “talk to my teammate”. This is domain-based partitioning.
• If you build the team around the technology, they will focus on the technology
• If you build the team around the domain, they will focus on the product
• Monoliths: We often focus on technology-based partitioning
• Microservice: We often (or should) focus on domain-based partitioning
• Client-server: You’re optimizing for technology
• Microservices: You’re optimizing for domain
• In talking to people building microservices, I ask “Why?”
  • The answer should be “In order to provide business agility”

• YAGNI
  • Don’t write anything until you really need it
  • There’s a balance between YAGNI and extensibility
  • Do what you know is needed
• DRY
  • The general idea is that every piece of knowledge should have a single, unambiguous, authoritative source of representation
  • It’s about removing of duplication of effort, not just duplication of code
  • I once consulted with a place that had a database where the tables had something on the order of 800 columns
    • Every application in the enterprise uses that database!
    • It’s DRY
    • Focus: Stability, not agility
    • Changing the schema will break a lot of apps
    • File change request — where progress goes to die
  • Two things in life and programming that I will never share:
    • Toothbrush
    • Database — Sharing a database loses encapsulation
  • The higher the encapsulation, the higher the business agility

• We want low coupling and loose coupling
• Do we want reuse?
  • Answer is typically yes
• Do we want to reduce coupling?
  • Also yes
• Increase reuse: increase coupling
• Reduce coupling: increase duplication and reduce reuse

• Microservces tenets:
  • 1. Encapsulation
  • 2. Autonomy of development
  • 3. Isolation of deployment — how do we provide?
• Performance
  • The most important question: Not if the speed is great, but is the performance adequate?
  • The end result of worrying about performance is the worry, not the performance
• Do microservices provide excellent performance?
  • No
  • They’re distributed across multiple services
• If you want more scalability, you have to reduce performance
• If you want more performance, you have to reduce scalability

• To fail 100%, be absolute in your demands
• Distributed transactions are so 20th century
  • They’re an interesting technical idea — zero practical
  • Technical transactions have to be extremely short-lived
• Two things are figments of the imagination for programmers:
  • Transactions
  • Concurrency

• Please never ask your business analyst/people: “Is consistency important?”
  • It plants the seed of fear in their mind
  • Remember the CAP Theorem!
  • You can’t provide all three of these at the same time
    • (Strict) Consistency
    • Availability
    • Partition tolerance
• If we work hard to deliver what’s not necessary, we miss out on the truly necessary things
• Architecting is an act of evaluating trade-offs

Worth watching

Following his theme of evaluating trade-offs, Decision Dials is a talk of Subramaniam’s from Devoxx UK earlier this year. It looks at the art of decision making, the consequences of the choices we make, and how they tie that into the everyday architecture and design of enterprise systems.