The inherent value of simplicity

"Make everything as simple as possible, but not simpler." -- Albert Einstein

Simplicity: the lowest energy state of being; seen as beautiful or hurled as invective. Is it good or is it bad? In software engineering, the pursuit that engages all Knowledge Warriors in some fashion, simplicity is good, an attribute worthy of careful craft. Why? Because simplicity is efficient. Because simplicity is understandable. Because simplicity is challenging. Because simplicity is differentiated in the face of our complexity addicted culture. Consider that designing a piece of software with a single unnecessary feature requires 1 unit of design, 1 unit of build, 1 unit of testing, 1 unit of documentation, and 1 unit of maintenance. 5 units of effort are expended where 5 units could have been saved for expanding the boundaries.

"Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." -- Antoine de Saint-Exupéry

Why strive for a simpler solution? To enumerate a few of the most obvious reasons:

• Ease of explanation
  
• Openness for future expansion/maintenance
  
• Performance
  
• Reliability – fewer bugs
  
• Upgradability – fewer rules means less opportunity for failure in upgrade
  
• Testing needs reduced
  
• Usability improved
  
• Training time reduced
  
• Development time reduced
  

A simple design requires that we pare away unnecessary features. There are three types of unnecessary features constantly on my radar. Recognizing them is the first step in elimination.

1. Bells and Whistles: Great for sales and terrible for maintenance, this class of unnecessary feature is usually an addendum to a feature considered critical to a particular business function. They blur the line between needful and wasteful. Bells and whistles seem attractive in the abstract, but in-practice are rarely used and frequently broken. A Bell and Whistle here and there can add spice to the application for an end-user, but each will carry costs in performance and maintainability. Use them to please, but please sparingly—the delivery of solid, dependable business tools should be our primary focus.
   
2. Belt and Suspenders: A belt will hold up your pants 99.99% of the time, only spend money on suspenders when 0.01% will result in loss of life or limb. Belt and Suspenders are unnecessary features that address unfounded fears of failure in an application—paranoia expressed in design. Graceful handling of foreseeable errors and exceptions is important, but keep in mind that features added to handle imaginary errors are likely to become the source of errors themselves. A single, general purpose, pragmatic approach to dealing with system failure is best. More specific errors will emerge through testing and early production use—these will emerge from the quirks of each enterprises environment. Save time and money to fix these specific, actual errors in quick-response fixes post-rollout rather than waste ten-fold the time imaging and addressing all manner of potential problems whose multitude are unlikely to occur at all.
   
3. Better mousetrap: The third class of unnecessary feature is often the brainchild of a business expert. These are paths of processing that add competitive approaches to well-established processes that will also be incorporated into the application—multiple paths that reach the same business outcome. The challenge in recognizing and redacting these better mousetrap features is to determine which of two processing paths represents the most acceptable to the mainstream business. End-users are often confused by multiple options whose outcomes are equivalent. When two such paths exist an individual will often pick a path based on their own internal criteria and then favor that path forever after. A single, straight-forward path to fulfilling a crucial business need will instead be leveraged consistently within the user community. Multiple paths are more likely to complicate training, introduce the possibility of inconsistent processes, and result in the inevitable introduction of maintenance headaches.
   

   "Remember that there is no code faster than no code." -- Taligent's Guide to Designing Programs
   

PRPC OOP Terms: Classes

Abstract base class (ABC), is a class that cannot be instantiated; in PRPC this means that a clipboard page cannot be created using the class. An abstract class is designed only as a parent class from which child classes may be derived. Abstract classes are often used to represent abstract concepts or entities. The incomplete features of the abstract class are then shared by a group of subclasses which add different variations of the missing pieces.

Abstract classes are super classes which contain abstract methods and are defined such that concrete subclasses are to extend them by implementing the methods. The behaviors defined by such a class are "generic" and much of the class will be undefined and unimplemented. Before a class derived from an abstract class can become concrete, i.e. a class that can be instantiated, it must implement particular methods for all the abstract methods of its parent classes.

Partial classes are classes whose implementations are split over multiple Rulesets, making it easier to deal with large quantities of code and to allow selective substitution of implementation flavors using Access Group or Application Record as a means for switching-out one version for another at runtime. A primary benefit of partial classes is allowing different programmers to work on different parts of the same class at the same time. It also makes automatically generated code easier to interpret, as it can be separated from other code into distinct Rulesets.

