--- Begin Message ---
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
--- End Message ---
_______________________________________________
tails-dev mailing list
[email protected]
https://mailman.boum.org/listinfo/tails-dev
