A reader sent me email with this question: “We have a group of four people (3 developers and a tester). We work on 4 products, releasing one about once a month (each product is released once a quarter). The developers are devoted to one product when they’re developing, but have to fix problems immediately if […]
With a little common sense and some dependable metrics, you can banish the “bug bucket” and keep the dreaded rework monster under control by creating a reasonable prediction of your project’s end. A reader recently asked me, “When planning a project phase, how do you account for the bugs that you know will be created?
Originally published in Computerworld. During the past few years, we’ve been bombarded with news of outsourced call centers, help desks, testing, development, projects and entire IT infrastructures. It sure looks as if outsourcing is the way to go. Before you jump on the outsourcing bandwagon, ask yourself this question: What’s the value of the knowledge
I’m a fan of nightly builds with automated smoke tests, run overnight. In the morning when everyone returns to work, anyone who’s broken the build fixes it. In most cases, the developers see what they did and they fix it. The agile folks take this even further and say to build the system whenever
If this month’s guest column strikes a familiar chord with you, welcome to the club. We have all been there. Caught in the maelstrom of unrealistic requirements and damnable deadlines, we grab for whatever tactic looks like it might keep us afloat. More often than not, we start putting in longer hours and expect everyone