X
Business

When software and politics mix, quality suffers

How 'technopolitics' rushes good software and services
Written by Joe McKendrick, Contributing Writer

In my last post, I talked about the challenges in quality assurance across complex SOA environments -- and how quality is important in SOA, because SOA is built on trust. Without trust in the viability and reliability of services, SOA collapses.

How 'technopolitics' rushes good software and services

However, quality assurance works great in nice, sterile environments. But most organizations are messy affairs run by fallible human beings. In this blogsite, we often talk about the struggle to deliver good solutions and services against organizational inertia and hidebound thinking. Organizations that could benefit from SOA methodologies, for example, are not likely to be friendly to SOA.

In a new post, James McGovern explains how the "technopolitics" (great term) of organizations result in rushed projects that overworked IT departments are forced to churn out:

"A project is initiated, but the staff delays design and development activities for several months while various technopolitical issues are resolved at a management level. Enterprise Architects then scramble to create PowerPoint while the problem at hand that actually caused the politics is in the rapid creation of working software."

What happens with many projects get mired in politics, shifting or conflicting organizational priorities, and general management inertia.

The story becomes wait for 12 weeks while management sits on it, which then asks to get it done yesterday. Ironically, James says, the resulting time crunch "makes the job easier for some software developers as management will accept almost any software (or documentation) product with few questions if it is behind schedule."

But this is no way to achieve quality software.

James offers a couple of ways to beat this "Fire Drill" pattern. Enterprise architects need to take a more proactive role in shielding development operations from this chaos. As he puts it: "Enterprise architects should be a condom of sorts to protect developers from the disease known as IT executive politics where they can focus on long term continual progress towards software delivery."

James also advocates Agile software development, which is a far more interactive approach than the traditional waterfall method.

Editorial standards