Comments on: Painless Spec and Schedule Development http://www.brandonsavage.net/painless-spec-and-schedule-development/ The personal blog of Brandon Savage. Contains entries of a personal and professional nature focusing on PHP, Apple, LAMP, MySQL and Washington, DC. Thu, 29 Jul 2010 11:09:38 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Matthew Purdon http://www.brandonsavage.net/painless-spec-and-schedule-development/#comment-2765 Matthew Purdon Sun, 03 Jan 2010 02:47:22 +0000 http://www.brandonsavage.net/?p=1094#comment-2765 I think a lot of the problem with the waterfall method of software development is the fact that you do rely on having extremely detailed specs in place before you can write anything. Although I agree that you definitely need good specs,I have found many times that the client really doesn't know what they want. If you go ahead and implement something and let the client play with it as soon as possible, you waste less time grinding out specs that are just going to be tossed out later and have an easier time attaining the YAGNI principal. Long story short, get a good idea of the feature the client wants - especially what it is supposed to help the user do - and then bang it out. Clients are happy to get results back in small increments, it makes them feel as though their money is actually going somewhere. I think a lot of the problem with the waterfall method of software development is the fact that you do rely on having extremely detailed specs in place before you can write anything. Although I agree that you definitely need good specs,I have found many times that the client really doesn’t know what they want. If you go ahead and implement something and let the client play with it as soon as possible, you waste less time grinding out specs that are just going to be tossed out later and have an easier time attaining the YAGNI principal. Long story short, get a good idea of the feature the client wants – especially what it is supposed to help the user do – and then bang it out. Clients are happy to get results back in small increments, it makes them feel as though their money is actually going somewhere.

]]> By: Benoit http://www.brandonsavage.net/painless-spec-and-schedule-development/#comment-2699 Benoit Thu, 17 Dec 2009 08:36:33 +0000 http://www.brandonsavage.net/?p=1094#comment-2699 Hi, that's the reason why we souhld separate functionnal spec from technical specs. I know it's no more sustainable having a too heavy software design upfront the production of code, but in fact it sometines still being required. Functionnals spec determines the what software does, like in use cases, while technical specs states how the functionnality will be done. We've sometimes to wrote only to avoid the client discussing technologies and design choice we've made from the beginning of developement. I agree on fact that developers should participate in writing specs. I 'm used to do it (and liked it), but our management has made the choice to hire "professional" project manager in charge of writing them. That's a disaster on term of planning, and profit, because she doesn't have any idea how complex it is to make a functionnality in the real world. Moreover she writes things that are technically not possible, like putting flash app in email newsletters... In the end, our clients ended up frustated because the specs are not filled, and we have very limited profits because of the large difference between time planned, and charged to cusstomer, and the real time we've to spend on the product. Yeah, it's a project manager job handle communication and perhaps negociation with client. But this is not incompatible with developers actually writing specs, or at least review and amendate them. In my opinion, the more realistic and precise specs are, the more probability for the project to be a success for us and client. Hi,

that’s the reason why we souhld separate functionnal spec from technical specs.
I know it’s no more sustainable having a too heavy software design upfront the production of code, but in fact it sometines still being required. Functionnals spec determines the what software does, like in use cases, while technical specs states how the functionnality will be done.
We’ve sometimes to wrote only to avoid the client discussing technologies and design choice we’ve made from the beginning of developement.

I agree on fact that developers should participate in writing specs. I ‘m used to do it (and liked it), but our management has made the choice to hire “professional” project manager in charge of writing them. That’s a disaster on term of planning, and profit, because she doesn’t have any idea how complex it is to make a functionnality in the real world. Moreover she writes things that are technically not possible, like putting flash app in email newsletters…

In the end, our clients ended up frustated because the specs are not filled, and we have very limited profits because of the large difference between time planned, and charged to cusstomer, and the real time we’ve to spend on the product.

Yeah, it’s a project manager job handle communication and perhaps negociation with client. But this is not incompatible with developers actually writing specs, or at least review and amendate them.

In my opinion, the more realistic and precise specs are, the more probability for the project to be a success for us and client.

]]> By: Brandon Savage http://www.brandonsavage.net/painless-spec-and-schedule-development/#comment-2697 Brandon Savage Wed, 16 Dec 2009 15:27:16 +0000 http://www.brandonsavage.net/?p=1094#comment-2697 Chris, if I didn't explain very well the collaboration I apologize. That was the point I was trying to make with the architect example; the two have to work together. The spec should also be specific, but as you've probably learned, specific doesn't necessarily mean written in sentence form. I like the idea of a technical project manager who knows his developers and acts as an intermediary between the two. Letting the developers do the development is the best option. It's unfortunately also been my experience far too often that project managers are not technical, which creates significant problems for developers who actually do the development. Chris, if I didn’t explain very well the collaboration I apologize. That was the point I was trying to make with the architect example; the two have to work together. The spec should also be specific, but as you’ve probably learned, specific doesn’t necessarily mean written in sentence form.

I like the idea of a technical project manager who knows his developers and acts as an intermediary between the two. Letting the developers do the development is the best option. It’s unfortunately also been my experience far too often that project managers are not technical, which creates significant problems for developers who actually do the development.

]]> By: chris http://www.brandonsavage.net/painless-spec-and-schedule-development/#comment-2696 chris Wed, 16 Dec 2009 12:47:05 +0000 http://www.brandonsavage.net/?p=1094#comment-2696 I have to disagree with you on one thing - you mention that the spec itself should be an overview of the functionality, the "why" it should work but not the "how". Putting the spec writing in the hands of the developers is a sure way to miss what the client is trying to tell you they need. Should it be all in the client's hands? Of course not, but it should be a collaboration between them, not a one-sided look at how one group thinks it should work. In my experience, the more vauge the spec, the less happy the customers end up being (and the more the developers have to come back and ask questions). The better specs I've seen are combinations of both narrative and process flows, giving the developers a good overall view (the flows) and some of the more picky details about the parts of it. I see it as the role of the project manager and/or a business analyst type to handle any communication between the customer and the development team. Last time I checked, most developers don't have the business knowledge to be sure the spec is still well defined - especially if it's an outside company they're doing the work for. I have to disagree with you on one thing – you mention that the spec itself should be an overview of the functionality, the “why” it should work but not the “how”. Putting the spec writing in the hands of the developers is a sure way to miss what the client is trying to tell you they need. Should it be all in the client’s hands? Of course not, but it should be a collaboration between them, not a one-sided look at how one group thinks it should work.

In my experience, the more vauge the spec, the less happy the customers end up being (and the more the developers have to come back and ask questions). The better specs I’ve seen are combinations of both narrative and process flows, giving the developers a good overall view (the flows) and some of the more picky details about the parts of it. I see it as the role of the project manager and/or a business analyst type to handle any communication between the customer and the development team. Last time I checked, most developers don’t have the business knowledge to be sure the spec is still well defined – especially if it’s an outside company they’re doing the work for.

]]>