PRPC OOP Terms: Public versus Private Access

In computer science, the principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change). In modern programming languages, the principle of information hiding manifests itself in a number of ways, including encapsulation (given the separation of concerns) and polymorphism. PRPC supports information hiding through both polymorphism (though somewhat limited polymorphism) and separation of concerns through its implementation of the class hierarchy and Ruleset packaging. Consider the following three "access modifiers" popular in most Object Oriented languages.

A concern is a generic term used to encompass any programmatic element (aka rule instances) including class definitions, activities, properties, streams, or other rule types.

Friendly: a property, activity, stream, or class that is accessible to the class itself and to all classes in the same Ruleset. A property or method is declared friendly by virtue of the absence of any more specific access modifiers.

Friendly access is accomplished by defining classes and other concerns directly inside the Ruleset housing the primary application. There is no restriction applied to internal knowledge between classes and concerns declared thusly. It is the easiest to implement (indeed it is the default) and the hardest to maintain.

Friendly Classes

Public: a property, activity, stream, or class that is accessible to every class with visibility to the Ruleset. It is distinguished from friendly access in that explicit access is must be specified to allow interaction between concerns contained by different Rulesets.

Public access in PRPC is implemented by allowing an application's primary Ruleset Version to have prerequisite knowledge of the Ruleset in which a class and related concerns are defined. It may be accomplished with a minimum of two Rulesets.

Public Class A

Private: a property, activity, stream that is accessible only to the class in which it is defined. Note that a class cannot be declared private as a whole.

Private access in PRPC is implemented by allowing an application's primary Ruleset Version to have prerequisite knowledge of the public Ruleset as above. The class in question is defined within the public Ruleset. Additionally, the public RuleSet Version is allowed prerequisite knowledge of a second private Ruleset into which private concerns are placed. The application itself may not refer to any concern defined within the private Ruleset; invocation of these concerns may only be accomplished through access to public methods (which may be a virtual method). This may be accomplished with a minimum of three Rulesets.

Public (partial) Class A with Private Class B

In such an arrangement, concerns that extend Public Class A may be included in the private Ruleset making Class A into a partial class. This allows concerns within Class A to be a mix of Private and Public access. Indeed, multiple Private Rulesets may be created to extend the private capabilities of Class A without impacting the integration between the application classes and the public interface of Class A.

PRPC OOP Terms: Methods

Methods are functions whose behavior is tied to a specific class. The intimacy of a method to its class allows extraordinary control over the state of objects derived from the class but also limits the behavior relative to other objects. This restraint assists developers in managing boundaries between objects and the classes that define them. Below are three special purpose method types with which you should be familiar.

Abstract method is a function whose behavior is appropriate to any objects derived from subclasses of an Abstract Base Class.

An abstract method is implemented as an activity (or other action-oriented rule type) whose "applies to" name part is a PRPC abstract class. It will generally operate only against properties defined within the abstract class and allow specialization of large portions of functionality by making frequent calls to Virtual methods (see below).

Virtual method is a function whose behavior, by virtue of being considered "virtual," is determined by the definition of a function with the same signature furthest down in the inheritance lineage of the instantiated object on which it is called. By convention, virtual methods are typically implemented within Abstract Base Classes. This concept is a very important part of the polymorphism portion of object-oriented programming (OOP).

A Virtual method is implemented by creating a "stub" or Activity with no steps (or other rule type) in a parent class and a like-named, overriding method Activity in a subclass with steps defined. An activity intended to use the method against a subclass Instance at run-time will call the virtual method using a Step Page whose class is defined as being of the (usually Abstract) parent class. At compile-time, access is validated against the Virtual method (Activity) and at run-time the overriding method (Activity) is executed.

Static methods act at the class level rather than at the instance level. Therefore, a static method cannot refer to a specific instance of the class. They may be found in both concrete and abstract classes.

A static method is implemented as an Activity that does not operate on its Primary page. Any internal functionality will use pages explicitly created via Page-New, Obj-Open, etc.. It may therefore be invoked without an appropriately instantiated page using a Call <class name>.<static activity name> syntax with an empty Step Page.

Pattern Finding and Following

Patterns guide all human action. We have instincts that call for repetition of behaviors that have proven successful (or at least not lethal) in the past. We walk in the literal and figurative footsteps of those that have come before us. In application design and development we should exploit these instincts to create unity in form where the form is initially set through thoughtful intent.

