Wednesday, April 16, 2008
Process as a substitute for competence
Have you observed the uptake of the word agile by lots of enterprisey folks whom are more than capable of using it in a sentence but otherwise have zero clue about the values behind it...
Why can't so called champions of Agile simply admit that they are doing unmodified 1977 style waterfall? You will typically find that most enterprises who outsource work to India where the developers are largely out of contact with architects results in a staggering amount of process.
On one recent project, a developer I knew wrote a custom authentication scheme for Siteminder doing pair programming which took only fourty five minutes. Management of course insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.
The code in question? He started with a sample application and modified six lines lines of Java.
If you believe that the need for process is strong without questioning in the same breadth as to whether it needs to be heavy then you really should smack yourself silly every time you use the word Agile.
I humbly predict that the socialization type architects will drive the enterprise into the ground. The ever increasing amount of meetings is simply a so-called agile way of documenting less but otherwise still wasting time where neither no one actually understands nor does work get done any faster. Recently, I was asked whether I felt comfortable with a particular project moving forward. I could have used my influence to simply state that I don't feel comfortable while also avoid articulating any rational reason for not and could have gotten away with it.
Anyway, Why on earth is so much process present? Why does it take three documents and six meetings to write six lines of Java? There are twice as many pages of documentation as lines of code! Well, having worked with the people involved on these documents, plus the development, and the testing, not just on this project but several others, I think I've figured out the purpose: process is being used as a substitute for competence.
The funny thing is that I too am losing my sense of humor and are starting to become borgified and believe that CMMi is the perfect way to use process as a substitute for competence. With enough steps, documents, design reviews, and test plans, I think that the proverbial 1,000 monkeys with typewriters really could produce a functional IT system. The incredible amount of mutual reinforcement breaks the task down into such minute pieces that each piece is comprehensible and completable by anyone with even the slightest modicum of coding or testing ability.
The added advantage is that no one is required to think let alone understand. It even helps project managers to a pretty good degree of accuracy how long each minute task will take, and can thus do a pretty good job coming up with a (obscenely long) timeline for a project in any stage of development.
If the business only knew that IT didn't actually know IT...
| | View blog reactionsWhy can't so called champions of Agile simply admit that they are doing unmodified 1977 style waterfall? You will typically find that most enterprises who outsource work to India where the developers are largely out of contact with architects results in a staggering amount of process.
On one recent project, a developer I knew wrote a custom authentication scheme for Siteminder doing pair programming which took only fourty five minutes. Management of course insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.
The code in question? He started with a sample application and modified six lines lines of Java.
If you believe that the need for process is strong without questioning in the same breadth as to whether it needs to be heavy then you really should smack yourself silly every time you use the word Agile.
I humbly predict that the socialization type architects will drive the enterprise into the ground. The ever increasing amount of meetings is simply a so-called agile way of documenting less but otherwise still wasting time where neither no one actually understands nor does work get done any faster. Recently, I was asked whether I felt comfortable with a particular project moving forward. I could have used my influence to simply state that I don't feel comfortable while also avoid articulating any rational reason for not and could have gotten away with it.
Anyway, Why on earth is so much process present? Why does it take three documents and six meetings to write six lines of Java? There are twice as many pages of documentation as lines of code! Well, having worked with the people involved on these documents, plus the development, and the testing, not just on this project but several others, I think I've figured out the purpose: process is being used as a substitute for competence.
The funny thing is that I too am losing my sense of humor and are starting to become borgified and believe that CMMi is the perfect way to use process as a substitute for competence. With enough steps, documents, design reviews, and test plans, I think that the proverbial 1,000 monkeys with typewriters really could produce a functional IT system. The incredible amount of mutual reinforcement breaks the task down into such minute pieces that each piece is comprehensible and completable by anyone with even the slightest modicum of coding or testing ability.
The added advantage is that no one is required to think let alone understand. It even helps project managers to a pretty good degree of accuracy how long each minute task will take, and can thus do a pretty good job coming up with a (obscenely long) timeline for a project in any stage of development.
If the business only knew that IT didn't actually know IT...
