Library columns
Pro Developer - Throwing Money Out the Window
Introduction
It's common knowledge among programmers that most of the ills of the software industry, and most particularly the companies where we work, could be solved by simply letting the technical people make the technical decisions. In fact, that sounds so obvious that you might be tempted to shake your head and wonder what planet I come from. Obviously, since this is so incredibly logical and sensible, it's a given that most companies leave management decisions to managers, and technical decisions to techies, right?
Hey, you. Yeah, you. The one in the back staring at your compiler errors. You're laughing in all the wrong places. At least let me finish, and then we can all laugh together about how silly an assumption this is. Now, as I was about to say, anyone who's ever been paid for writing code already knows that regardless of how sensible it might be to let the people with the expertise make the decisions, that's just not the way it happens in the real world. In fact, in the overall scheme of things, when it comes to decision making power, programmers are at the bottom of the food chain, whether the issue is technical or not.
In short, no matter how silly it may be, most critical technical decisions in the software development business are made by middle or upper management, a class of creature who only rarely possesses any in depth technical expertise. This, in and of itself, wouldn't be so bad. It is, after all, management's area of expertise to keep the company on track and make the sweeping decisions requiring someone with a wide angle view of the business. The problem with this scenario is that an extremely high percentage of the time, these decisions are made without consulting the technical staff about the feasibility and consequences of the decision. Worse still, management often makes decisions for their own reasons over the loud protests of their technical staff, ignoring the recommendations made by those who have the greatest skills in that arena. It's a wonder that any software ever ships at all.
Christopher Duncan is President of Show Programming of Atlanta, Inc. and author of both the monthly syndicated column Pro Developer and the recent book for Apress, The Career Programmer: Guerilla T...
Project management is a sophisticated science. A new emerging discipline in software engineer called Project Management Principle (PMP body of Knowledge) takes systematical approach to solving some of the common problems associated with software failure.
In reading the article I reflected on some of the PMP principles such as scope, stakeholder buyoff, activity planning, and risk management. The flow of PMP is to complex to demostrate in this response but definately most software fails because of lack of planning and design.
I used the PMP model while working as an outsourcing SPA. I found it took 95 percent design and planning and 5 percent code to complete the project. Software development is that political. The technical risks rarely inhibited the release of a program. Object orient technologies and database technologies are extremely flexible.
The real challenge is to bring the business model into focus: business requirements, assumptions, constraints, required resource, and scope (budget, time, resource). The PMP way advocates increased CMM levels to achieve its objectives.
Let say extreme programming principles can fit inside a PMP framework. The PMP framework is designed to produce documentation that brings the business teams into focus and scope. Deliver a product with exactly the desired features wanted, no more no less.
In short, I sympathize with the authors fustrations, but a more beautiful design exists to reduce lose and fustration. Management incompetence is an enemy, but systematic approaches can reduce risk of failure. Let the failure occur on paper first. Using PMP, I had a few project halted because it didn't fit the business needs. The cost was minimal because it was a documentation cost. I recommend, One analysis handling manage numerous development projects, flexibility and cooperation among the team members, and customer center methodologies. Resource matrixes provide availability schedules and extreme programming principles ensure reliability and reuse. Consider this as an approach to reduce fustration.
This thread is for discussions of Pro Developer - Throwing Money Out the Window.