A moment's respite

Time to take a break from real-time Java. Having worked on our programming languages assignment for most of my waking hours in the past two days, a lot of stress and frustration has built up, and something needs to come out. Unfortunately, I don't need to use the bathroom, so I guess I'll be regurgitating what I've been thinking about in the past few days. This happens to be how not to engineer software.

Our software engineering class has thus far probably taught me more things that are bad practices rather than good. Unfortunately, these practices reflect upon just how bad our development process actually is when executed. Here they are, in no particular order of importance:

• Using version control without knowing how to use version control. Everyone knows that version control is necessary, especially for larger projects. To argue otherwise is essentially arguing with a brick wall—nobody cares. Unfortunately, knowing that version control is necessary still gives little incentive on how to use version control proficiently. I'm not here to give a lecture on how to be a version control expert, because undoubtedly I'll be wrong about something. However, it's amazing how some people in Computer Science at the senior level simply don't "get" version control. Our department steadfastly believes that teaching tools is a waste of time—such is the job of C&IT. At this point, I'm almost convinced that they're wrong, to some degree. One teammate assumes that checking out a new repository and copying all of his files over before committing is a good way to fix conflicts. This is obviously a very bad idea, especially if you have files that are out of date, and it just so happened to be the case. His solution? Blame Subversion for everything. The problem is between the keyboard and chair. Seriously.
• Not communicating properly. When an e-mail goes out to your customer, all of the relevant people on your team should receive a copy of that e-mail. For us, that's everyone on the team. There's no reason not to, and leaving out people results in very one-sided communication.
• Not listening. When a teammate has something to say, learn to listen. Interruptions are not usually helpful. Neither is waiting until the teammate is done talking, but not listening. This really shouldn't have to be mentioned, but this is actually a common occurence. Listen to the other person, and then if he/she is wrong, then explain why. Interrupting because you're 200% convinced your method is infallible is unacceptably rude and arrogant.
• Project tracking instead of project leading. A recent article on Reddit summarized the problem nicely. A team leader is not responsible merely as a gateway to the customer; a leader is ultimately responsible for keeping the team accountable and heading in the right direction. Can't do that? Please don't be a team leader. You may get this fuzzy, warm "leadership" experience to put on your resume, but the result will be that your team will fail.
• Allowing feature creep. This seems to be a fairly common problem. On a deadline as short as ours (one semester), it's vital to stick to the defined specification. "I think ______ would be nice" is completely unacceptable. This will result in a traffic jam and a failure to complete the project on time.
• Not using an issue tracker. Humans are typically not very good at context switching. Typically, when you find a bug, the best way to deal with it is to file a bug report. If you decide to fix the bug immediately, unless you were specifically looking for the bug, you're context switching away from what you were previously doing, which can end up being quite a distraction.
• Lack of in-code documentation. This is probably something that virtually all CS majors at Purdue are guilty of. When we're working alone, there's no reason for us to comment; we're all brilliant geniuses that always retain understanding of what our code does. Unfortunately, this brilliance doesn't transfer when you work on teams. In-code documentation is important for quick reference. In addition, many languages support extracting the documentation out from code into various document formats, which adds even more benefit to code documentation. This alone should be a good reason to document function headers. Nobody is asking for an essay, but at the same time, nobody understands what your function does.

All in all, this is a very random assortment of pitfalls I've seen among my software engineering team. Some of these are more easily corrected than others, but sometimes I wonder if it's even worth it, with so little time left.

Ah, time. Where did it go? This semester feels like it's gone by faster than the rest, perhaps due in part by the post-graduation stress that I'm experiencing. I'm flying out to Google for an on-site interview on Thursday; Microsoft has invited me to an on-site interview, but I don't know when; grad school applications are still looming over my head. It was probably a bad idea to take three CS classes this semester, of all semesters.