First Integrate Detroit cohort to graduate soon, applications open for second cohort

On Saturday, August 25, 2018, the first Integrate Detroit cohort will graduate. I’m one of seven students working on a final project in a computer programming class that teaches test-driven development and pair programming.

I’m of course grateful for congratulations and good wishes. But the main reason I’m telling you about the graduation is because maybe you know someone in metro Detroit who could use a course like this.

Applications are now open for the second cohort. No hard deadline has been set, but as a practical matter, I suggest you tell people you refer that they should apply by August 31, because the second cohort is slated to start soon after Labor Day.

Realistically, I think that an application on September 1 is an application for the third cohort, which will probably start in January.

The location for the second cohort will probably be the same as the almost downtown Detroit location my cohort goes to, but the instructor is open to consider other Detroit locations.

Universities teach computer programming, but the focus is more academic, not industry, and most if not all of what they teach can be learned from books.

Coding boot camps, the good, the bad and the ugly, have more industry-relevant curricula that still leaves out test-driven development and pair programming.

It’s easy to know the dictionary definition of test-driven development and give an example or two. That’s what I’m going to do right now.

In test-driven development, the first implementation of a function or procedure should fail a test. Then you rewrite the tested subroutine so that it passes the test.

Maybe the first test wasn’t very thorough, so you either augment the first test or write another test, which the tested subroutine might now fail. And so, the tests guide the process.

This gives programmers greater confidence in what they’re writing. Testing is not a chore left to the end. By foreseeing what the problems might be, the programmers can be more confident in what they deliver to the quality assurance team.

Now an example, which might feel like a toy example. Suppose you have to write a function that tells whether an integer is prime or not.

This is of course wrong. But it’s good enough to get a failing first test.

Of course 10 is not prime, so the first assertion holds. But 7 is, so the second assertion will fail the test.

So you go back to isPrime and rewrite it so that it correctly identifies positive prime numbers as prime. But what about negative primes? Does your implementation give the correct result for those?

Just add assertions and find out.

You should probably also test for −1, 0 and 1.

Easy enough, right? However, this doesn’t really capture what test-driven development is like in an actual project with multiple pairs or teams, working on several different components, some of which are from third-party libraries.

Nor does it do justice to that feeling you get in going from a seemingly daunting task to something that turns out to have been very simple after all.

Maybe you can learn test-driven development from a book. But to learn pair programming, you really have to be in a pair with an actual human being.

That’s the benefit of a class that pairs a student with another student to write tests on Day Two, if not Day One, which will probably be September 5.

To RSVP to the August 25 graduation, go to To apply to the next cohort, here’s the link again: The source code for the first cohort final project is on GitHub.

is a composer and photographer from Detroit, Michigan. He has been working on a Java program to display certain mathematical diagrams.

is a composer and photographer from Detroit, Michigan. He has been working on a Java program to display certain mathematical diagrams.