Over the years, I have worked for several companies where software development was at the core of their product offerings. As a Software Support Engineer, I’ve worked closely with the development team, and witnessed project management first hand. Some of the teams were small, only a few individuals with one level of management. These teams tended to work well, even without using any formal project management ideology. These teams were more like families than co-workers. Their relationships extended beyond the office walls, and none were afraid to speak their mind. Each was willing to speak up with what they had to offer, and ready to take on the tasks assigned to them. The methodology of this smaller team was “whatever it takes to get the job done,” and the company prospered. There was a limit to this cooperation, however, and it had to do with size. As the company grew, so did the projects, and the naturally scattered free-for-all methodology that had been so successful in the past, began to create bottlenecks in development velocity.
This leads me to a particular example that outlines the tragedy of cowboy-development, when it doesn’t turn out the results expected. A pair of brilliant developers were assigned the task of converting a Windows based application to a web based application using the latest ASP.NET architecture in the spirit of creating a platform independent contact management product. They were given their parameters and sent off to complete the project on their own. The project manager at the time was the CEO himself, and he thought he was clear on what he expected from the project. The developers also thought he was clear on what was expected. But at the end of several months worth of development, it became apparent that those expectations had not been communicated as clearly as they could have been.