Very good points Kasey, I'll surely take notes. I am not exactly tuned to the formal requirement specification process as it can be very time-consuming. Including customers in the development process has its benefits to a degree. Nonetheless, can't some leverage be made between adequate information to no little information at all. I think to move to and from in iterations making seemingly endless changes on the particularly ingrained understanding of features for the customer can as equally be time-consuming. Getting basic facts from interactions with customers can go a long way to reduce time, improve tests (in this case they are more concise). Another observation is, customers have needs, and they want it fast. There are a couple of categories of changes that may crop up in development, one is just as you stated, getting your assumptions in code, I'll call that "Corrective changes", and then there is another, changes based on a change in customer/business needs "Dynamic changes". These could be as a result of a change in business logic which could be based on external factors (market, competitors) or internal changes (customers realigning business goals/process). I find the first "Corrective Changes" easier to curb/reduce. In an iteration, let's say 8 sprints for 2 and a half months, significant delays (development, testing, corrections, repeat) could occur which will still cost customers and the development firm. Perhaps my post came off as defending rigid specs doc, but that's not it at all
Just to clarify, I was not recommending getting your corrections solely through writing code and having the customer correct it. I love the joke "weeks of work can save hours of planning". Customer interviews are the preferred way to gain the proper understanding of their problem domain. Some written artifacts like notes and documents naturally fall out of that. I wouldn't call these specs so much as memory aids. But any well-defined process is probably going to require multiple interviews to tease out all the important details. We meet with the customer to get some details, go away and think on them, try to come up with a design. Maybe it is even enough to start some code. But then we face roadblocks where the puzzle pieces stop fitting, and we need to talk to the customer again. That's why I said that it takes iterative discovery. And sometimes your interview with customers stop making progress. Maybe then it is time to write something and have them correct it, but this tends to be more expensive than developing a design from interviews. And then coding once we have enough understanding to be confident in that design.
So this design might actually sound a lot like requirement documents / specs. The big problem with specs is that they are artifacts. And changes to them must go through a bit of overhead (change orders and approvals and literally changing the document and so forth). But a design lives primarily in the minds of the developers. Maybe with some written artifacts to help organize or remember some details. The design is living and evolving as new information comes in. Once it is written down, whether in specs or in code, it becomes harder to fix. And when you have both specs and code (the case where you used specs, are writing code, and need to dynamically responding to the customer's business changes), then you have 2 places that need updating for every change. Write amplification. Increased cost.
As you can probably tell, I am biased against requirement documents. However they do have places where they work. And other places where they are required anyway. :)
hmm...again very good points. Customer interviews, multiple interviews to tease out all important details for a well-defined process, iterative discovery, a design. There is a lot to pick up from the post but developing a design from interviews...well perhaps this is where soft skills make another huge difference. Communication between both parties will have to be clear and concise. It's not easy to measure exactly when you have enough understanding though. Well, it's probably the clients I have faced. Writing points down after every interview did prove to help keep the customer aware if there is a paradigm shift or change and draw their attention (in my case they thought that's what they said during the last interview). The team could discuss and actually have a design in mind, explain to customers and they affirm, but somehow it's not exactly what they wanted, still a tiny or small change. Anyway, it does reduce overhead compared to a spec doc, as the overhead of making a small change is better.
Thanks. All the best.
I hoped this would have reached more people so as to have a wide array of varying opinions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very good points Kasey, I'll surely take notes. I am not exactly tuned to the formal requirement specification process as it can be very time-consuming. Including customers in the development process has its benefits to a degree. Nonetheless, can't some leverage be made between adequate information to no little information at all. I think to move to and from in iterations making seemingly endless changes on the particularly ingrained understanding of features for the customer can as equally be time-consuming. Getting basic facts from interactions with customers can go a long way to reduce time, improve tests (in this case they are more concise). Another observation is, customers have needs, and they want it fast. There are a couple of categories of changes that may crop up in development, one is just as you stated, getting your assumptions in code, I'll call that "Corrective changes", and then there is another, changes based on a change in customer/business needs "Dynamic changes". These could be as a result of a change in business logic which could be based on external factors (market, competitors) or internal changes (customers realigning business goals/process). I find the first "Corrective Changes" easier to curb/reduce. In an iteration, let's say 8 sprints for 2 and a half months, significant delays (development, testing, corrections, repeat) could occur which will still cost customers and the development firm. Perhaps my post came off as defending rigid specs doc, but that's not it at all
Just to clarify, I was not recommending getting your corrections solely through writing code and having the customer correct it. I love the joke "weeks of work can save hours of planning". Customer interviews are the preferred way to gain the proper understanding of their problem domain. Some written artifacts like notes and documents naturally fall out of that. I wouldn't call these specs so much as memory aids. But any well-defined process is probably going to require multiple interviews to tease out all the important details. We meet with the customer to get some details, go away and think on them, try to come up with a design. Maybe it is even enough to start some code. But then we face roadblocks where the puzzle pieces stop fitting, and we need to talk to the customer again. That's why I said that it takes iterative discovery. And sometimes your interview with customers stop making progress. Maybe then it is time to write something and have them correct it, but this tends to be more expensive than developing a design from interviews. And then coding once we have enough understanding to be confident in that design.
So this design might actually sound a lot like requirement documents / specs. The big problem with specs is that they are artifacts. And changes to them must go through a bit of overhead (change orders and approvals and literally changing the document and so forth). But a design lives primarily in the minds of the developers. Maybe with some written artifacts to help organize or remember some details. The design is living and evolving as new information comes in. Once it is written down, whether in specs or in code, it becomes harder to fix. And when you have both specs and code (the case where you used specs, are writing code, and need to dynamically responding to the customer's business changes), then you have 2 places that need updating for every change. Write amplification. Increased cost.
As you can probably tell, I am biased against requirement documents. However they do have places where they work. And other places where they are required anyway. :)
Best wishes!
hmm...again very good points. Customer interviews, multiple interviews to tease out all important details for a well-defined process, iterative discovery, a design. There is a lot to pick up from the post but developing a design from interviews...well perhaps this is where soft skills make another huge difference. Communication between both parties will have to be clear and concise. It's not easy to measure exactly when you have enough understanding though. Well, it's probably the clients I have faced. Writing points down after every interview did prove to help keep the customer aware if there is a paradigm shift or change and draw their attention (in my case they thought that's what they said during the last interview). The team could discuss and actually have a design in mind, explain to customers and they affirm, but somehow it's not exactly what they wanted, still a tiny or small change. Anyway, it does reduce overhead compared to a spec doc, as the overhead of making a small change is better.
Thanks. All the best.
I hoped this would have reached more people so as to have a wide array of varying opinions.