Agility in Software Architectures through PI (Property-Invocation) Programming

Your team process is getting Agile, but is your code Agile? How long does it take you to add a new feature? How about a logger that listens to every object in your application? For me it’s a just a few lines of code.

After designing software for over a decade for the DOD, the FDA, NASA, the DC Metro, multiple startups, and more, I discovered the architecture that made me truly Agile, and it became the foundation for my next decade of work. It was designed through what I call “looking back at the present from the future,” which is a long-winded way to say that it was designed around what would make an application easier to maintain, since on average 85% of the cost of any application is during its maintenance phase. Turns out this makes it easier to build applications from scratch too!

Property-Invocation Programming is like Story Splitting in code form. Each step of your workflow is encapsulated in a function, and the init() function for your object shows a map of how all those pieces come together, and in which order. With this map, you can have multiple developers working on the same object, and even the same file, without merge conflicts. Integration testing is just a matter of executing your functions in the correct order. And a year from now, when your Product Owner needs changes, but you’ve forgotten what you wrote, it’s all mapped out neatly in your init() function. No hunting for code. Just read what you wrote, add new functions, and insert them in the right order.

In this session I’ll show you the four simple rules at the heart of Property-Invocation Programming, and how to leverage them to create truly Agile software architectures. We’ll also look at how to build a new cross-platform (mobile and desktop) application from scratch that can handle anything your Product Owners throw at it. Plus I'll walk through the 5 Pillars of Modern Application Architecture that I used with my teams.

 
1 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Tutorial

This architecture is built on four rules and several conventions.

  1. You must set properties on an object using the universal set() function.
  2. You must get values from an object using the universal get() function.
  3. All functions that want to update values within an object must register themselves as “listener” functions within the init() function of the object.
  4. All functions that want to make non-destructive augmentation of object properties (e.g. formatting) must register themselves as “filter” functions within the init() function of the object.

The huge advantage of this approach appears during debugging, so it is usually not even noticed until after the first release, and then people “get it”. If, for example, you have an incorrect value or a missing value on an object, you can usually find out what went wrong by going to the object’s init() function and going one-by-one through the functions defined there until you find the error. Even if that doesn’t work, you can set a break point in the object where it loops over the array of filters. Using the “step over” function you can execute one listener at a time until you see the error appear, and that usually tells you exactly which function produced the error.

The second major advantage is that any get() or set() action becomes a potential future event. For example, let’s say we designed our object to save to the cloud on-demand when a button is clicked, but one year later we decide to implement auto-save. In PI Programming, we just add a global listener. With one line of code, an edit made to that object will now be automatically saved to the cloud.

Object.on(Object.save); 
// ‘on’ is how you add a listener. If no property is specified, it is always run.
// “Object.save” is the function to be executed

For another example, if you want to modify some values before a “save” event, you don’t have to create a “preSave” event. Instead, just add a filter to the object in the init() code, before the filter that creates the “stringified” version being sent to the server, and all of its changes will be applied before the object is saved.

It is essentially Story Splitting as applied to code. Each step of execution is its own function, and the init() function acts as a workflow map of how each of the code segments interact with each other, and in what order.

The third major advantage comes when applied in teams. Since each step is its own filter/listener function, you can assign each function to a different developer, and they can work on the same object, and even in the same file, without merge conflicts, for faster check-ins. Plus, integration testing is easier because you have the outline of the code mapped in the object’s init() function to track down collisions more easily.

Presentation Structure:

Fast-Forward History of the Evolution of Software Architecture (8 min)

  • 1 min: Procedural Code - How it all began (but sadly also how many people still write code)
  • 1 min: Functions - The first instance of reusable code
  • 2 min: Object-Orientation - A revolution in reusable code modules
  • 2 min: Java Beans - A standard for object interactions
  • 2 min: Event-Invocation Programming - A push towards encapsulation

The Principles of Property-Invocation (PI) Programming (16 min)

  • 4 min: Universal Getter - One function to get them all
  • 4 min: Universal Setter - A universal function to track all object changes for now and for all time
  • 4 min: The Filter Function - Modifying return values without modifying an object
  • 4 min: The Listener Function - Encapsulation and communication between objects based on property value changes

Real-World Examples (12 min)

  • 12 min: Kendo UI - A universal data object, and an infinite number of widgets that form the foundation for a single code base that can be deployed to the Web, compiled to Android, iOS, phones, and tablets, all from a single code base.

The 5 Pillars of Modern Architecture (9 min)

  • 1 min: PI Programming
  • 2 min: Whitelist, Role-Based, Server-Side Security - Always assume nothing, and add permissions explicitly, where nobody can mess with them
  • 2 min: Augmented HTML - Seriously, start with HTML and Hybrid-Web architectures wherever you can
  • 2 min: The Degrees of Maintenance Theory - The more layers you have been the UI and the database is directly proportional to the amount of time it will take to fix any bug, and add any new feature
  • 2 min: APIs - Separate your front end from your back end using No-Backend programming principles.

