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.
Monday, May 5, 2014
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.
Thursday, May 1, 2014
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 :)
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 :)
Monday, April 28, 2014
Critiques on 2nd round, 2nd set project pitches
I'll just give my general thoughts on each group, some of which I may have already said in class. This is mostly just from my memory, but serves as a set of impressions.
Automaton:
Good:
Game looks freakin sweet. Animations and color scheme on it are vivid and engaging. Presentation was better organized this time around.
Not so good:
I think they really, really need to take the intro to the game to a more basic level. They kind of just jump in and say "there's all kinds of buttons and stuff here" and describe a small subset of them. I think it leaves the audience confused about the game, even though we're computer scientists (the subject the game is supposed to teach). I think it would be wise to leave out the more complicated puzzles and instead do a very thorough puzzle that explains each piece of the solution and it's function. I guess it's late for this, but I also think it would be a lot less overwhelming to new players if many/most of the buttons are disabled or made invisible in the early puzzles.
Visual Scheduler:
Good:
Once again, their product is looking mighty fine. This group is on track to win "project of the year", in my opinion. Their tool is clearly useful, has an easy interface, and has a clear market. Hell, the people in the class would probably use this thing if it were to stick around. It definitely seems to beat the existing MyUNM facilities. The idea raised about asking the audience for classes to add is very worthwhile.
Not so good:
Their presentation improved, but they could still use more rehearsal; sometimes it seemed like they weren't clear on where to go next. Overall, I found the presentation to be pretty strong though.
G.E.R.A:
Good:
Ben gave a stronger speech this time. He was pretty organized and to the point, without really looking back at his slides for reference (something I personally need to work on). One thing I really liked is how Justin was following along with Ben's talk and updating the powerpoint presentation in the background without being asked. I'd like to implement something similar for our next presentation. Their demo went pretty well overall and the site looks good.
Not so good:
The fumble by Ben, of course, but it wasn't such a huge deal. I do agree with Ackley that another member of the group (probably Justin) should have tried to provide an assist there. I also agree with one of the class members that the demo should involve completion of some kind of mission, as it's the core unit of work for the application.
Automaton:
Good:
Game looks freakin sweet. Animations and color scheme on it are vivid and engaging. Presentation was better organized this time around.
Not so good:
I think they really, really need to take the intro to the game to a more basic level. They kind of just jump in and say "there's all kinds of buttons and stuff here" and describe a small subset of them. I think it leaves the audience confused about the game, even though we're computer scientists (the subject the game is supposed to teach). I think it would be wise to leave out the more complicated puzzles and instead do a very thorough puzzle that explains each piece of the solution and it's function. I guess it's late for this, but I also think it would be a lot less overwhelming to new players if many/most of the buttons are disabled or made invisible in the early puzzles.
Visual Scheduler:
Good:
Once again, their product is looking mighty fine. This group is on track to win "project of the year", in my opinion. Their tool is clearly useful, has an easy interface, and has a clear market. Hell, the people in the class would probably use this thing if it were to stick around. It definitely seems to beat the existing MyUNM facilities. The idea raised about asking the audience for classes to add is very worthwhile.
Not so good:
Their presentation improved, but they could still use more rehearsal; sometimes it seemed like they weren't clear on where to go next. Overall, I found the presentation to be pretty strong though.
G.E.R.A:
Good:
Ben gave a stronger speech this time. He was pretty organized and to the point, without really looking back at his slides for reference (something I personally need to work on). One thing I really liked is how Justin was following along with Ben's talk and updating the powerpoint presentation in the background without being asked. I'd like to implement something similar for our next presentation. Their demo went pretty well overall and the site looks good.
Not so good:
The fumble by Ben, of course, but it wasn't such a huge deal. I do agree with Ackley that another member of the group (probably Justin) should have tried to provide an assist there. I also agree with one of the class members that the demo should involve completion of some kind of mission, as it's the core unit of work for the application.
Wednesday, April 23, 2014
Reaction to 'leaders only' client meeting
It wasn't so much as a meeting as it was an interview.
I had thought that I was going to be seeing both Nikan and Ackley at the same time; not sure why I thought that, since the time slots were unchanged (and thus they could only schedule one at a time). There were a set of questions asked of me, which I expected. Some were about the project timeline and how closely it was followed; having looked at the original team timeline recently, I was pleased to see we actually were in sync with it pretty well. Others were about the team dynamics; overall, I've been quite happy with my team and the work they do. And yet other questions were about my experience as a leader and what I would do differently. I think my main thought on the last one was that I should have kept better tabs on my team members' assigned tasks and how they were being implemented to avoid ambiguity, confusion, or stalling. I do think that overall I've been a pretty good team leader and I'd like to think my group is happy with my performance.
I'm now wondering what the last two class sessions will look like (Monday after next and the one following). Are we going to do more group presentations? I would hope not. Are we going to have lectures like when the class began? My best guess is that were going to have lectures/discussions about the experience of the class or something like that, but who knows (except Ackley, I guess).
I had thought that I was going to be seeing both Nikan and Ackley at the same time; not sure why I thought that, since the time slots were unchanged (and thus they could only schedule one at a time). There were a set of questions asked of me, which I expected. Some were about the project timeline and how closely it was followed; having looked at the original team timeline recently, I was pleased to see we actually were in sync with it pretty well. Others were about the team dynamics; overall, I've been quite happy with my team and the work they do. And yet other questions were about my experience as a leader and what I would do differently. I think my main thought on the last one was that I should have kept better tabs on my team members' assigned tasks and how they were being implemented to avoid ambiguity, confusion, or stalling. I do think that overall I've been a pretty good team leader and I'd like to think my group is happy with my performance.
I'm now wondering what the last two class sessions will look like (Monday after next and the one following). Are we going to do more group presentations? I would hope not. Are we going to have lectures like when the class began? My best guess is that were going to have lectures/discussions about the experience of the class or something like that, but who knows (except Ackley, I guess).
Monday, April 21, 2014
Reflection on the presentations today
I think we did really well today. When it was first announced a week ago that we would be doing the presentations again next week, I wasn't quite sure what we should change for the next one. Overall, we received pretty good feedback from both the students and Ackley. But clearly, as shown by today, there was room for improvement.
One thing that I think made today's a lot better was our use of Prezi rather than PowerPoint. This made the presentation more visually appealing, and having a few more slides really helped me to stay on track, I think. It was only a few days ago that I decided both me and Alan should have speaking roles in the presentation. I wanted to change the demo so that there was kind of a "user-version" (the one I gave), which just showed how the application functions in normal use. Alan then gave the "backend-version", which gave more in-depth info and demonstration of some of the behind-the-scenes intelligent choices the application makes. I think this kind of two demo approach really improved how we got our message across. When done this way, the audience gets to see both of whats above and under the covers. Alan did a great job explaining the graph search we use and it's purpose, I thought. There were some questions about other stuff we could have added to the presentation; I would like to add more stuff, but don't think we can really afford to do so with a 9 minute hard limit. I kind of wish that limit would get extended to something like 13-15 minutes. Perhaps it will be a little more forgiving for the final presentation since we have like 2 hours (rather than 100 minutes for 6 groups).
I think the other groups I saw today also improved. I really liked PowderAde's presentation. Kishore did a super good job at explaining similar apps, what they do, and what they don't do that PowderAde does. The style of his presentation was spot-on, I thought; kind of snarky, but in a good, business-shark kind of way. David Strawn was suggesting that we could do something similar by showing what your average car repair online forum looks like (they're pretty hideous), as it's about the only thing we could compare our application to. After all, part of the inspiration for this project was the belief that car forums are very useful for all of the communal car history knowledge they collect (common causes of certain problems on specific cars), but that their knowledge base is vague and hard to quantify.
One thing that I think made today's a lot better was our use of Prezi rather than PowerPoint. This made the presentation more visually appealing, and having a few more slides really helped me to stay on track, I think. It was only a few days ago that I decided both me and Alan should have speaking roles in the presentation. I wanted to change the demo so that there was kind of a "user-version" (the one I gave), which just showed how the application functions in normal use. Alan then gave the "backend-version", which gave more in-depth info and demonstration of some of the behind-the-scenes intelligent choices the application makes. I think this kind of two demo approach really improved how we got our message across. When done this way, the audience gets to see both of whats above and under the covers. Alan did a great job explaining the graph search we use and it's purpose, I thought. There were some questions about other stuff we could have added to the presentation; I would like to add more stuff, but don't think we can really afford to do so with a 9 minute hard limit. I kind of wish that limit would get extended to something like 13-15 minutes. Perhaps it will be a little more forgiving for the final presentation since we have like 2 hours (rather than 100 minutes for 6 groups).
I think the other groups I saw today also improved. I really liked PowderAde's presentation. Kishore did a super good job at explaining similar apps, what they do, and what they don't do that PowderAde does. The style of his presentation was spot-on, I thought; kind of snarky, but in a good, business-shark kind of way. David Strawn was suggesting that we could do something similar by showing what your average car repair online forum looks like (they're pretty hideous), as it's about the only thing we could compare our application to. After all, part of the inspiration for this project was the belief that car forums are very useful for all of the communal car history knowledge they collect (common causes of certain problems on specific cars), but that their knowledge base is vague and hard to quantify.
Saturday, April 19, 2014
Presentation plans, project next steps
I'm hoping the next project pitch will be noticeably better than the first. To this end, we are going to use Prezi (which is pretty freakin sweet) rather than plain 'ol PowerPoint. Our demo is now a 2-man operation: I will run through a diagnostic as a user (no graph display or anything on the side, just answering questions like normal), then Alan is going to use a combination of the program and a Prezi show to show how his greedy graph search makes intelligent choices. Overall, I think our presentation is going to be more smooth and interesting with the use of Prezi as a guide in the background. I also think it's going to help me stay on point and get all of my points across.
On the project side, we're chugging along, but I'm growing more concerned about the amount of stuff we're slated to do before projects' end. We have user logins, but need to add security to them; also the actual functionality of user accounts (such as saving the location of a user in a traversal) is not implemented. We also said we are going to add a mechanism for users to add comments to QuestionStates; I have written the storage backend for that, but the UI has not been written (it has been started). We still do our development and demos running locally, and I'm getting worried that a deployed version of the site will have unforeseen issues. We have deployed and ran it before, but not steadily. I think these things are all going to work out, but I guess this is one of those parts of the process where the pressure and stress builds.
On the project side, we're chugging along, but I'm growing more concerned about the amount of stuff we're slated to do before projects' end. We have user logins, but need to add security to them; also the actual functionality of user accounts (such as saving the location of a user in a traversal) is not implemented. We also said we are going to add a mechanism for users to add comments to QuestionStates; I have written the storage backend for that, but the UI has not been written (it has been started). We still do our development and demos running locally, and I'm getting worried that a deployed version of the site will have unforeseen issues. We have deployed and ran it before, but not steadily. I think these things are all going to work out, but I guess this is one of those parts of the process where the pressure and stress builds.
Subscribe to:
Posts (Atom)