Principles Inform Practices Which Inform Process

Continuing in my nerdy output of management concepts** I want to highlight an important idea about management processes.

Studs in motion

Imagine a carpenter who took the blueprints for a house, read them once and then never checked back to make sure that all the details were right.  That carpenter built the whole house and upon completion the inspector showed up to review the first phase of the work.  The inspector would require that all the drywall would need to be ripped out so that the plumbing and electrical and structural work was done properly.   In fact if the foundation wasn’t properly inspected they may make you tear the whole house down to the foundation.  The mechanisms in place to make sure that the house can be moved into are strict to make sure that people who move into a house are safe and to confirm that the home will meet the minimum requirements of building code.

Final inspection processes are the worst gating mechanisms as far as efficiency is concerned.  Gating mechanisms are used to control bad output/content/products from hitting the public or releasing into production.  This is part of quality control work, which is important.  However, often decisions are made that trump the processes and I’d like to address that idea here.

Principles are basic assumptions that lead to actions for the individual.  If a company has hired an employee who has either under-developed, compromised, or incorrect principles then the outcome will be under-developed, compromised or incorrect.  This applies to me as much as anyone else as an employee.  I’ve had bugs in software because I compromised on my principles for the sake of time or in response to perceived pressure and the outcome was compromised [read: bugs in the code].  Instead I needed to work with the discipline and conviction that were the principles I knew.  This would involve test driven development, careful use of the tools that I had, and doing things the ‘right’ way.  Software Craftsmanship principles that lead to a quality outcome over and over.

Principles lead to practices – they’re things that I do and tell other people about so that when they’re doing what they do they might consider changing their practices based on the principles I’ve informed them of.  Maybe they add test driven development to their repertoire.  Maybe they break changes down into better modules of code so as to make it more  testable.  Maybe they teach me a principle so that I can do a better job because my personal craftsmanship toolbox is added to.  In the end the principles lead to best practices that are applied and expected between myself and the community of developers (or team) that I work with.

Processes – being required/enforced by an outside party (management, C?O’s, clients) – should almost appear as an afterthought.  They should be affirmed, but they should never trigger a gating situation.  Internal processes should exist, but should not come up as tests or mechanisms that lead to surprises.  Instead the value of  the process is to confirm that the right principles and the right practices were in place.  You see if the wrong principles and practices are in place then the technicians employing their trade can either figure out a way to bypass them, or they’ll slow down the whole race to completion of work because they ignored them and the problems weren’t discovered until the end.  If processes are finding issues then the principles and practices should be addressed first because they are the location of the problem.  You don’t need more processes, you need quality in the principles and practices of your team.

I’m learning this about myself the hard way – so this isn’t something that I’ve known all along, it is what I’ve seen in myself.  More processes will just slow down the final work of your team as they reach a release.  However, if the team is not responsive to education and learning proper craftsmanship principles and embracing practices of maturing craftsmen (and craftswomen) then they’re not going to be helped by more processes.  They may be a bad fit for your company or project.

Make sure you know the blue prints.  Make sure you know the best way to do things.  And for heavens sake, don’t let the inspector find your mistakes and make you do the work again – do it right the first time.

** ignoring that a majority of my readers are family who could probably care less