cogdogblog

How to Run a Dysfunctional Software Development Collaborative in Ten Easy Steps

The following is based on actual experiences. Names have been change.. nahhh, no names are used.

But I was there.

10. Do not set up any electronic collaboration tools, such as the basics that are available to anyone at SourceForgce.

9. Focus a large chunk of time and energy on conference presentations and theoretical papers.

8. Insist on meeting via expensive two way video conferencing, although some partners do not have access and others question the value of seeing each other talk.

7. Do not set up the project code as an accessible library that can be checked in and checked out or even viewed. Instead, parcel out complete updates on an irregular basis.

6. Promote members customizing code for their own purposes, but force them to re-write every line of modifcation to a new released update of the applicatiom.

5. Do not set up any source control or allow central parts of the code to be voted as stable, code, and therefore untouched.

4. Do not set up any kind of bug reporting system (despite availablity of ready-made ones); after all, we all have e-mail? And do not bother acknowledging bugs changed that have been reported by email. Get pissed off when questioned about this.

3. Allow an inexperienced programmer to iinfluence or control strategic direction (and certainly do not read Alan Cooper's The Inmates are Running the Asylum).

2. Encourage (#3) to respond to criticism of the application with personal attacks.

1. Charge a fee to be a part of this.

And a few more bonus steps to help you along:

* Respond to suggestions on user interface, "we hired a graphic artist to address this"
* Build the features that the project director likes as opposed to gathering data from potential users or generating user personas
* Build a system that can have only as many accounts as the number of directories the server's operating system can create.
* Build a user name log-in with no way for the user to retrieve a forgotten password, even for the system adminsitrator.
* Build a public web application that only works reliably on one browser.
* Rely on a database that has not been rationalized or even reviewd by a DBA, and why even optimize a table when you can keep adding another 100 fields?