Final thoughts on the class

It's been an interesting ride for sure.  I have some mixed feelings I guess.

The Good
The course has a 'real-world' feel to it that isn't normally felt as much in other CS courses.  We talk about industry standards, current trends, and how stuff actually gets made and (gasp) marketed.  Being allowed to choose all of your technologies as well as the project content allows for creativity.  Ackley is a great speaker and I think we all enjoyed his lectures greatly.  Our finished product for the class gives us way more pride than getting an A on some final exam.

The Bad
Sometimes, it didn't seem like the class was teaching us anything.  It's very non-traditional; at first I really like this, but it started to wear on me after a while.  I was trying to figure out if this was a good thing still.  I think that overall, it is good, but the class could use a wee bit more structure and consistency.  Students often don't know what comes next.  Frankly, the 'grading scale' scares us; we have little clue what it is or how it works and accordingly don't feel in control of our academic success in the course.

The Ugly
I think future iterations of the class should do away with personal project ownership.  I like that everyone proposes a project and the best ones get made.  However, I don't think the owners' of them should have to do pitches to 'sell' them to their classmates.  We get plenty of practice with project pitches in the latter part of the course.  Related to this, I'm not sure that having team leaders is a good idea either - this (naturally) seems to lead to contention from some team members who feel their grade is negatively impacted (via not being positively impacted) by not being a team leader.  It also adds stress to team leaders that they didn't sign up for.  I don't think the course is more valuable for having people directly labeled as 'project lead'.


Sure was some of the tougher 3 credit hours I've earned during my time here.

Making a 'software time capsule'

That's kind of what it felt like today, to me, when we were wrapping up all the components of this project (code and non-code elements alike) into a single tarball.  I was picturing somebody opening this file up in 30 years (if they could...) and looking through it.  Would they be impressed?  Disgusted?  Would they laugh at how 'hard' or 'crazy' software engineering was in our day, like how we laugh at old-timers when they talk about punch cards?  I also wondered if people that far from now would understand what the product was for and what it wasn't for.  I really kind of wished we had made more documentation to go with the shipment - I guess the project proposal describes the purpose of most of it though.

It also felt a little odd to 'pull the trigger' and ship the thing.  For one, there's always that lingering feeling of "is everything good in there?" (at least for me).  But also it's this feeling that the project is over, and probably will stay in it's neat archive for the rest of it's days "being looked at by top men".  In some ways that makes me sad, but I'm not sure that I have the expertise yet to bring a product like this to market yet.  Perhaps one day, future earthlings (human or not) will unearth the project and bring it back to life with their super futuristic computing technologies.  Or maybe they'll find it quaint when they discover it, already having an ultra-advanced case-based diagnostic program of some kind.

I'll take it!

We got 2nd place, and I'm more than satisfied with that.

I was SUPER impressed with the presentations today.  I had written in my last post that I wasn't seeing the point of doing so many practice pitches.  It kind of 'clicked' for me as I was watching the final ones today.  I was seeing each group give a killer talk, and remembering pieces of their 1st and 2nd presentation attempts.  What a difference indeed!  I had almost no complaints about the presentations today, whereas in the first couple, I could have come up with decent lists of nit-pickings for most groups (including my own).  From watching the presentations today and going last, I really didn't think we would win 1st or 2nd.  I remember thinking, "wow.  These people are stepping up our game.  I feel kind of out of my league".  Honestly, it dialed up the pressure for me.  I was more nervous for this presentation than the in-class ones, and now I realize a lot of that was from watching a full round of them first to see what everyone else had brought to the table.

I hope the other groups don't take the opinion of the judges too seriously though.  I personally found some of the questions from the judges to the groups (including mine) to show a lack of understanding in some areas, or a difference of opinion on some things that I really didn't stand for.  After all, it's pretty hard to judge the quality of a software project/idea based on a 7-9 minute pitch.  It was nice to have good feedback from successful "adults" (whatever that means), though.

Ahh, a living project!

Nice feeling.

We're pretty much done now - everything is working, website is being (re) launched, and we're good to go.  We rehearsed our final project pitch for tomorrow, which now includes a small section by David Strawn.  After that, we make the archive and review each other and ourselves to call it a day.

I'm excited to finally finish the presenting portion of the course tomorrow.  I'm a little dismayed at how much presenting the course has entailed, and find myself questioning it's value.  We had to give a solo project pitch to the class.  As a group, we've now given two 7-9 minute project pitches to the class, and will give a third one tomorrow.  When we were rehearsing today, I was thinking about the somewhat repetitive nature of this activity.  While we have tuned and tweaked our presentation, it feels odd to rehearse and give it so many times.  Perhaps that's a good thing, in that we should be prepared to give a solid show tomorrow.  But at the same time, I wish I had gotten more 'meat' from the class.  It has kind of felt like some kind of "graduating exam", where the class is more about everyone proving themselves to the professor and TA than it is about learning things related to software engineering and computer science.  I liked this aspect of the course at first (this "selection" and "competition" aspect), but after a while it has made me (and probably others) wonder what the course is meant to teach us about either CS or SE.

Thoughts on programming language debates

By and large, they're pointless.

Yes programming languages are an important part of computer science and software engineering.  But sometimes I get the impression a lot of people think programming languages == CS & SE.  I would argue that languages are an implementation of ideas from CS and SE (i.e. paradigms), and little more.  We get so wrapped up in the whole "this language vs. that language" thing that I think we tend to forget that the ideas behind a programming language are far more important than the language itself.

Let's take the classic C++ vs Java debate.  Personally, I prefer Java.  This is basically for two reasons:

