Hacker News new | past | comments | ask | show | jobs | submit login

I agree that what you describe is a huge problem. I'm not so sure though if that problem can be alleviated by additional tooling. More often than not the cause of this is defective processes and assumptions rather than deficient tools.

DDD, ubiquitous language and bounded contexts in particular, can be enormously helpful with defining better requirements.

I'm not so sure about BDD though in this context. While the notion of the customer / product owner writing specifications in this format in a way developers can use these specifications to test their code sounds great at face value I have yet to see a project where this is done consistently and continuously.

Moreover, some types of requirements can be better explained by using diagrams or UI mockups, which doesn't really fit the BDD paradigm.




Agreed, it's not about the tools, but the process. I've worked with different agile coaches - most of them were crap, but one of them really struck a chord in how he would find flaws on the organisation that would reflect on the software side. He was really good at devising strategies to overcome this.

To address the specific question, I think most of the time there's a problem because there is no one that takes care of making sure everyone has the same vision and understanding of what needs to be done. And because sometimes words fail us, I think mockups are a great way of uncovering and sharing requirements.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: