This week's book giveaway is in the Artificial Intelligence and Machine Learning forum.
We're giving away four copies of Machine Learning with R: Expert techniques for predictive modeling and have Brett Lantz on-line!
See this thread for details.
Win a copy of Machine Learning with R: Expert techniques for predictive modeling this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

How does the book reduce costs?

Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You may feel this question to be a funny one but just try to reply to the users.
How truely will your book help a development team to reduce anxiety and cost?

[Edit to provide meaningful title - Dave]
[ September 26, 2006: Message edited by: David O'Meara ]
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Biju,

there are a lot of good practices in processes such as RUP, OpenUP, Scrum, Agile Modeling, XP, and if you follow those processes, you will probably find that you are more effective in your development, hence saving money.

But transitioning to a process is often seen as a huge and expensive undertaking. How long time will it take for my team to learn how to follow RUP? How costly will it be?

What we tried to accomplish with the book is to provide you with 20 practices, and for each practice, we describe how you can incrementally adopt that practice. Maybe you are at the basic level, and you would like to go to the intermediate level. You now how a very specific target for process improvement allowing you to improve in an area where you feel you need to improve, without having to take on a lot of cost, since the associated organiztional change is small.

In the book, we describe a framework (overall approach) for how you can leverage these practices to take on this type of incremental improvement, and how to identify the practices your organization should imorove first (what is right for your organization may not be right for the next organization). So, we think that if you use the book, you will more easily find low-hanging fruits for process improvements, allowing you to incrementally improve your process, and hence incremetally hpefully improve the software economics of your development organization.

Now, the book is a compliement to using normal mentors and trainers, and for using processes such as RUP and OpenUP. The goal has not been to replace these things, we do not describe all the practices in the depth we describe them in e.g. RUP, we do not provide templates, we do not replace the need for training, we do not provide tool-specific guidance....

Hopefully this answers your question.


Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't speak for the book, but I think that Agile Software Development reduces costs in a number of ways:

I agree with Per that some of the practices directly reduce costs. Test Driven Development, for example, radically reduces the number of bugs you introduce in the software, and thereby significantly reduces the amount of time you need to spend debugging.

Additionally, being quite humane approaches to software development, Agile approaches often lead to better motivated teams. I hope it's no secret that better motivated teams are more effective.

Last but not least, Agile practices do away with a lot of waste in software development. And I'm not only talking about tons of documents that are created but never used.

It is known that typically more than half the features of a software system are never or seldom used. It's not hard to imagine that for most of those it would have saved costs to not implement them.

Why are they implemented? Mostly, I think, because people don't know what they need, let alone what they will need in, say, a year from now. But when we tell them that they need to come up with their requirements now, and that it will be costly to change them later, we force them to come up with all those features they actually aren't sure they will really need, just in case.

Agile Software Development approaches change that - we only develop the set of most important features and then show them to the users to try them. Then they can learn from that experience and decide what else they need. We tell them that, as long as a feature isn't yet implemented, changing it or exchanging it for something totally different costs near to nothing. That way we dramatically improve the probability that the final system will really contain all important features, and we don't waste much time on features that aren't of use to anyone.

One more thing that doesn't reduce cost directly, but increases income, is that Agile teams work on having a releasable system from early on. If a system with the most important features implemented can be installed and used in a couple of weeks instead of months or years, we get earlier and more return for our investment.
They weren't very bright, but they were very, very big. Ad contrast:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!