With Karl Groves, Tenon.io
At first, the cost of fixing a bug at the requirements stage is nominal, when everything is on the drawing board. But as the software moves along in its life cycle the cost of fixing a bug increases radically. We start at 1 times when we are at the initial development stage when a bug is no more than a change in notion. But at the design stage, the relative cost is 5 times what it was compared to the requirements stage, and then ten times what it was when it becomes code and on this goes until it the relative cost of a bug fix is 150 times what it was originally. Source
However, it was the hidden costs that drained us of life: hours lost arguing about bugs in bug triage meetings; hours lost stumbling over the same known issues again and again; hours lost fighting with a fragile and error-prone code base to make even small changes; hours lost cataloging and categorizing the backlog. It was demoralizing and immensely expensive. Source
|1||QA tests, finds, and opens a bug||1.0||$60||$60|
|2||QA/ Dev manager assigns the bug||.25||$15||$75|
|3||Developer reviews the bug||.25||$16.25||$91.25|
|4||Developer verifies the bug||.50||$32.5||$123.75|
|5||Developer fixes the bug||1||$65||$188.75|
|6||Developer assigns the bug back to QA||.25||$16.25||$205|
|7||QA retests the bug||.75||$45||$250|
|8||QA confirms bug is fixed||.25||$15||$265|
Oops, maybe we should see if this product we’ve developed is accessible
Core goal of XP: Introduce a number of basic values, principles and practices to improve quality. The "Extreme" in extreme programming is the way it takes development best practices to the extreme.
Code review? Why not pair programming?
Acceptance Testing? Why not automate it?
Short release cycles? Why not continuous integration?
The only truly important product of the system development process is code
If a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws.
Developers must listen to what the customers need the system to do
Good design is critical especially as the product grows. Unwieldy design exacerbates quality/ UX/ a11y shortcomings.
(we good, UXers?)
Hint: both of these can be driven from Gherkin language
You don't have accessibility problems, you have quality problems.
A lack of quality-oriented development practices elsewhere is your first warning sign that you will fail in accessibility
Get out of the a11y silo.
Stop treating a11y as a separate concern.
Start approaching a11y as a quality domain.