Library columns
Pro Developer - Throwing Money Out the Window
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...
Incremental successes
Building credibility is a similar approach. You've probably been spending all your time trying to do the job you were hired to do, right? Silly you. That needs to be dealt with, of course, but your priorities are all wrong if you truly want to change the world. Credibility is an incremental affair. You don't gain it by having one huge success. Furthermore, that's too risky. One huge success could easily turn into one huge failure. Instead of rolling the dice on all or nothing at all, we instead simply leave a trail of small successes, so frequent and consistent that there can be little doubt that betting on your opinions is a sure thing.
Even if the project you're working on now is scheduled for imminent failure, you can still get mileage out of it. The first step is shifting your thinking to a very fine granularity. Almost any task can be broken down into a sequence of small, consecutive actions. Let's say that you wanted to bench press 300 pounds, and you had a body that was capable of doing so. Here's two different descriptions of accomplishing that task.
Approach one:
Took a deep breath and lifted the weights.
Approach two:
- Set the alarm clock
- Went to bed at reasonable hour
- Got up on time
- Took a shower
- Dressed in appropriate clothes
- Walked to weight room
- Set machine for 300 pound bench press
- Reclined on the bench
- Grabbed the weight bar
- Took a deep breath
- Focused
- Invoked upper body muscles
- Raised weights to full arm extension
- Took deep breath
- Lowered weights to resting position
- Rose from the bench to conclude exercise
Yes, I know, it seems kind of silly to go to all that detail when all you did was lay down and just punch up the weights. However, the first approach shows only that you succeeded in one effort. In the second approach, you have 16 consecutive successes on operations that each could have failed or encountered problems. Now who would you rather put your trust in, the guy who did one thing right, or the guy who did 16 things in a row right? This is how you must approach every job you do. From the smallest coding task to the largest documentation effort, there are a host of things that you have to do right to succeed. Take the time to write them down so that you can always refer to your notes instead of having to recount your successes from memory.
Design Specification Extreme Pro
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.