Incompetent but Nice, Surfacing Worldviews in Design, Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle
What do you do about someone who’s really nice but can’t seem to do the work?
The proximate answer is fairly easy: you try to help them level up: pay for classes, conferences, and/or books; connect them with mentors or coaches; figure out if something’s in the way and remove the blocker. Sometimes folks in this category just need to learn, and because they’re nice it’s easy to give them a lot of support and runway to level up. Sometimes these are folks with things going on in their lives outside work and they need some time (or some leave) to focus on stuff that’s more important than work. Sometimes the job has requirements that can be shifted or eased or dropped – you can match the work to what the person’s good at. These situations aren’t always easy but they are simple: figure out the problem and make a change.
But occasionally I run into people who seem somehow resistant to change. You can’t identify any particular reason why they’re struggling – and, more importantly, neither can they. Any changes you make are ineffective: they just can’t seem to get work done.
Une entrée en deux bandes, suite à cet article qui détaille le problème, un autre article relate toutes les réactions qui suivi le premier article avec pas mal de matière : Follow-ups to “Incompetent but Nice”
Design choices carry along the worldviews of the designer. This often is not apparent, especially when design ideas are for obvious technical improvements. Let’s look into a design challenge faced by a fictional Maker Lab.
Un court article qui enseigne par l’exemple ce qu’une vision du contexte peut avoir comme impact sur la résolution de problèmes. Je pense qu’on a souvent vu le premier scénario de d’approche par la tech.
Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner. This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006–2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction.
Je vous le partage ici parce que ça va à contre courant de ce qu’on (je) raconte sur les defects, et que j’aimerais votre avis. Je me plante ou bien l’échantillon est biaisé par à la fois une source (personne) et des projets utilisant uniquement un framework dont la propriétaire revient à l’université qui a mené l’étude ? Aussi, dans les définitions il est dit que le coût et l’effort sont confondus ce qui me parait pas une bonne idée puisque d’un contexte à l’autre on arbitrera pas de la même façon selon ces deux axes.
