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.
Outline/Structure of the Tutorial
This architecture is built on four rules and several conventions.
- You must set properties on an object using the universal set() function.
- You must get values from an object using the universal get() function.
- All functions that want to update values within an object must register themselves as “listener” functions within the init() function of the object.
- 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.
// ‘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.
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.
- 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
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
- An understanding of Object-Oriented programming
schedule Submitted 9 months ago
People who liked this proposal, also liked:
Roland Cuellar - Experience Report: Agile and Lean UX Techniques for Hardware DevelopmentRoland CuellarManagement Consulting Practice LeaderLitheSpeed LLC
schedule 10 months agoSold Out!
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