Cornerstone patterns are macro-patterns that define the majority of the application's internal structure and guide the application of more granular patterns in the fulfillment of the intended features. For within each level of a pattern are embedded sub-patterns mirroring the symmetry of nature.

As a designer, your job is to define the cornerstone patterns that suit the constraints of a project. Project constraints are formed by functional needs, architectural mandates, team skills, project economics, and the like. A designer may also identify sub-patterns that should govern the approach solving smaller problems within the project.

As a developer, your job is to understand and enact the patterns identified as cornerstones of the project, to recognize and repeat the sub-patterns established by fellow developers, to contribute to a collective pattern-spinning. The use of the right patterns is critical to producing an application which is maintainable and a creative process which is efficient.

Programming to Interfaces not Implementations

What is an implementation?

An implementation is a specific approach to fulfilling the desired operations on a given page.

What is an interface?

An interface is an abstraction of specific operations into higher-level meta-operations; abstractions provide activities and properties that are common not only to a specific page format but to a whole set of similar pages.

How does PRPC make interfaces possible?

1. Polymorphism




Abstract class definitions can have activities defined without steps but with parameters defined. These activities are the interface.


A subclass can have the same activity defined but with specific steps that actually do something. These activities are the implementations.


An application that uses the class can define a property as being one of the abstract parent class and use Call method to invoke one of the interface activities on the property.


The Page-Change-Class or Page-New can be used to create a page structure that reflects a specific subclass of the defined abstract parent class.


At run-time, the specific version of the Activity in the subclass is fired even though the validation occurred against the abstract version.




2. RuleSet Prerequisites and Run-time RuleSet Lists




PRPC allows the creation of two different RuleSets that can contain identical activity definitions.


One is created as xxxBase has activities with empty steps. This RuleSet forms the Interface.


Another is created as xxxImpl has the same activities with actual steps defined. This RuleSet forms the Implementation.


The RuleSet version of the calling application is has the xxxBase RuleSet added to its prerequisites.


Activities are called from within the application and validate against the versions in the xxxBase RuleSet.


The xxxImpl RuleSet is placed above the xxxBase RuleSet in the Application records list of associated RuleSets.


At run-time, the specific version of the Activity in the xxxImpl RuleSet is fired even though the validation occurred against the abstract version from the xxxBase version.

KROME modules make heavy use of the latter approach to allow the possibility of changing system behavior through deployment action and security tweaks rather than through programming.

OOP in BPM

BPM is still something of an exotic animal compared to most other IT tools. BPM tools represent a blend of features inherent in 4^th generation programming languages with some tools such as Pega's PRPC adding a strong flavor of 5^th generation facilities. In the rush to distance such tools from the practices employed by developers of 3^rd generation (Java, C#, C++ etc.) object oriented applications, BPM developers have so far failed to emphasize those computational best-practices that still apply to application development using these new tools. The promise of these higher-level generations is to remove the programmer from the development chain; perhaps this promise precludes those mental models that require professional mentality to understand and exploit. Whatever the case, we Knowledge Warriors are clearly members of the professional caste of BPM practitioners and, as such, will need to balance best-practices in computation with business savvy.

Object Oriented Programming techniques as a computational best-practice are very much germane to our development of BPM-enabled applications. By extension, OO Design Patterns should also be part of our toolbox. For a good, basic intro to OO Design Patterns that a quasi-geek can understand, check-out the book "Head First Design Patterns" published by OReilly. For a nerdier treatise, check-out the, now classic, "Gang of Four": Design Patterns: Elements of Reusable Object-Oriented Software.

I will try to give you a brief review of this thinking and draw parallels to PRPC development over the course of the next month. Here are the major OO Design principles to be aware of with links to some detailed articles on what each one means.

The first five principles are principles of class design. For the most part these OO Classes translate into PRPC Classes. The principles are:

SRP	The Single Responsibility Principle	A class should have one, and only one, reason to change.
OCP	The Open Closed Principle	You should be able to extend a classes behavior, without modifying it.
LSP	The Liskov Substitution Principle	Derived classes must be substitutable for their base classes.
DIP	The Dependency Inversion Principle	Depend on abstractions, not on concretions.
ISP	The Interface Segregation Principle	Make fine grained interfaces that are client specific.

