levels of control
For as many different kinds of people there are out there, there seem to be different ways of approaching development. These different ways could probably be placed on a “control spectrum” where at one end (for the sake of argument, let’s call it the _Left_) you have the willy-nilly, cowboy-coding, answer-to-no-one kind of development that usually involves one programmer who’s never worked with others before.
This is identified by:
* lack of source control
* no distinguishing marks between ‘feature requests’ and ‘bugs’
* orders being rattled off verbally by the ‘boss’
* development done *on* production
* raw FTP
* programmed in notepad
* sub-par quality
* *fatal* crashes
The quality of the work is so low, that there isn’t even mention of QA, just “why doesn’t this #$*(& thing work??”
On the other end of the spectrum (again, let’s call this the _Right_), you have uber-control. A programmer has the authority to change only the lines of code he has been assigned, must do it in the style and number of characters dictated, as assigned by a black-box ticketing system, at the assigned time, for the assigned duration, at the desk to which he has been assigned on this day by the little lcd control thingy on his keychain (which needs to be authorized once a week), following the 372-page printed code manual given during the week-long orientation in Tampa or Memphis or someplace equally temperate and desolate.
This is usually identified by:
* disinterested programmers
* Everestine code libraries
* rigid feature sets
* long development cycles
* above-par reliable software
* documentation that fills several warehouses in Jersey City
* copious backups
Underneath all of this control is a direct relationship of overhead. The more control, the more overhead:
On the Left, there is no documentation, no tracking of development, no checking in to source control, no release procedures, etc.. At the same time, work is turned around quickly (with the exception of the “x=0″ Left), and is very adaptable.
On the Right, there are additional days, weeks, and months of generating documentation and diagrams, minutes added to development daily for checking in and out, releases are done in a scheduled and controlled fashion, accountability for every line of code, and even more time for testing and QA.
Since I started doing development, I’ve experienced all different kinds, and have a pretty good idea of where I fall in the spectrum. I started out as the sole developer, knowing nothing of good development practices. After a few years, I developed my own procedures to make sure things were a bit more controlled. Once I started working with a team, I learned how my old ways were insufficient, and worked with people to come up with procedures for doing development. I’ve even worked in such a highly regulated environment that my looking up code examples online was identified by the IT department’s proxy as me visiting “online gambling” websites, which warranted a “talking to” (which lead to me leaving that job). It wasn’t until a while later that I started exploring actual development methodologies, and learned not only the error of my ways, but how much I was doing right _naturally_.
As in most things, I tend to be a little to the left of moderate. I’ve picked up the bits of control that are eminently helpful to development and help produce quality code, while leaving behind all of the extra documenty-bits that don’t do anyone any good, save the company that makes printer paper. The question I ask myself is “after this is launched, will I be glad I’ve done _x_?” If the answer is yes, I do it. If the answer is no, I don’t. If the answer is maybe, I need to work out a rough cost/benefit ratio to determine if it’s worth the added overhead.
There are some things that I know I can do better, that involve more control, and thus more overhead e.g. Test Driven Development, and Feature Specs for QA. It feels a little bit like jump-rope… I’m waiting for the right moment to hop into it, but I’m sure once I get in there, it’s just a simple matter of jumping up and down.