We were recently written up in some cool blogs, so we figured we'd share them with you.

Kare Anderson's blog, Say It Better, featured us in a post about attracting employees.

Massively, a news site that covers the MMO market, gave us a short write up.

SeedWatcher, a blog about early stage start-ups by one of our angel investors, interviewed  me in connection with our latest financing.

We recently raised our Series B financing. We couldn't be more excited about the firms we are working with. The press release is below. 

Grockit, a San Francisco Learning 2.0 Start-Up has raised its Series B financing. Integral Capital Partners lead the $8M round with Benchmark Capital, who lead their Series A, participating as well. Grockit is creating a MMOLG (Massively Multi Player Online Learning Game) where people can connect to learn from each other. The company was founded by Farbood Nivi, a long time teacher, and Michael Buffington, a well known Rails developer. Grockit will use the latest financing to expand their development team and they plan to launch their first product this fall.

You can also check out our post on TechCrunch. 

Growing up, the score at the bottom of the screen of a Basketball game would update about a second or so after you looked down at it. And, as you didn't look down until you saw what looked like a legitimate basket, there was a flow.

1. Notice the basket
2. Look down to bottom of screen
3. Watch the score change

Lately, probably because of advances in technology, the score often updates before you look down. You can be left staring and waiting and sometimes not really knowing whether the current score is the updated score or the pre-basket score. You can end up staring longer than you would had the score been delayed a second, allowing you to look down.

So, from a UI perspective, should there be a 1 second delay in the update of the score on the screen? Would one test this? How?

At Grockit we employ some pretty serious agile development, or extreme programming. Just a few examples include...

1. Our developers code in pairs that rotate almost daily.
2. We write code to pass tests, not tests after writing code.
3. We iterate, iterate, iterate.

I would like to take a moment to discuss the first point. Our developers code in pairs.

Grockit's MMOLG is about students teaching students (yes, it's ok if you're a teacher, you can play too). And recently, I've had some discussions with folks around my comments about the problems in education and the re-design it badly needs.

I realized, in these discussions, that paired coding is what I'm talking about. Because we code in pairs, all our devs get in on the action. This means that every dev is constantly teaching and learning from the other devs. We don't do peer reviews, we don't need to.

Does every dev come to the table with the same skills and skill level? NO.
Does paired coding work despite individual differences? YES. In fact, it works because of it.

People think that students teaching students is impossible because, 'Where do you start?'. It seems to imply that half the students need to already know the material if they are going to teach the other students. Not at all. Let's look at what our devs do.

When the team is faced with a challenge that nobody has the immediate know how to address, someone starts doing some research. This is what happens in real student to student learning. The first thing you need to do if you're going to teach someone is to learn it yourself.

When Russell Ackoff was asked by a group of students to teach them systems, he said 'No, but you can teach me.' Well, teaching Russell Ackoff about systems is a serious challenge. Nevertheless, after many months of studying and working together the team put on a seminar for Ackoff that he described as the best course in systems he's ever seen. In fact, one of the students is now a major planner for Brazil.

In paired coding, or paired learning, the group continually builds on top of its strengths. In this modality of learning it would be impossible for students to graduate illiterate. As it stands, an alarming number of 8th graders can't read and write. We've been trying this education design for about 100 years now and quite frankly the bar has not risen much. I think it's time for a change. I think it's time that students take the responsibility to teach each other.  Can our students handle it?

Well, before the modern industrial revolution, people began having families as early as 13 or 14 years old, and certainly carried far graver responsibilities than children do now. We are sadly mistaken in thinking that young people are not motivated or capable. We take on this view because we place them in an environment that they finding very demotivating and that strips them of their responsibility to contribute. Strangely enough, when it's a matter of their own well being, people can make the personal choice of caring or not. When our responsibilities are to other as well as ourselves, we often care quite a bit more. In fact, some parents might argue that their kids care only about the thoughts and wants of their peers. What a wonderful leverage point to help students teach each other.

The industrialization of education came on 100 years or so ago.

We still haven't recovered. The idea of applying the burgeoning mass manufacturing model of the factory to the school must have seemed like a good idea to the civil planners of the time.

In the early 1900s, the number of schools in the country was cut in half. Any guesses as to why?

This was the mass movement from single room school houses to larger city schools. The idea was that if factories could improve quality and quantity of manufacturing, so could schools.

Instead of teachers being facilitators of a classroom where students taught each other, they became the factory worker, the school the line, and the student the car making its way down the line.

Even here, the analogy almost makes sense. Things start falling apart though. Unlike the sheet metal coming into the factory, each student entering a school is a totally different raw material.

That's not the problem though. The problem is the same that Edward Demming pointed out to the auto industry decades ago. Quality.

Demming argued that equipment must be constantly checked to be within a tolerance. At the end of the line you get Toyota cars that all work to the same exact specifications with almost 100% quality.

The analogy is this. If cars were made like we make students, they would come off the end of the line and some would work and some wouldn't and we wouldn't know where things went wrong. The cars that came off the line non-functional wouldn't be fixed, they would be shuffled off to places where functional cars aren't really needed.

Without metrics measuring the delta of a student's learning before and after said 'learning', we are left with a system that shuffles students down a line and out the door. Some work, some don't. Nobody knows where they went awry.