A Variety of Programming Techniques

 

I teach a class called “Software Methodology” at The Gordon Institute. My goal is for the students to be able to recognize if a software project is not being managed properly, and to give them a feel for what a software project might be like. So, I have them organize themselves into teams and perform a software project.

I’m grading the final exams, and have encountered these programming techniques:

  • Panic Programming: Writing code as quickly as you can because you realize the deadline is approaching and the project is far from done.
  • Peer coding: (this is not a typo) When you and your peer learn to program together because neither of you know anything about code. One student said, “Different perspectives of the same problem lead to a much faster solution.”
  • Pair party: Get everyone on the project in one room, give them short tasks, teach each pair enough to do the task. When a pair finishes a task, they check another pair’s task. Move around the pairs.
  • Beer-and-projection-group-debugging: The night before the project is due, buy enough beer for everyone. Project the code on the wall. Program and debug together. Loop until project is done or beer runs out.

I wish I could say these programming techniques were new to me. But I’m pretty sure I’ve tried them all except for the one with beer. I can think of a project where the beer might have helped; sobriety didn’t 🙂

I’m excited that the students had a chance to feel what a software project is really like. I suspect they were more willing to try pairing in a variety of ways because most of them had little experience writing code.

Look at your project. Anyone using any of these techniques? Would they help or hurt?

3 Replies to “A Variety of Programming Techniques”

  1. I see a lot of panic programming, and I’ve done some in the past. The worst by product is that things like writing unit tests go right out the window and the code goes out in pretty shabby shape.
    I’ve done peer coding a few times at conferences. It is pretty difficult when both of you aren’t that familiar with the problem domain.

  2. Panic Programming: Yes, especially when requirements change the day before you ship. It continues despite proof that it causes problems in the next cycle.
    Pair Coding: I’ve never done it, but I’ve seen it done.
    Pair Party: Nope.
    Beer-and-projection-group-debugging: Again, nope, but it sounds like something to try. 🙂

  3. All 4 are common. The best part of the Project is the beer part.. doing an all nighter and then converging red eyes for next day demo !! :)-
    The worst is the panic mode, it actually weakens the product. However there is something else which we called “cut throat” programming… just code, in lean mode.. no comments, no documents ..just bridge the gap , we’ll close the loop later kinda stuff

Leave a Reply