1.) I find Java easier to debug.  For example, dereferencing a null pointer in C++ usually gives the classic SEGFAULT, with little information about why.  Java gives a concise NullPointerException, with a corresponding line number in the code.

2.) I tend to discover that Java has an easier-to-use and more complete set of libraries.  The libraries in Java are documented in a single place for the most part (I don't really see this with C++).  I also tend to find that the standard libraries in Java have more useful and easier to remember semantics than C++.

But let's notice something about these two characteristics: they are not really definitive of the programming languages themselves, but rather the system by which they are implemented.  The fact that Java is easier to debug arises from it being run in a virtual machine, rather than natively on machine hardware.  C++ could, in principle, be made to run this way to make it easier to debug.  Similarly, one could imagine a good samaritan coming along the remaking the C++ STL to be easier to use and understand.  The point I'm trying to make is that it's the sort of side features, not the actual language, that often makes for a determination of which is better.  If you compare the syntax and semantics of the core of the two languages, they are very, very, very similar in my opinion (such that I was able to pick up C++ quite easily from knowing Java).

If I may make a car analogy, what people generally like about and use to distinguish between cars are external features.  Things like the interior (even it's freakin color), dash displays, and how the car looks on the outside.  Performance of the vehicle is important to some people too, but generally only from an outside view - most just don't care what the engine actually looks like on the inside, since they have no reason to look.

New programming habit, courtesy of Mr. Strawn

After reading some of David Strawn's project code, I decided I really like the way he comments things.  He does stuff like this:

/* Setting up bla bla */
int x = ...
int y = ...
int arr[] = ...
/*******************/

/* Compute such and such */
arr[0] = x + y;
.....
/*******************/

At first I found it kind of strange, but I actually really like this methodology.  The result is truly readable code.  The /****/ blocks serve to show the end of a particular "logical block" of instructions.  This segmentation is way better, in my opinion, than just the sort of side comments you normally see at the end of a sparse number of code statements.  I've been using this style for commenting and documentation for the code I write at work (Sandia), and I think I will continue to.  When I show it to other people, they seem to be able to follow it pretty easy by virtue of it being segmented into kind of high-level events, rather than just a dense set of program instructions.

Reflections on class wrap-up

The class has been a mix of interesting as well as frustrating.

A lot of the time, the grading scale seems arbitrary.  Well, I guess it is arbitrary.  Probably by design.  There are some consistent deliverables, like blog posts, but even these do not have very specific guidelines for length or content.  Much of the work of the class has a very vague set of evaluations associated with it.  This seems kind of realistic, given my small work experience in a professional software environment (Sandia), but for the class it's rather frustrating.  You never really know where you stand.  Do I have an A?  B?  Are there things I could be doing better?  On a related note it sometimes feels like you're getting graded badly for things that you can't really fix; I know a few people have said they felt they were getting an unfair shake because their project idea "wasn't original enough", or something to that effect.  On the one hand, it seems cool to give winning projects credit for their 'impact', but what about if you don't have a winning project?  Is that entirely a product of the quality of your pitch and proposal?  I think not.  It's largely a function of the value or appeal of your idea, which is true in life as well, but makes the class feel like you signed up for "Invention 460" or something.

Discussion: CS vs SE

As far as the discussion today about CS vs SE, I think many good points were brought up.  I would generally agree that CS is more about ideas while SE is more about products.  But I think everyone should remember that you can't have many products without solid ideas.  Some people in the class seem to have the sentiment that SE is some distant relative to CS at all, if they're even related.  Things were said like "I had to learn things for this [class] project that I wasn't taught at UNM", as if to say their training here in CS doesn't help them at all in building software.  I just see so much wrong with this sentiment.  I would argue that if you handed a workload like this class presents to a 1st-year CS student, they would crumble.  Sure, we've all had to learn a lot to execute these projects, like new programming languages, web frameworks, database systems, and so on.  But there is a ton of knowledge in the background that we use all the time when we are designing or coding these software projects.  From algorithms all the way down to just basic code quality and conventions.  There's a reason you can't take an average Joe off the street (or an MBA, for that matter :) ) and get them to do this kind of work.  There is a lot of little skills and implicit knowledge all over the place about how to understand and work with computers, how to design robust and flexible code, how to keep your cool under frustrating or confusing conditions, and so much more.  In closing, I would argue that CS and SE are not disjoint fields at all; they each have regions that do not overlap (highly theoretical CS research, Facebook, etc), but I would argue that their overlap is greater than their disjoint areas.

A few words on unit testing

In short: I'm infected.

The more I use unit testing (mostly JUnit, but I'd like to get into it for C++ and Python), the more I like it.  It not only gives me a frame of reference for the correctness of code, but also helps me understand the purpose of sections of code more concisely.  I've even become a sort of automated testing evangelist, wanting to spread it's teachings to others (like at my job).  It appears that much of our woes in the software world come from a lack of acceptance testing; we think a piece of software is correct, though we've only used it a few times in ways we probably already know it works (these cases were tested throughly during development, most likely).  I'm starting to think more and more that automated acceptance/unit tests should be a requirement for every software project of significant size.  It's kind of a way to make an implementable version of the software specification and requirement documents.  Bugs are found faster.  Stress goes down because developers are less fearful to make changes or refactor, because they have a tool which can verify the correctness and functionality of the code base quickly.  I think my next step for my unit testing journey is to actually write some tests BEFORE I write the program that solves them.  It sounded crazy when I first heard of such a thing, but I think I'm ready :)