Re:What every PhD should know before interviewing with a tec...
by dasmoth on Friday July 21, 2017 @11:28AM
(#14821289)
Software quality isn't the easiest thing to define. In some cases, it means "no bugs", and it certainly looks to me as though the places turning out really-low-defect-rate code for, e.g., aerospace applications are doing a fair amount of up front planning (plus other things -- reviews, dedicated QA groups, etc.)
In other contexts "nice to use" is a better measure of quality, and I definitely agree that some iteration can help there. Even so, I'd caution that iterative development and a planned overall architecture aren't necessarily incompatible. And when following an iterative approach you have to be pretty careful to optimise for something that most users like, rather than a just bolting on everyone's pet feature.
Perhaps you misunderstand the agile process? Quality isn't something you ever actually achieve through the Feynman Algorithm (write down the problem -> think real hard -> write down the solution) regardless of whether you spend two hours thinking real hard or two years. Quality is achieved through iterative, continual improvement and polish. Otherwise, waterfall software would be the pinnacle of quality.