The aftermath

Ian Taylor notes in his [blog post] 1 about the rise of [Cargo Cult Programming] 2:

In today’s increasingly complex world of programming, when so much code involves integrating libraries in various ways, I expect that cargo cult programming is on the rise.

He is talking in context of developing open source software, but this applies to proprietary software development as well. In a commercial software development enterprise, cargo cult is less likely to be noticed or pointed out because peer review is no longer deemed necessary as there is so much to do with so few people to go around. Its easier to just turn a blind eye.

One of the many possible reasons, at least in corporations, can be the increasing pressure to deliver by an arbitrary deadline set by someone who does not really understand the work involved. In such situations, developers confront a couple of options when faced with a seemingly impossible goal:

Reason with the management to help them see why a deadline will be missed; or Go ahead and put together software that will be accepted by customer, with little concern for the day after; or Create a culture and a team that can deliver good software which meets aggressive schedule. Every team strives (even if pretends) to reach here. Afraid of trying (or after trying) option 1, developers take the easy route with option 2. They cut corners, copy/paste code, and do anything that needs to be done — in order to meet a deadline. And then they deliver. Everybody is happy, and life goes on. The feature is accepted and deployed.

The aftermath will be dealt with by technical support. What are they paid for, after all?