The 70% Solution: Practical Testing and Version Control

Written by Steve Pickard

"What do you mean you need to push backrepparttar launch date?" Saysrepparttar 137551 CEO. Saysrepparttar 137552 CFO. Saysrepparttar 137553 user community. CTOs, CIOs, and all officers who oversee major development projects have had to deliverrepparttar 137554 dreaded message. But a deadline forrepparttar 137555 sake of a deadline is a dangerous pitfall that can consume an entire project and stymie it torepparttar 137556 point that it never launches. Overrepparttar 137557 years I've come up with six simple rules that help deadlines become more meaningful, while keepingrepparttar 137558 developers,repparttar 137559 user community,repparttar 137560 CFO andrepparttar 137561 CEO all satisfied. 1.Always have minor version control throughout development. Group functional requirements into minor versions so that core functionality is prioritized and so thatrepparttar 137562 entire development team is generally active onrepparttar 137563 same minor version. 2.Always target minor version releases every 2 to 4 weeks. 3.Always begin testing immediately once each minor version is complete. 4.Always prioritize bug-fixing torepparttar 137564 highest level uponrepparttar 137565 completion of any testing. 5.Never allow a problematic functional enhancement to be a showstopper. Negotiate withrepparttar 137566 user community andrepparttar 137567 CFO or CEO for a delay in, or removal of,repparttar 137568 delivery of that functionality. 6.Always launchrepparttar 137569 product on time - as long asrepparttar 137570 most recent fully completed minor version is functionally equivalent or better thanrepparttar 137571 current production system. Launch it, no matter how far you are from 100% complete.

So I want you to launch an incomplete application? Let's just call it "functionally challenged". This is what I callrepparttar 137572 70% solution. The deadline doesn't move andrepparttar 137573 developers deliver a fully tested, bug-fixed version on time and within budget. This gives managementrepparttar 137574 opportunity to evaluate further investments into application functionality while reapingrepparttar 137575 benefits of any developments to date.

Beyond Repair: The fixed-price model

Written by Steve Pickard

Don't get me wrong. I certainly don't thinkrepparttar majority of vendors who use a fixed-price model are trying to rip you off. In fact, when I started my business that'srepparttar 137550 way we worked—which is why we have such great insight intorepparttar 137551 flaws inrepparttar 137552 system. But there needs to be a transparency torepparttar 137553 work. You need to know exactly what you're getting, how long it takes, and how much it costs. You need to know that you're only paying for time actually spent on your account. And you need to know that no risk will ever be taken with your system just to maintain your contractor's profitability. The inherent structure of fixed pricing makes this kind of transparency an impossibility. Here's why:

Fixed pricing is designed to function withrepparttar 137554 absolute minimum amount of human attention. The morerepparttar 137555 company does not work forrepparttar 137556 client,repparttar 137557 higherrepparttar 137558 profit. This creates an adversarial system whererepparttar 137559 caretakers fight to do as little work as possible no matter how much they are being paid.

Fixed pricing encourages wastage. Since a fixed price contractor has an hourly rate in mind - say $120/hr - then when they quote $12,000 per month, that really means that they intend to spend no more than 100 hours per month on your account. But if nearrepparttar 137560 end ofrepparttar 137561 month they have only done 20 hours, for example, then what happens torepparttar 137562 other 80 hours? Nothing. You would have received inferior services for an astronomical hourly rate and have no recourse to approachrepparttar 137563 contractor and ask that they put in a little TLC.

Fixed pricing encourages increased risk. This one has a little math behind it: If a problem can be corrected in 1 hour but has a 10% chance of reoccurring in 2 months, or can be corrected in 5 hours and will never happen again,repparttar 137564 fixed price contractor will always pickrepparttar 137565 1 hour solution. Why? Imagine that they have 10 different clients withrepparttar 137566 same problem. They can spend 50 hours fixing itrepparttar 137567 right way for everyone, or spend 10 hours fixing them allrepparttar 137568 wrong way knowing that only 1 inrepparttar 137569 10 (10%) will have a problem in 2 months (incurring another 1 hour then). Therefore,repparttar 137570 total time saved by doing itrepparttar 137571 wrong way is 39 hours. A huge savings torepparttar 137572 contractor.

Now imagine if that problem has downtime or data loss associated to it. This will never factor into their profitability equation.

Fixed pricing can be deceptive as far as measure of quality. Take database administration, for example, since that's what I know best. The measure ofrepparttar 137573 DBA job in a fixed price model is to ensure thatrepparttar 137574 database is up. Performance improvement or dealing with performance decline is not even inrepparttar 137575 contract. Also missing is any diagnosis of complex performance or network issues which may involve more than one piece ofrepparttar 137576 architecture puzzle.

Cont'd on page 2 ==> © 2005
Terms of Use