Recently, I got to try out working in a couple different environments. Working in these environments helped me formalize some of the things that I like and some of the things I don't like. With these new environments I've come to realize my style of development. It's called **penance driven development**. It's called this because there are two important things:
1) It's better to ask forgiveness than for permissions
2) You need to be deserving of forgiveness.
So the concept is simple, whenever you break something, you first fix the symptom, then you improve the infrastructure so similar breaks should be harder to do. The cost of the penance doesn't have to be huge, but the penance has to be done, otherwise technical debt accumulates and people believe there is no downside to breaking things.
What needs to be improved depends on what is missing. For example, if an engineer broke a feature, but that feature didn't have a test, the penance should be to write a test. Even if the one that broke the feature isn't the owner or the one that wrote the feature. If someone breaks the build and no one noticed because the continuous build didn't email, the fix could be setting up the continuous build to email out build failures, or even better, run each change on a build bot before allowing commits.
I think I'll have to start a penance of the day blog/twitter stream.
I've been practicing this style of development for most of my career, and it's similar if less precise than the [5 whys][1] . As mentioned in the [The Lean Startup][2], the cost of the penance should be proportional to the cost of the break.
![][3]
[1]:
http://en.wikipedia.org/wiki/5_Whys
[2]:
http://theleanstartup.com/
[3]:
https://blogger.googleusercontent.com/tracker/6893636-7351862986128773327?l=phython.blogspot.com
URL:
http://phython.blogspot.com/2012/03/penance-driven-development.html
