watch this  

The company I work for is very process-driven. So much so, that it has patents on processes. But my current client (and former employer) is very much of the “Make it happen” mentality.

While I can see the benefits of both a process-driven and an informal, relationship-driven approach, I wonder how well the process-heavy schemes will hold up in an environment where the customer is not particularly tech-saavy. These business users are in the business of whatever it is their company does—not in the software business. They’re not NASA, either. Software exists only as a means to an end. That’s something that can be hard for a developer to swallow.

One of the tentants of the Agile Manifesto is “Individuals and interactions over processes and tools”. To me this means, the days when the business user would call you up on the phone or walk into your office and say, “make it happen” and you’d do it. That works great until it doesn’t. Often you end up with a lot of specialization and dependence on a particular individual. And there’s no transparency (and probably no audit trail). But here, I think developers can help themselves and each other: avoid the “job security” mentality, don’t be clever. Write quality, standards-compliant software using good practices. Write tests, use version control—this stuff isn’t hard.

The alternative is The Process. It solves the problem of specialization by abstracting the work to the lowest common denominator. And it creates an Audit Trail made out of paper and Red Tape. [ed. sorry for mixing metaphors] But it’s prohibitive and doesn’t otherwise add value.

And really, don’t we all just want to “make it happen”?