Monday, February 16, 2009
Great series of blog entries on DDD
Casey Charlton has a great series of blog entries on DDD (Domain Driven Design). The articles just keep on coming, and now he has made an ebook with all the articles. Great work, highly recommended.
Tuesday, February 03, 2009
Quality and the speed of development
Uncle Bob has written a post on the subject of quality versus speed.
I really like his point that speed in and of itself is not a success criteria. If the software you develop isn't quality software, it may (or may not) be faster to get the first release of the product shipped.
However, the speed of development for the remainder of the product's life may be heavily reduced due to the lack of quality in the design.
A good example of the opinion that speed matters more is when someone states that "we don't have time to write unit tests." Writing tests may take longer in the short run, but if done right, the quality of the software increases, which may even help get the release of out the door faster. At least, the quality of the code will improve.
In the upcoming book by Roy Osherove, The Art of Unit Testing
, he deals with an example, where two teams in the same organisation implemented two similar features. One team wrote unit tests for their code, the other didn't. In summary, the unit testing team spent twice as long implementing the code. However, they were significantly faster integrating the code, and spent less time in manual test and bug fixing cycles. Actually, the team that wrote unit tests completed the feature in less time than the team that didn't. In addition, the number of bugs found in production was much lower.
The example in the book may not have been a very scientific study, but it shows that actions to increase the quality of the software may actually have the positive side effect of increasing the speed of development. Just remember that speed of development is not a quality in itself.
I really like his point that speed in and of itself is not a success criteria. If the software you develop isn't quality software, it may (or may not) be faster to get the first release of the product shipped.
However, the speed of development for the remainder of the product's life may be heavily reduced due to the lack of quality in the design.
A good example of the opinion that speed matters more is when someone states that "we don't have time to write unit tests." Writing tests may take longer in the short run, but if done right, the quality of the software increases, which may even help get the release of out the door faster. At least, the quality of the code will improve.
In the upcoming book by Roy Osherove, The Art of Unit Testing
, he deals with an example, where two teams in the same organisation implemented two similar features. One team wrote unit tests for their code, the other didn't. In summary, the unit testing team spent twice as long implementing the code. However, they were significantly faster integrating the code, and spent less time in manual test and bug fixing cycles. Actually, the team that wrote unit tests completed the feature in less time than the team that didn't. In addition, the number of bugs found in production was much lower.The example in the book may not have been a very scientific study, but it shows that actions to increase the quality of the software may actually have the positive side effect of increasing the speed of development. Just remember that speed of development is not a quality in itself.
Subscribe to:
Posts (Atom)