Sunday, March 7, 2010

Process as Infrastructure Enhancements

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/process_as_infrastructure_enhancements.htm]

Most devs I meet hate process, almost like it's a stupidity-tax from some ivory-tower folk (who themselves don't actually need to use the process that they're imposing on others). These devs just want to get the app done, and they think that the process gets in their way with tedious constraints that add no value. I recall projects with "process" like forcing devs to go and update all the internal variable names to be compliant with some new coding standard, or not allowing devs to have admin rights to their own machines until three levels of paperwork is approved (good luck being a dev using a Windows OS if you're not an admin), or requiring that developers test the app by taking success screen shots of every single step - and then printing out that 600 page doc and getting it signed by QA.

That sort of stuff bothers me too, but I'm still a big fan of good process. What I realize is that I essentially view "process" as "developer infrastructure enhancements". I think of process as helpful things like automation, unit tests, code generation, proper tools, CI builds, checkout and install scripts, etc...  Devs just want to get the job done, and good process assists them in doing that, it doesn't burden them with ivory-tower taxes. If your process code-generates the data access layer, then the dev need not do all that manual ADO.Net plumbing code, and hence the dev gets the job done faster.

Sure, it's semantics - "process" vs. "infrastructure enhancements", but semantics are important because it affects how a thought is communicated to other people, and people are important.

No comments:

Post a Comment