Comments on: The 15 Minute Rule Of Software Development http://www.brandonsavage.net/the-15-minute-rule-of-software-development/ The personal blog of Brandon Savage. Contains entries of a personal and professional nature focusing on PHP, Apple, LAMP, MySQL and Washington, DC. Fri, 03 Feb 2012 19:36:33 -0500 hourly 1 http://wordpress.org/?v=3.3.1 By: Chris Roane http://www.brandonsavage.net/the-15-minute-rule-of-software-development/#comment-3063 Chris Roane Wed, 24 Mar 2010 14:57:54 +0000 http://www.brandonsavage.net/?p=1196#comment-3063 For me, the importance of a spec document is that it covers the specifics, which prevents the specifics from becoming monsters. I don't mean tiny specifics, but specifics that vary the amount of time that it will take to develop that part. For example, a photo gallery is a horrible description, because it does not cover exactly what the client is thinking for the gallery. I like this article! It goes a long with my experiences. I may blog about this on my site. For me, the importance of a spec document is that it covers the specifics, which prevents the specifics from becoming monsters. I don’t mean tiny specifics, but specifics that vary the amount of time that it will take to develop that part. For example, a photo gallery is a horrible description, because it does not cover exactly what the client is thinking for the gallery.

I like this article! It goes a long with my experiences. I may blog about this on my site.

]]> By: Sebs http://www.brandonsavage.net/the-15-minute-rule-of-software-development/#comment-3044 Sebs Thu, 18 Mar 2010 16:47:26 +0000 http://www.brandonsavage.net/?p=1196#comment-3044 With scrum you have this process in several parts: weekly meetings to get a leverl of uderstanding that everyone can say "this is big" or "this is small" which leads to a first level of understanding a meeting where we take the story and get all acceptance criteria and a design meeting, which leads to the final level of understanding. And for big ones we exceed your 15 minutes, but maybe becasue we are mixing up things With scrum you have this process in several parts:

weekly meetings to get a leverl of uderstanding that everyone can say “this is big” or “this is small” which leads to a first level of understanding
a meeting where we take the story and get all acceptance criteria
and a design meeting, which leads to the final level of understanding.
And for big ones we exceed your 15 minutes, but maybe becasue we are mixing up things

]]> By: Eli White http://www.brandonsavage.net/the-15-minute-rule-of-software-development/#comment-3040 Eli White Thu, 18 Mar 2010 12:39:35 +0000 http://www.brandonsavage.net/?p=1196#comment-3040 Nice post Brandon; however, it seems to be very targetted to a specific development environment. I'm used to working in situations where the developer is involved in creating the spec in the first place. In fact, I'm a HUGE fan of this practice as it really leaves the 'spec' phase with a product that everyone understands and has agreed upon. In this case, there is no idea of tossing the spec back, because the developer helped create it and knows exactly what it is. More importantly though, is the idea of development on small agile (small 'a') teams, where specs are loose and changing at all times anyway. Where you just throw code out there and iterate as needed. In which case, there isn't really a formal spec perse anyway. Nice post Brandon; however, it seems to be very targetted to a specific development environment.

I’m used to working in situations where the developer is involved in creating the spec in the first place. In fact, I’m a HUGE fan of this practice as it really leaves the ‘spec’ phase with a product that everyone understands and has agreed upon. In this case, there is no idea of tossing the spec back, because the developer helped create it and knows exactly what it is.

More importantly though, is the idea of development on small agile (small ‘a’) teams, where specs are loose and changing at all times anyway. Where you just throw code out there and iterate as needed. In which case, there isn’t really a formal spec perse anyway.

]]> By: Stuart Herbert http://www.brandonsavage.net/the-15-minute-rule-of-software-development/#comment-3039 Stuart Herbert Thu, 18 Mar 2010 11:18:31 +0000 http://www.brandonsavage.net/?p=1196#comment-3039 Interesting idea, and I'm sure it'll really help folks when they're reviewing a spec to make sure they haven't created some behemoth from hell :) But I'd always recommend an alternative test. If you can't create appropriate acceptance tests to prove that the developer / supplier has met the spec, then the spec isn't finished. Best regards, Stu Interesting idea, and I’m sure it’ll really help folks when they’re reviewing a spec to make sure they haven’t created some behemoth from hell :)

But I’d always recommend an alternative test. If you can’t create appropriate acceptance tests to prove that the developer / supplier has met the spec, then the spec isn’t finished.

Best regards,
Stu

]]>