The next six principles are about packages. In our context a package is a unit of deployment rather than of programming: usually this means a RuleSet but might also be an Application or Product collection.

The first three package principles are about package cohesion, they tell us what to put inside packages:

REP	The Release Reuse Equivalency Principle	The granule of reuse is the granule of release.
CCP	The Common Closure Principle	Classes that change together are packaged together.
CRP	The Common Reuse Principle	Classes that are used together are packaged together.

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

ADP	The Acyclic Dependencies Principle	The dependency graph of packages must have no cycles.
SDP	The Stable Dependencies Principle	Depend in the direction of stability.
SAP	The Stable Abstractions Principle	Abstractness increases with stability.

The Iterative Pace

A development iteration should be approximately 2 weeks long. The size of the team determines how much work should be done in the course of the iteration, not how long it lasts. Why two weeks? Because it is enough time to make significant strides, but not enough to a) dull details or b) make feedback difficult to incorporate. These are the principles that drive the pace described below. In each iteration the team should engage in just enough of the design, build, test, document cycle to capture accurate content with a minimum of effort: This is the meaning of efficiency.

The end of iteration demo is often seen as the focal point of the iteration: It is. However, you must remain committed to the idea that the demo is to show the product of the iteration and not that the iteration is to create the product of the demo. This subtle difference can be the yardstick against which decisions should be made during the iteration.

Expectation management is key to running a successful iteration. We are expecting and welcoming direct feedback from our clients. We must be able to focus their attention on items which are malleable and on requests that are fulfill able within established scope boundaries. On rare occasions, we find a requirement that will force a realignment of scope and project boundaries: These we must face head-on. It is one of the benefits of the iterative approach that requirements are vetted and scope is managed in real-time. We expect that expectations are wrong and that requirements are incomplete to start. Our process adapts to those accepted failings and maximizes the likelihood that our final result will be better suited to the tasks than anyone could have initially imagined. It is collaborative, it is dynamic, it is rewarding.

Here is a rough sketch of each iteration's pace:

1. Day One:
   
   1. Review feedback from previous iteration.
      
      1. Incorporate simple changes.
         
      2. Plan for larger changes.
         
      3. Alert PM to any possible scope or timing impacts.
         
   2. Review portions of previous iteration goals that did not get done.
      
      1. Plan for finishing.
         
      2. Alert PM to any possible scope or timing impacts if feature has been deprioritized.
         
   3. Review feature scope for the current iteration.
      
   4. Discuss design approach.
      
2. Day Two – Day Seven:
   
   1. Design
      
      1. Quick bursts driven by pictures
         
   2. Build
      
      1. Collaborate
         
      2. Add notes where appropriate
         
      3. Document progress with screenshots and short mnemonic annotations in OneNote
         
   3. Review with team
      
      1. Incorporate feedback.
         
3. Day Eight:
   
   1. Take stock of progress.
      
      1. Prioritize finishing tasks and defer new tasks.
         
      2. Set expectations of client about feature and finish levels.
         
   2. Finishing build.
      
      1. Stub interfaces or advanced features to create simulated function.
         
4. Day Nine:
   
   1. Unit test.
      
      1. Confirm technical soundness of establish functionality.
         
      2. Document procedures with screenshots and autotest spreadsheet data.
         
         1. Document results of Unit tests.
            
         2. Repair simple defects.
            
         3. Note major defects for next iteration.
            
      3. Set client expectations for iteration based on known issues.
         
   2. Peer review
      
      1. Check internal documentation level –
         
         1. Usage and Descriptions
            
         2. Activity Steps
            
         3. Flow Comments
            
      2. Review and revise based on naming standards.
         
      3. Seek improvements for stability and maintainability.
         
      4. Check compliance against architectural mandates.
         
         1. Repair simple violations.
            
         2. Note major violations for next iteration.
            
   3. Architecture review (maybe performed by Architect or Lead Developer)
      
      1. Confirm technical soundness of establish functionality.
         
      2. Check internal documentation level.
         
      3. Review and revise based on naming standards.
         
      4. Seek improvements for stability and maintainability.
         
      5. Check compliance against architectural mandates.
         
      6. Contribute a brief write-up of findings.
         
      7. Review findings with lead developer and/or team.
         
