The common thread for all human pursuits is our nature. This is best exemplified in our current economic crisis and the events leading up to the dénouement. Peter Schiff is a market participant and analyst who was scorned and laughed at for his prescient conclusions on the US financial markets and economy.
Read the full story »
You’ve probably been there, working to deliver on one of those unrealistic schedules. They all roughly follow the same trajectory. The marketing team sponsors the next project with a must hit inflexible date, an inflexible …
You’ve probably heard someone say it, or you may even say it yourself: “You design quality into a product; you don’t test quality into a product.” The last time when I heard those words uttered, I had to restrain myself from reacting. What did this person mean by that? The product was in trouble. It released late and with low quality. Customers were rolled back to the former version, and now the product marketing team fears that if things aren’t corrected soon they will lose market share.
What’s your worst fear as a software professional? My worst fear is changing jobs and joining a team that is in crisis. You’ve probably been part of a team, heard about a team or witnessed another team in your company deliver to one of those unrealistic schedules. Often times, the project starts off right, but entropy slowly builds as changes are introduced to the schedule with the velocity of an open fire hydrant. It doesn’t start that way: it builds with a crescendo. It’s not a case of replacing the old water with new water; it’s a case of filling a pool that’s filled 98% of capacity while watching the water spill over the sides and drain into the streets.
I often wonder why software teams always seem to be committing to unrealistic schedules. You know when the sales team signed a contract with a customer to deliver functionality on a date without ever asking the engineering team whether it were possible. Never mind the roadmaps identify an entirely different set of functionality than what was committed. And guess what? The product roadmaps can’t change either; the sales team has signed contracts on that functionality too.
It happened when I participated for the first time on a SEI/CMM process improvement initiative at my employer. That’s when I realized the power of software metrics. Instead of handing us a ready made process to follow, each of the different product organizations were tasked with the objective of developing their own processes with the goal of achieving Level 2 certification. Each group formed teams around the key process areas (KPA) to develop the practices to be followed. It was without a doubt the best process improvement experience of my career changing the way I manage and view software management permanently.
It has been my experience that shortchanging quality has always had a negative impact to the team and the organization that was never worth the trade-off.
The one essay that I was hoping would have a large readership was “An Objective Method for Navigating Your Projects.” Out of all the pieces published the methods described in this article can make a tremendous improvement in managing your software releases. There are many benefits to using metrics to managing software projects.
When I was a high school student I was an avid competitor in the sport of wrestling. It’s an extremely demanding and punishing sport: requiring extreme stamina, strength, skill, agility, and mental toughness. You have to have a strong mind to compete successfully in wrestling. When you’re in the 3rd period of a match, you’re exhausted, and your opponent continues aggressively to push the action, only the tough-minded continue to fight and pull out a win.
Did you ever read one of those articles where the writer had instant credibility? I recently stumbled upon one when I was looking to get my web site indexed on dmoz.org. The article is titled “Nine Steps to Delivering Defect-Free Software” by Terence M. Colligan. When I read the article I knew he isn’t just writing about somebody else’s experience because it mirrored my own experiences when I was writing software myself. In the article he identifies nine traits contributing to defect free code.
The Agile software development practices are in their infancy stage as evidenced by the number of variants that are being promoted in popular print and usage today: Scrum and XP being two popular variants. Clearly …
