On Wed, Oct 5, 2016 at 11:12 AM, Viktor Engelmann <viktor.engelm...@qt.io> wrote:
> It's okay for quickly evolving UX, but we are talking about > long-term concepts that need to provide stability and IMHO > that requirement is incompatible to agile programming. > > If for example you developed a network protocol in an agile way, > in the end all machines would speak different dialects and you'd > never get them to communicate reliably. > Depends on what you call Agile I guess. For instance I remember Ableton Live (very famous music software)'s first 8.x versions were buggy as hell. What they did was : * do a full code audit * implement Agile processes ( http://www.synthtopia.com/content/2015/03/07/behind-the-scenes-with-developers-at-ableton/ around 5:00 and the various videos here : https://forum.ableton.com/viewtopic.php?f=1&t=217683 ) * for months, almost a year if I remember correctly, they entirely blocked ( http://cdm.link/2009/12/ableton-suspends-development-to-focus-on-bug-fixes-for-live-8/ ) the implementation of new features to focus only on bug fixing. They took a somewhat long time, which let time for competition to build up a bit, however I think that most agree that the resulting product was well worth the wait since it actually *worked*. So I'd say that agility is orthogonal to stability, it's just a way to manage the teams. Best, Jean-Michaël <http://www.jcelerier.name>
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest