Conversational development


Apparently, this is the cool thing to do now:


The core ideas there seem reasonable, which should be expected since someone put it forward as a sort of holy grail. The usual problem is that the real world is far too diverse and subjective, which means any theoretical plan falls short. There will be features which are simple enough that will need no conversation whatsoever, and features that are so entrenched into the system that there’s no reasonable and real “minimum viable” product. There will be very effective people that love communicating, and very effective people that prefer to stay quiet and will quit if we bother them too much. And on and on… and every day we’ll face a new issue and will need to come up with a new plan.

That reminds me of a realization I had a few years ago while reading yet another software development methodology book: the single thing that is common across every single book ever written about how to develop software “properly” is that behind the book there was a group of people that were very interested in making things work well. So reading the book is useful, because many ideas may be reapplied, but for that to actually work we need a similar group of people that is very interested in making things work well, and actively thinking about the process rather than just following a routine.