5. Day Ten:
   
   1. Collate design documentation, unit test results, peer review, architect review results with auto-generated documentation.
      
   2. Set expectation of client about demo content.
      
   3. Forward documentation to client.
      
   4. Demo content:
      
      1. Reset expectations about demo content.
         
      2. Demo the content.
         
      3. Reset expectations about demo content (not a typo, do it again).
         
      4. Collect feedback.
         
         1. Positively acknowledge understanding of feedback.
            
         2. Incorporate simple changes and redisplay.
            
         3. Discuss larger changes in context of current priorities.
            
            1. Set expectations for effort involved and impact on design imperatives.
               
            2. Seek reprioritization.
               
      5. Set expectations for next iteration.
         
   5. Set the stage for next iteration.
      
      1. Review iteration progress with team.
         
      2. Discuss feedback from peers, architect, and client.
         
      3. Export Product to zip to preserve demo content.
         
      4. Roll RuleSet minor versions (usually minor).
         
      5. Rest.
         

10 Technical Verbs You Must Know

Object: Page


1. Instantiate – To form a clipboard page from a class.
   
2. Persist – To store the contents of a clipboard page.
   
3. Embed – To instantiate one clipboard page inside of another.
   

Object: Properties


4. Define – To specify a class or property within a specific context.
   
5. Declare – To specify the context and algorithm that should be used in future derivation of a property's value.
   
6. Derive – To calculate a property's value using an algorithm applied in the context of other known values.

Object: Activities


7. Execute – To cause an action to be performed.
   
8. Invoke – To cause an action to be performed on one or more clipboard pages (objects).
   
9. Trigger – To cause an action to be performed based on an external event.

Object: Consultant


10. Kickass – To properly apply verbs one through nine.
    

Project Decomposition Terms

There are a least a dozen different terms in broad use for very similar concepts. We are trying to focus our own nomenclature to give us a more consistent presentation to each other and to the world. Using the same terms to mean precisely the same things, we lower to barrier to introducing consultants to projects—the uncertainty is reduced because the form is familiar like sitting in your favorite chair.

Project decomposition is an important principle for surviving complex software projects. It allows planning in smaller, more manageable chunks of time and functionality. It creates regular milestones that make progress tangible. It enforces rigor to finish and finalize in smaller, less taxing increments. Do it, you will like it.

Iterations are temporary build milestones:

• 1-2 weeks of effort, design/build/unit test
  
• Demo-ready
  
• Increment your patch-level RuleSet versions for each
  

Slivers are temporary build artifacts:

• 6-8 weeks of effort [3-4 iterations], design/build
  
• Smaller, individually-useful, 'partial' applications
  
• Tested [2 week], patched and documented
  
• Production-ready, but not necessarily deployed
  
• Increment your minor-level RuleSet versions for each
  

 

Modules are a permanent design elements:

• Technical vs. Functional
  
• Reusable and Individually testable
  

Releases are a temporary deployment artifacts:

• One or more Slivers, though ideally no more than 2
  
• Practical selection based on deployment windows
  
• Production visible, so involved transition activities such as training and support
  
• Increment you major-level RuleSet version for each
  

Applications are permanent production artifacts

• Increment your Application record version for each
  

 

 
 

 
 

  

Creative Destruction and Taking Steps

Two key concepts from my "10 Guiding Principles for Surviving Complex Projects" post:

• Taking steps
  
  • A step in wrong direction is better than no steps in the perfect direction. Progress is more valued than perfection.
    
• Decriminalizing change:
  
  • Embrace creative destruction. Learning quickly is better than planning perfectly.
    
    

I recently had the chance to speak to a project team on these related topics. Together, they encapsulate crucial expectations about the performance of all Knowledge Warriors. Faced with an unclear directive and lack of specific direction, you must take steps to further the task. This doesn't mean that you should not seek additional clarity. You should try and try again. If clarity is not forth-coming, you should use best judgment. Pick an approach or direction: test that approach. We will never punish someone for taking steps—we can explore and improve your judgments, we can decide to reverse or redirect, but we cannot criticize motion in the face of uncertainty. That is always praise-worthy.

Implicit in this contract between management and staff is the open acceptance of creative destruction. Creative destruction means that 'rework' is not indicative of failure. Rework is a natural result of our process that encourages experimentation, learning by doing, and forward momentum. From kindergarten to corporation, fear of failure has been instilled. The wrong answer is punished. Not here. Wrong answers are expected and encouraged in the spirit of inquiry and step taking. This is what makes us great. Explore and be wrong. Revise and get right. Test and share. Expect to have some of your best work 'thrown away'. Expect to learn from every step you take. Expect that your managers and your teammates will be disappointed only if you fail to take steps.