Learning Outcome

  • Learn a modern approach to structuring your applications, that's designed for the future, no matter what that future holds
  • Learn how to make your code infinitely reusable
  • Learn about the Degrees of Maintenance Theory and why you’re killing your productivity
  • Learn the 5 Pillars of Modern Application Architectures

Target Audience

Software Architects & Engineers managing code for large teams and across long lifecycles

Prerequisites for Attendees

  • An understanding of software architecture
  • Understanding of event-driven models
  • At least a cursory understanding of Javascript syntax
  • An understanding of Object-Oriented programming
schedule Submitted 10 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • George Dinwiddie
    By George Dinwiddie  ~  10 months ago
    reply Reply

    You hurt your submission by presenting this as the One True Architecture. It would be better to cover the advantages and disadvantages more evenly. For example, if you're worried about someone using an object wrong, it's way harder to protect against someone using the wrong property name contained in a string. Good OO practices can provide an object API that constrains usage. String usage is hard to constrain.

    • Pete Oliver-Krueger
      By Pete Oliver-Krueger  ~  10 months ago
      reply Reply

      I do get into the ins and outs in the presentation. I’ve always tended to avoid debate in a session description, but are you saying I should describe the debate?

      Specifically to your point about constraints, one of the principles of Property Invocation is that you choose to constrain how you write code, and very intentionally do not constrain your property usage. It’s actually about how when we give up control of how our objects will be used in the future, we actually create better, more-sustainable architectures that grow with the unexpected. And with Agile, of course, we want to “welcome changing requirements, even late in development.” (Constraints lock us into the known, and into the now.)

      I know there are a lot of “one architecture to rule them all” proposals in the wild that fall flat under scrutiny, but there are some designs that are truly universal. The predecessor to property-invocation, i.e. event-invocation, is built into Javascript, and every application written in Javascript uses event-invocation architecture. Object-orientated itself was a “One True Architure” approach that completely reframed how people looked at coding. Java Beans introduced rules that every Java Bean has to follow to comply with the standard. Each of these is an architectural evolutionary step, and in this presentation I not only lay out the progressive evolution of each of these new modes of thinking, but also lay out a case for Property-Invocation being the next one. It’s actually the same principles used by Roy Fielding in REST, but translated to be used in client-based objects. And because of these similarities, perfectly melds with modern REST-based APIs and offline, asynchronous, cross-platform architectures, which is where I used it over the previous decade. 

      • George Dinwiddie
        By George Dinwiddie  ~  10 months ago
        reply Reply

        The outline/structure is the proper place to have a conversation on the details with the reviewers.

        Having dealt with the problems of people using session variables (as one example) to hold values by name, I know how awful it can be. You have to search through the code to see how other parts of the code is using it. Usually people don't do that, so the same information is getting stored under different names and formatted in different ways and with different life-cycles, some of the values being still present when obsolete. Since you don't easily know who is using a given property, it's unsafe to delete anything. The cruft builds up quickly.

        Such an approach can work OK with a single programmer or a small disciplined group, but it goes badly in most cases. Even when it works, it's replacing explicit structure in the code with tacit structure in the mind of the programmer.

        • Pete Oliver-Krueger
          By Pete Oliver-Krueger  ~  10 months ago
          reply Reply

          Made some additional comments about the presentation in the outline to address your comments, and updates to the Abstract to reflect some of the points of interest. Let me know if I can clarify any more points?

          Thanks!


  • Liked Roland Cuellar
    keyboard_arrow_down

    Roland Cuellar - Experience Report: Agile and Lean UX Techniques for Hardware Development

    45 Mins
    Case Study
    Advanced

    Experience Report: Applying Lean UX to New Hardware Development

    We often hear how Agile and Lean UX techniques are applied to software development, but there is much less information available on how to use these same ideas to develop new hardware solutions.

    In this experience report, Matthew Maddox, VP of Digital Strategy at Mirion Technologies and Roland Cuellar of Lithespeed will show how Lean UX techniques were successfully applied to the design of new and highly complex integrated hardware and software products.

    Mirion makes complex, highly regulated equipment that is focused on radiological safety for national security, first responders, and nuclear power. Mirion’s radiation detection equipment is used to protect people from radiation exposure, secure major events, and track down illicit radiological sources. Over the past year, Mirion has been experimenting with agile and lean UX techniques to design it's next generation radiation detection hardware and software.

    In this experience report, we will hear how Matthew utilized rapid, lightweight, lean UX techniques to quickly develop hardware prototypes, gather feedback from past and potential new customers, and quickly pivot initial designs based upon feedback from customers.

    As a result of this important process innovation, Mirion is now embracing more modern digital and agile techniques to more quickly bring innovations to market that are more closely aligned with customer desires.

    Matthew Madox is the VP of Marketing & Digital Strategy, and lead the field research, primary design and customer validation phases of the next generation Personal Radiation Detector (PRD).

    Topics Include: Agile Hardware Design, Lean UX, Hardware and Software Design Integration, New Product Development, Engineering Culture Change