coding

A few weeks back I was attending a local conference and the guy delivering the “speech” said something very powerful – “… always anchor yourself around the Principles that govern the game you are playing”. That statement hit me rather on a sensitive nerve and temporarily my neurons started firing faster and has resulted in this Post.

Suddenly, it seemed to make a lot of sense to pause all threads for a few minutes to identify (rather, try to identify) the principles that govern the modern day’s S/W development process. Once those Principles are identified, we could look at ways to “instantiate” them for our “daily purposes”. The core logic here is to look at each Principle as a “Class” (blueprint) and implementation of that Principle is like instantiating that “Class” and set the appropriate “state” for the same which results in multiple ways of implementation for the same Principle, as we vary the “state” on the fly or by nullifying “this” instance and re-instantiating it with a different state. Some people in the industry term such conglomeration of various instances spanning different “Classes” (Principles) with a defined “state” for the instances as “Process”.

So what does it mean when we say instantiate a Principle and set the right state into it? Let’s look at it with an example.

Principle: Have constant communication within the team and also with the Customer/end-users where possible.

Instance-1: User Yammer or any Enterprise Social Network Tool for communication purposes

State: 

Attribute 1: Meeting_Type = online

Attribute 2: Daily_Status_Update_Capture = Yammer_group

Attribute 3: Customer_Contribution = Yammer_group_Conversation

Attribute 4: Frequency_of_Physical_Meeting = Once a Week

Instance-2: Run a daily stand-up meeting

State: 

Attribute 1: Meeting_Type = telecon

Attribute 2: Daily_Status_Update_Capture= a simple MoM email share  after the meeting

Attribute 3: Customer_Contribution = join the telecon

Attribute 4: Frequency_of_Physical_Meeting = Daily

Instance-3 Use Cloud Docs daily

State: 

Attribute 1: Meeting_Type = Google/OneDrive Document/sheet Update daily

Attribute 2: Daily_Status_Update_Capture = everybody updates the crux (Yesterday’s work, blockers and today’s work) in the document on a         daily basis

Attribute 3: Customer_Contribution = customer updates the same document with comments where needed on a daily basis.

Attribute 4: Frequency_of_Physical_Meeting = Twice a Week

No, this does not mean one has to prepare documentation for each Principle but have this line of thought running though out the execution and make sure all the Principles are covered, the number of attributes one adds to these instances will dictate the complexity of the “Process” which most likely is directly proportional to degree of resistance from serious development teams.  So keep this as light as possible and identify the most important attributes that fulfil the current context – not more than 4 to 5 per Principle.

However, many a time, Process-sticklers miss out on laws of garbage collection sweeps that promote instances across Gen1, Gen2 and Gen3 and the “garbage” will have to be reclaimed.  As instances die off one could re-instantiate “garbage collected Principle/s” (or the ones with the potential for garbage collection), instances which are deliberately assigned nulls – Processes that are decommissioned deliberately- or the ones that are nulled out of normal Program control flow – Processes that are useless for the context and should be decommissioned but might be lingering around to impact the overall performance. These re-instantiated Principles could now be set with a different state/s to see if that improves the overall “performance”.  It is to be noted the more autonomous and lesser the attributes of these instances, easier the garbage collection sweeps will be and the faster we fail which by itself is a good news.

Below are a few Principles when implemented with appropriate instances with the right state into them worked well for me majority of times.

  1. Know Who are the target Audience/s for the developed Engagement/Product/Service
  2. Know and articulate the Business Goals
  3. Know What aspects are you going to develop and how each one of it are tied to the Business Goals
  4. Identify the “How” sooner, do not look too deep into the future – technology and business landscapes are changing rapidly
  5. Estimate the effort and have it reviewed by a capable person/tool
  6. Each Artifact that gets delivered must be Reviewed by a capable person/tool
  7. Do it “right” the First time – you may not get a chance in this “busy” world
  8. Have constant communication within the team and also with the Customer/end-users where possible
  9. Fail Fast on strategies – the longer you take to fail, more the cost implications are
  10. There is always a scope for improvement – define the boundary conditions
  11. You are responsible to identify and clean your “mess” – don’t rely on others
  12. Your deliverables identify you , your commitment and maturity levels – hence, be careful
  13. There are no One-man-shows – Synergy is the only key to “success”
  14. Work Hard and make this decision judiciously
  15. Everything could be questioned politely and be assertive about it, including these Principles – tailor make things for scenarios – there is no silver bullet
  16. Always keep the end-customer (users of the System) in the center

We all know that an Engagement/Product/Service is unique and hence the way these Principles are implemented (with a specific state in their instances) for one scenario may not be valid for other scenarios (Engagement/Product/Service).

Similarly, for a given scenario (Engagement/Product/Service) when the Principles are implemented for/by different teams due to varied team compositions and their experiences, the same state of instances may not work either.

While implementing the Principles for a scenario (Engagement/Product/Service) one could start with instances and set the respective state to the best of the synergies available. Now the trick lies in understanding that these instances could be garbage collected as needed, to decommission or re-instantiate with new (different) state and see if it is addressing the “performance issues”. So, it’s absolutely fine and is a recommended strategy to explicitly call System.gc();  or GC.Collect(); and then seed in new instances as needed – again, Fail fast.

So the whole game is about anchoring around the Principles and identifying/knowing your “instances” with the “right” state, instead of blindly following some “Process” as a silver bullet for every scenario which not only hits the morale of the team but the overall Quality and thereby your Customer Experience.

Please feel free to comment and share your “instances” and the constraints that drove you into a given “state”.