Errors in development are usually summed up as syntactic or semantic. Semantic (related to logic/understanding) is more subtle and more difficult to debug because it rarely throws out a glaring exception as would a syntactic error. There are significant issues with customers definition of problems, scope, and functionality. This leads to a different type of semantic error in my opinion. Imagine writing tests that eventually pass after long hours put in, only to show a client and realise that he/she meant something else. Well, so how important is a specification document? Also Agile seems to facilitate bootstrapping based on significantly less information than traditional methods. What is your opinion?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (4)
I usually find that the customer is best served by iterative, collaborative development instead of formalized specs. Consider this scenario: the customer wants you to automate a well-established business process. This should be the ideal scenario to write a formal spec and contract it out for development. But in my experience, the product created to spec will be disappointing most of the time.
Here's why. These kinds of processes are so ingrained in the customer that they don't think to communicate very important details. Because they know it very thoroughly, some details become so obvious to them that they stop noticing them. Since they don't notice them anymore, they don't think to point them out. The developers trying to follow the spec have to guess at these unspoken assumptions. To guarantee a successful outcome, the development team must become insiders so that they understand those implicit assumptions when they make the software. This takes iterative discovery. And sometimes it just takes putting your guessed assumptions in code and having the customer tell you how you missed the mark. Failing fast so you can find the right path sooner. If anything, a spec is going to slow down that process and cost the customer more money.
Places where I have observed (from the outside) specs working quite well are more low-level software like implementing communication protocols, or controlling hardware devices.
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.