For some reason, I decided to volunteer to give a talk about software development to some Grade 9s. It was an interesting experience, to say the least. I had to think of things to keep them engaged, and I really felt when they made a connection. I also really felt when I had lost them completely - they all had phones. =/ For better or worse, my notes are below:

How do we come up with an idea for a product? You might think that there are people who sit around D2L, whose job it is to think of things to build You might think that ideas come from people who use our systems, and pay us to build things for them The truth is that it’s a mix of both.

We have something called the product ideas exchange, where people propose ideas, and we take those ideas and incorporate them into what we are already planning to build. Your teachers can log in, and vote for features that they would like to see!

Once we have an idea for something that we’re going to build though, it’s not just a matter of sitting at a keyboard and making the magic happen. If we did that we could go in a very wrong direction. We use something called requirements gathering to make sure that what we’re building is what people want. What is requirements? Well, imagine soma friend asked you to build something that could help them carry rocks down the street. What would you come up with? What if you then found out the street was Yonge street (56 km?) What if you they told you the rocks were diamonds?

A lot of times, people don’t know or can’t describe what they want, and we need people to ask good questions and tease that out of them.

That’s why it’s important to talk to the people you’re building things for. We at D2L spend a lot of time testing things with people, bringing them in to try our designs, and seeing how they interact with those designs.

Another technique we use to build software is something called iterative development. It’s in-line with what we talked about for gathering requirements, but a little more concrete. Going back to our transportation analogy, we would first build a skateboard so that our friend can start carrying rocks down his street. We would be able to quickly get feedback from our friend, and he would say something like, “It’s hard to skateboard with my hands full”, so we’d build an attachment for the back of his skateboard. Then maybe we’d upgrade it to a bicycle, so he could go a bit faster. The whole time, he’d still be able to carry his rocks, so we wouldn’t be stopping him from doing what he needed to do, we’d just be making gradual improvements so he could keep doing what he was doing. The alternative is to give him nothing, until we deliver him a pickup truck.
He’d be unable to start carrying rocks until we were done.