Are there any statistics available to
how much longer it will take to
develop applications when creating
unit test during the development
compared to just coding?
There is some very interesting research about this. Read the following whitepaper:
Realizing quality improvement through test driven
development: results and experiences of four industrial
teams
The whitepaper and others research from one of its authors, Nachi Nagappan, are discussed here:
http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx
The study and its results were published in a paper entitled Realizing quality improvement through test driven development: results and experiences of four industrial teams, by Nagappan and research colleagues E. Michael Maximilien of the IBM Almaden Research Center; Thirumalesh Bhat, principal software-development lead at Microsoft; and Laurie Williams of North Carolina State University. What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.
“Over a development cycle of 12
months, 35 percent is another four
months, which is huge,” Nagappan says.
“However, the tradeoff is that you
reduce post-release maintenance costs
significantly, since code quality is
so much better. Again, these are
decisions that managers have to
make—where should they take the hit?
But now, they actually have quantified
data for making those decisions.”
Additionally, Jason Gorman has proposed such an experiment for the Software Craftsmanship conference this year. He's been trying an experiment creating the same application using a TDD and a non-TDD approach and he's recently blogged about his results:
Over 3 iterations, average time taken to complete the kata without TDD was 28m 40s. Average time with TDD was 25m 27s. Without TDD, on average I made 5.7 passes (delivering into acceptance testing). With TDD, on average I made 1.3 passes (in two attempts, they passed first time, in one it took 2 passes.)
Now, this was a baby experiment, of course. And not exactly laboratory conditions. But I note a couple of interesting things, all the same.
It will be interesting to see the full results of this experiment when more people perform it.
Are there any statistics available
that shows how many hours maintenance
decreases when having (good) unit
tests?
From the whitepaper above:
The results of the case studies
indicate that the pre-release defect density of the four products decreased between 40% and
90% relative to similar projects that did not use the TDD practice.
Best Answer
A software maintenance retainer contract is an agreement between two parties to maintain a piece of software after its initial release.
As it's a retainer (and not a subscription), the client agrees to pay a certain amount up front for the purposes of handling any expenses that might occur in maintaining the software.
This benefits the client by having their bases covered—should bug fixes or security updates need to happen after release—without having to negotiate pricing or secure approval every time a change needs to be made to the software.
This benefits the developer in that they get the money up front and can specify the exact conditions under which a change counts as part of the agreement ahead of time.
A similar concept (but not exactly the same) is the Service Level Agreement (SLA) that Zsolt mentioned: SLAs are used for services that require a certain amount of up-time or availability (hence the name). As part of the negotiated price for the service, the developer/host/etc. guarantees a certain level of support, reliability, and availability.
When negotiating the retainer fee (or what type of SLA you can offer), you need to decide a few things:
From experience, it's also important to keep in mind that maintenance and support is not second-rate work: do not lower your rates just because it happens after the initial project is done. The main reason why maintenance would cost less to the client is that it takes up less time.