PBL works best in the presence of learning objectives, such that the project has domain deliverables, but is also explicitly designed to lead to learning outcomes. (In a team project, these objectives are mostly defined at the level of the student, not the team.) Ideally, these learning objectives are shared with, and maybe even, in a college course and maybe earlier, co-developed with the student.

“5 PBL Pitfalls to Avoid” [^1] may not be the final or best word on PBL, and it focuses more on PBL in primary education, but it's relevant and I was able to find it in ten seconds via Google. ([^2], which links to this, is the top hit for “project based learning”.) “The Practice is not the Performance” would be a stronger article if it either (1) responded to PBL as it's actually used (in my understanding and experience) in schools, or (2) argued that, and why, college-level applications typically stumble into the pitfalls in [^1]. (Which may indeed be true, but I'm not prepared on the content of “The Practice” to weight the authors claims over my own experience.)

The author's other point is around isolation practice. Well, yes. Olin's current Software Design course (intro to Python and programming, typically taken in the second semester) takes a textbook approach[^3] to the basic concepts of programming and computational thinking, and introduces projects as concurrent stream. But also — musicians, athletes, and other performance practitioners are often advised not to perform isolations to the exclusion of longer phrases or entire pieces, lest (1) they forget how to combine the elements into a fluid whole, or (2) they remove the feedback loops that tell them what areas of weakness to isolate. The software analogue of (1) might be design principles and practices that don't appear with isolated elements or at small scale. The software analogue of using isolations within a project context might include discovering that you don't understand a language feature well enough to use it or debug it, taking time out to explore it by reading or experimentation, and then returning to the project. This doesn't downplay the importance of isolations, but it uses them as a complement to PBL, not a substitute.

I think there's a lot to be learned about software engineering (which I think is what the author means when he refers to “CS”) from instruction in music and in studio arts, but it's better learned from a deeper look at both formal and informal instruction in these areas.

There are some open questions, not (I believe) mentioned in the article but raised in some of the comments here:

* Who is PBL appropriate for? For example, Olin College uses PBL — mostly within the context of Team-Based Learning (TBL) — extensively. However, the Olin admissions process[^4] evaluates candidates within the context of a group activity, which overlaps substantially with PBL and TBL, and provides not only information about the candidates to the students, faculty, staff, and alumni on the team, but also provides a taste of the TBL/PBL experience to prospective students, that they can use to self-select prior to matriculation.

* In what domains is PBL applicable? It seems to me a clear win for many engineering, design, and entrepreneurship topics. Olin's Quantitative Engineering Analysis[^5][^6] is a multi-year experiment in applying PBL to introductory-college-level math and physics.

[^1]: Frank McKay, “5 PBL Pitfalls to Avoid”. https://www.edutopia.org/article/5-pbl-pitfalls-avoid

[^2]: Edutopia, “Project-Based Learning”. https://www.edutopia.org/project-based-learning?gclid=CjwKCA...

[^3]: Literally. Allen Downey, who designed an early version of the course and is on the faculty, wrote the textbook: _Think Python_. http://greenteapress.com/wp/think-python-2e/

[^4]: Olin College, “Candidates Weekends”. http://www.olin.edu/admission/candidates-weekends/

[^5]: Olin College, “QEA”. http://meet.olin.edu/olin-isms/quantitative-engineering-anal...

[^6]: Olin College, “Changing Course”. http://www.olin.edu/the-wire/2016/changing-course/