Reflection and Failing Fast

While reading some articles for class, I was struck by the similarity between the Reflection Cycle  and another similar cycle I’ve run across often related to in continuous improvement and user testing for websites. I have often seen the PDSA (Plan Do Study Act) Cycle, or one of many slight variations referenced as a model for how to improve a product or design . Having identified a problem, one can plan a test, perform the test, study the results, and then make changes based on the results. The cycle then repeats, studying the effectiveness of the change.

It is not surprising to find essentially the same pattern in learning; what we are accomplishing in continuous improvement cycles is learning about our users and our topic. Portfolio websites provide a mechanism to reflect on the topics we are discussing, gain feedback and alternate viewpoints, and then revisit the topics again with greater understanding.

Which leads me to another model from the software development world, “failing fast.” The idea is that, instead of writing software that can hide errors, the developer should write programs that show errors very quickly so they can be easily found and corrected . Of course a developer wants to be sure they are not shipping the product with those errors, so it is important to flush out as many of those errors as possible while the stakes are low, within a group that shares the same goals. Again, the portfolio process allows us to “fail fast” and among peers while we work through ideas and grow.


Barrett, H., & Richter, J. (n.d.). Why reflect? - Reflection4Learning. Retrieved May 8, 2017, from
Best, M. (2006). Walter A Shewhart, 1924, and the Hawthorne factory. Quality and Safety in Health Care, 15(2), 142–143.
Deming, W. (n.d.). PDSA cycle. Retrieved May 8, 2017, from
Shore, J. (2004, September). Fail fast. ThoughtWorks. Retrieved from