I think you're missing how "... procedurising everything so it can be followed by anyone to create predictable results" does not in fact lead to "McSoftware". Your 'procedures' don't have to be actually executable by a computer! Think of these examples:
- A support tech (you do have people answering phone calls from your customers, right?) takes a call from yet another irate customer because your hosted web-service (or hosted web-app [who still provides a 'local install'?]) is down.
- You need to implement and deploy a hotfix for a mission critical bug for your largest customer.
- While your developers are working on the next feature-sprint, the pool of unresolved bugs in your support system (you do have a support 'ticket' system, right?) is growing faster than your support techs or support developers can resolve them.
Now – what do these people do in these situations? And how do the managers or owners of this startup know what's everyone's schedules and priorities are and whether they need to be adjusted? How can all of the requisite data be collected so someone can even estimate this info? Here are some example procedures, in response to the example scenarios listed above:
- Your support techs know [and they were taught via the procedure "read this document ..."] enough about the web-service or web-app to know that the problem affects all of your hosted customers; they add a comment for the relevant ticket in your support system that the customer called and they lookup the latest comments in the ticket assigned to the tech or developer that's working on fixing the problem to learn that they estimate that the problem will be fixed in 30 minutes. When the problem is fixed, all of the relevant support techs are notified so they can then call all of the soon-to-be-less-irate customers.
- The relevant tech or developer creates a hotfix branch based on the release version for the affected clients. They check-in, build, and test changes using only that branch, and when it's deemed ready, it's deployed to the relevant production environment [itself another 'procedure'; hopefully some of these really can be executed by a computer!].
- Gary [huh?] is responsible for reviewing the pool of unresolved bugs in your support system each week – and techs know to escalate sufficiently important or urgent bugs before then! – when he notices that several bugs pertain to an area of your software for which recent changes were released, he pulls the relevant developers off of their new-feature projects to fix several related bugs.
The benefits of 'proceduralization' is that everyone that knows those procedures can then cache their decisions and everyone else that knows the same conventions can also easily know what to check to determine who's done what, when, why, and how. Procedures can be committed to mental 'muscle memory' so everyone can figure out the really hard problems of your business, instead of things like:
- What should I name the build output folder for the latest version of the app?
- Should I create a branch in source control for the latest feature I'm developing?
- Who should I notify when a project or task I'd previously estimated as requiring 3 hours will now require 6?
- How should I layout the controls on this form?
- Should I name this table 'clients' or 'Patient'?
The Ruby on Rails community calls this same general pattern convention over configuration. The point is to remove unnecessary decisions by adopting conventions (procedures, 'best-practices', etc.).
But don't forget that there are 'meta-procedures' which are responsible for reviewing and adjusting all of the other procedures as appropriate. There's nothing wrong with doing things differently, but it's immensely valuable to have an in-place way for everyone to do the common, routine tasks that make up a lot of the time working for a software company.
