An AI Manifesto

While researcher and journalists have certainly written much nonsense about AI, none of it competes in my mind with the recent silliness from Stephen Hawking and Elon Musk.

To that end, I offer an Artificial Intelligence Manifesto, modeled of course on the Agile Manifesto.

We are developing computational models of cognition. Through this work we have come to value intelligence that

• bases its decisions on benefits and costs, rather than politics and religious dogma
• exposes the depths of its uncertainties, rather than saving face and scoring points over opponents
• continually learns from failure, rather cherry-picking the facts that fit its opinion
• takes its goals from the needs of modern society, rather than the distant needs of biological survival and domination

Why competency-based learning is not enough

Critique-based learning and my virtual talk on education in 2025 say much that is also said by proponents of competency-based learning, including the emphasis on proficiency over seat-time, multiple pathways through a curriculum, formative over summative assessments, and teachers as mentors not graders.  When Success Is the Only Option by Sturgis and Patrick as an excellent overview of the ideas of CBL.

So is all I'm saying really CBL? Is CBL sufficient to define what education needs to be? Let's look at two large examples of CBL: the Florida Virtual School curriculum and the 2014 Western Governors University course catalog (course listings start on page 40).  What you see there looks identical to the courses you see offered in any traditional curriculum: Chemistry I, College Geometry, US Government and Constitution, etc. Compare those courses with the role and story driven offerings suggested by slide 21 of my virtual talk or actually offered at XTOL.

CBL is built on the same broken discipline-defined foundations-first content structure of traditional curriculum. Competency rather than seat-time is the right idea -- but competent in what matters just as much.

Education: So much to critique, so little time

I don't mind giving talks but I suck at sending things to conferences.

So I created a standalone virtual talk on what's wrong with education -- it's a long list --  and what it could be like instead. You can see it at Roger Schank's Engines for Education site.

Scrum Grumps

In my software development course at Northwestern, I emphasize early delivery of value and team development. I start with the second and move to the first over the 10 weeks of the course. I constantly refer students to those whose ideas have fed into my understanding of lean agile, including DeMarco and Lister, Brooks, Weinberg, Beck, Cunningham, Jeffries, Cohn, Rothman, Rasmusson, Ries and many more.

The one big thing I don't do is claim to teach Scrum. I teach most of the parts, such as user stories, backlogs, velocity, and daily standups (not "scrums"), but there are a couple of terms I avoid and actively un-teach when students come across them.

Sprint

Sprint says run like crazy, but not for very long. I know that's not what "Scrum Sprint" means but that's what "sprint" means. Words matter. I want my students to see development as steady loping, not repeated mad dashes. There's just one sprint in my course: a hackathon at project start to get the very first testable slice to the client. This first mad dash has benefits for the product, developers, and client-developer relationship. The one bad side is technical debt but the code base is still small and you have plenty of time to pay off technical debt. I use iteration.

The length of sprints, from two to four weeks, is also problematic. For anyone new to agile, I prefer one week. Move to two weeks when things are humming along -- or move to continuous delivery and drop iterations all together.

Scrum Master

[Edited January 30, 2017]: Master? Words matter. Master sets up a power relationship with developers I am not at all comfortable with. Even worse,  here is how Scrum Master is defined in the Scrum Guide:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

No wiggle room here. A Scrum Master is an enforcer. The Scrum Master tells you when you are and are not doing Scrum properly. This is about as far removed from a role I would want someone to play as can be.

What do I teach is the needed? Agile coaches.  The role of an agile coach is to help you identify ways in which team and business needs could be better served. An agile coach is good at

• detecting when things are going off the rails before the team does
• identifying counter-productive processes and attitudes
• suggesting simple and effective things to try to improve the development of both the product and the team
• making these ideas real with stories from personal experience and case studies

Increment

My minor grump is the definition. The Scrum Guide defines an increment as "the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints." This is an odd use of increment. In normal English, an increment is an increase or addition, not the accumulated total.

But my real grump is with the commentary under the definition of Done: "Each Increment is additive to all prior Increments." I am not the first to note that an additive view of implementation fits very poorly with the realities of product development. I use version with no commitment to steady growth. Build-measure-learn.

Courage in Profiles

(For those under 100, the source of this title.)

At least half of the student teams I coach in agile software product development have creating a user profile interface as their first or second user story. They're so used to seeing them in Facebook and elsewhere, that they assume they must have them.

Profiles are friction, pure and simple. There is no user payoff in creating a profile. How silly would an app be if all you could do with it was create a profile? Well-known sites can get away with profiles because users already know they want the services those sites provide and are willing to put up with some friction. Your fledgling app is unknown and probably not all that good yet. Users have no incentive to put up with any friction with your app.

Nor is there any value gained in early testing of a profile creating interface. No risk is reduced, because such pages are not hard to build, and no business value proposition is validated.

"Maybe so," the teams reply, "but our app has to have user profiles."

I've yet to see that actually be the case with any team.

The first argument for user profiles is usually "we need to know who the user is so that we can attach data to them." For example, if someone joins a scavenger hunt game, we have to know who they are so we can keep track of what items they have found.

This argument confuses identity with a user profile. To give someone an identity, all you need to do is give them a unique URL that they can bookmark and/or save on their home screen. Writeboard (recently retired) from Basecamp worked this way. When doing early product development, it's a way to get test users started with no friction or commitment on their part, and total control over the identity on your part.

The second argument for user profiles is so that users can specify preferences, e.g., what name they want to appear under, how and how often they want to be sent messages from the app, and so on.

This argument assumes that the only way to collect preferences is to interrupt the user's experience. How many apps have you used, from Google, Facebook, and elsewhere, where you wanted to change one thing, e.g., whether to get email reminders, and you had to go a preferences page with dozens of options to search through? Now consider the alternative: you get a reminder you don't want. It includes a link that says "don't send reminders in the future." One click. Done. Or your favorite restaurant searcher shows the places too far away, so you click adjust the radius of search and say yes when it asks if you want this radius to become the new default. Two clicks. Done.

Not only do these alternatives have way less friction, the friction is connected to immediate payoff, not some potential future benefit.

So does this mean you should never implement a user profile and preferences page? Not at all. Such pages are a great way for users to review and adjust their current settings. But such pages are just nice to have's. They aren't and should never be critical to your app or your early development process.

Have courage! Put user profiles where they belong, on the backburner, off the main line of development.