Why do we think this is so important? Because we deal in the reduction of uncertainty, the resolution of chaos. Building and preserving forward momentum for a project is critical to vanquishing entropy and injecting clarity. Momentum, forward progress, is always hard to achieve. To stand and await direction is to give hard-won ground to the enemy, chaos. I have seen many great pieces of software languish because a project simply lost momentum. Don't allow it.

Convention over Configuration

"Convention over Configuration is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility." -Convention over Configuration, Wikipedia

A very promising tool in an application designer's toolbox is a concept known as Convention over Configuration (CoC). It is related to the concept of Design by Convention (D by C) in that the "people" involved in D by C are end-users where CoC concerns developers. Addressing the conventions used by developers is generally what is involved in the creation of modern Software Frameworks. Probably the framework that most openly embraces CoC, and is my favorite technical movement born this century, is Ruby on Rails (RoR). RoR is a web-application development framework based on the Ruby programming language.

By decreasing the scope of change through the application of reasonable defaults, we define a box within which a designer/developer can truly thrive. They thrive because we reduce the cognitive load imposed by the approach allowing more crucial mental space for the complexities of the problem/solution. Cognitive load theory, in simple terms, says that people have a finite amount of mental space available for processing of tasks. To make people more effective, we must help them optimize their mental space (ie. reduce the cognitive load).

What does it mean to us? Convention over Configuration means that we follow a small set of well defined 'rules' or conventions that allow us to make simplifying assumptions about a solution space.

Putting CoC into Practice

Making your Conventions clear and malleable using the 5.3 feature called Declare Pages and the concept of DRY (Don't Repeat Yourself).

Rule-Declare-Page sets up a rule that will create a special sort of clipboard page that all requestors on a node will share.

Create a class to hold properties relating to the Conventions that your application requires.

An activity that simply uses a model to populate the page will be used to "load" the page to the clipboard when accessed the first time.

The model sets the values to match your defined constants to drive your Conventions.

To use the Convention constants, put a reference to Declare_Conventions - IQ-Convention into your Pages and Classes and then refer to its properties as usual.

.pyAssignedOperator = Declare_Conventions.WorkBasketPrefix + .ProductCode + Declare_Conventions.WorkBasketPostfix

On the clipboard, you can see the Declare_Conventions page contains the properties and values that you defined.

After the activities run, you can see that the values have been used in the concatenated Property-Set.

What Conventions are set in this example?

1. All WorkBasket names will be the ProductCode with the value "@IBX" appended.
2. All Skill names will be the HoldCode value with the value "ITS_MHSHC_" prepended.

Now that we can make the Convention and know how to utilize the conventions, what are the conventions that drive the design of your current system?

10 Guiding Principles for Surviving Complex Projects

Knowledge Rules excels at the implementation of complex projects. We embrace a style which allows us to make, communicate, and capitalize on progress. The key to survive and thrive is to turn complexity into simplicity in your mind and the minds of the team. Embrace a zone of calm and simplicity without ignoring hard work. Here are a few guiding principles about how to do just that:

Imperfect knowledge:

1. Focus on knowing enough to start (or step) rather than enough to finish. learn to operate with imperfect and incomplete information.
   
2. 15-minutes each day. Chaos is the natural state. Every day inject 15-minutes of order. Gray areas outnumber both the black and the white; chip-away every day.
   

Reduce the mental scope:

1. Decompose and ignore. Use the big picture to chunk-up the problem. Then chunk-up the chunks again.
   
2. Consider the 'Happy path' first. Shoot for the center of mass. Target 80% of the value and deliver 100% satisfaction. Don't wallow in the complexity of exceptions.
   

Taking steps:

1. A step in wrong direction is better than no steps in the perfect direction. Progress is more valued than perfection.
   
2. Build to show, show to inspire, inspire to build.
   

Decriminalizing change:

1. Embrace creative destruction. Learning quickly is better than planning perfectly.
   
2. Fail fast, cheap. Take risks, but take them quickly. Indecision consumes more than action, failure, and recovery.
   

Getting done:

1. Done is better than perfect. Emphasize function over perfection.
   
2. Rinse, repeat: find your iterative groove to improve.
   

I will add detail to each step in following postings.