Taking a Page from the Programming Competitions

Having done a few programming competitions, I know firsthand how it's important when developing software solutions that the developer utilizes a sound approach. A lot of times a brute force approach will suffice, but issues arise when the software is put through the torture test of a large set of data.

In a university setting, Computer Science students are asked to come up with solutions for fairly trivial problems, at least in my experience. Coming up with the first 50 prime numbers isn't that challenging. Coming up with the first 500 or 5,000 might be more difficult. The first 50 primes might take seconds, if that. But try your code with an order of magnitude larger of a value and you might sit. With as powerful as even the cheapest machines are these days, sitting for more than 10 seconds, depending on your computation, might suggest that your approach is poorly designed or executed.

In my program, many of the projects are one-off assignments where the goal is to do X objective. Students have generally been punished, grade-wise, for uncommented code, but that has been the extent of the requirements in most cases. A brute force approach will work most times, but the code isn't well designed.

A possible solution to this is to treat the assignments more like those problems assigned at programming competitions: use a large, varied set of data when computations are being performed, and require a reasonable amount of time to finish the computation. Build a decent approach and your computation is done lickity split, but attempt to do things in a brute force manner and you just might sit and wait for seconds, minutes, or hours.

There are few things more satisfying in this discipline than coming up with a great solution for a problem that has  given you fits. I've found a good resource in the Project Euler questions. Working on problems that require a good approach gets you thinking about how to keep your algorithms lean, and it'll help you know the limitations of the language you're working in (i.e. limitations with using integers vs. floats vs. longs, rounding errors, etc.)

TechPoint Innovation Summit Overview

Ball State had a series of booths at the TechPoint Innovation Summit to showcase some technologies and student-led projects. Morgan's Raid was featured, and I and another student involved in the game's development were there to answer any questions passerbys might have.

Overall, we received a lot of positive feedback. Those people who stopped were interested and impressed (or at least they pretended to be) with our work. Even the fellow Ball State-related individuals seemed impressed and could understand how much work went into it.

The crowd at the event was overwhelmingly business-folk, which was perfectly fine. Not everyone was interested in our work, which is understandable. I am, however, glad that I took some advice from someone and suited up. There were plenty of potential employers on-hand, and I would rather err on the side of business attire than on casual, but I'll talk more on potential employers in a moment.

My colleague and I didn't get a chance to hear many of the talks/presentations other than the one directly after lunch (speaking of lunch - it was fantastic!). We were pretty busy chatting with the folk that came by our booth.

As far as potential employers, there were the expected Indianapolis companies, Interactive Intelligence, ExactTarget, etc. Anacore had their Synthesis technology on-hand, and the demonstration was impressive. It looked very fluid, very easy to use.




There were plenty of other companies that my partner in crime and I spoke with, and I'm glad that I went. Even if I don't land a job from any of my leads, getting out there and speaking to professionals is a worthwhile experience. It definitely eased some of my anxieties, and I'm thankful to be entering into a field that appears to be very healthy, despite an uncertain business world.

Whirlwind

It seems I have reached the point in the semester in which everything comes due and everything occurs. Hopefully I've navigated it well enough to get through this semester with all of my hair. Time will tell.

I never summed up my thoughts on the ACM programming competition, which shows how much I prepared for it: very little. I'm disappointed that my schedule ratcheted up from "slightly busy" to "incredibly busy" at seemingly the worst possible moment, but such is life.

The competition itself went decently. Our team performed acceptably, and I'm confident that the majority of our issues stemmed from all of us being plain-old too busy to prepare. The skill in these competitions is (quickly) seeing the mathematical question within the prompt paragraph(s). That and I/O. After the competition at Huntington University over a month ago, my team was pretty prepared for any potential I/O hiccups.

My teammates and I were not aware that we would not be using Eclipse. It wasn't an unreasonable request by the competition operators to not allow us to, we just hadn't read the fine print to see that we would be, basically, using notepad and compiling via command line. This isn't a difficult task, but by never having done it we were  more than a little frazzled when we didn't see our most familiar IDE. After a quick "Hello World!" introduction to our software, we were back in business.

The questions for the competition were reasonably harder. The competition itself was interesting because every team received a balloon (balloons are the competitions "theme", if it were to have one) whenever they achieved a correct answer. By the midpoint of the competition, our team had no balloon (because we had no correct answers) which took a fun thing (receiving a balloon) and turned it into a sad, depressing thing. We managed to get a single correct answer and were in the process of getting another correct before the competition ended. Bummer, I still want my balloon! It's an interesting thing to provide a resource, make it scarce, and then see how people will be excited and motivated just by the idea of receiving that thing.

Overall, it was a lot of fun. I obviously wished I had invested a bit more time to prepare, but, if it wasn't blazingly clear: my life is quite busy. I would highly recommend any undergraduate student to take part in a similar event. It may not make you a better professional programmer, but they make you think critically about a problem. They force you to come up with a solution, which can expose some shortcomings in your own thought process. An example: I've been interested with the Sieve of Erastosthenes, which comes up with the number of primes up to a number n more elegantly a brute force approach. A problem (Question D of the pdf in the previous paragraph) during the competition required us to check a large set of numbers to see if they had a certain mathematical quality. Our group had a lot of back and forth discussion about whether we could compute a master list of numbers we would look for, and save them in an array or list. Then, we could check the input to see if the number was in our collection. A member of our team took the stance that it could not work. We talked it out, tried a different strategy, and then came back to my idea (it was one of the few good ones I had that day!) and voila! It worked! Our initial approach took far too long to compute the answer, so thinking of the Sieve helped me develop a better strategy. Sometimes you can get away with brute force, but some questions expose how poor of a choice that really is.


I wish I had another year to compete in these kinds of competitions, but, barring any catastrophic events, I'll be ineligible this May when I graduate. Darn!

I'm really looking forward to the spring, so I'm having trouble keeping my eye on the prize --- the prize being this semester as a whole ending well. Our group for the spring met at the Kitselman Center and discussed some preliminary ideas about what we want to work on. The center itself is a great old building. I was a little disappointed that it didn't have more wide-open spaces, large rooms that could accommodate the entire team easily. But my concerns melted away when I saw the attic! It's a large, open room that could easily hold all of us in a work environment. My jaw might have hit the floor when we walked in. I could easily see us modifying it and having a stellar studio setting, if we can successfully reserve the room. Exciting stuff, and I'm looking forward to wrapping up this semester and getting a chance to work with some great people!

My Review of 97 Things Every Programmer Should Know

A month or so ago, my wife and I were glancing through the local library. I, naturally, gravitated toward the tech section to see what they had to offer. There were some behemoth books, including Java In a Nutshell, which appeared to be about 8 inches in diameter.

I continued to work my way through the iOS books, the For Dummies titles, until a small, purple colored book caught my eye. The book was titled 97 Things Every Programmer Should Know. It's billed as the "Collective Wisdom from the Experts", and I found that to generally be true.

The book is arranged in very tiny gulps. Each topic has a separate author and spans all of 2 pages. It's a very approachable read, and it's one that you can safely pick up for 20 minutes and set down for a week.

The concepts are mid-range, technology-wise. You'll get a few code examples and references to specific hardware/software, but I never felt that the concepts were far over my head.

The authors seem to be experts or, at the very least, professionals with years of experience. The only one I recognized by name was Robert Martin. Over the duration of each article, I grew to trust each author's advice.

Generally, I knew 90% of what I read, which probably suggests good things about me. The big thing that I'll take away from this book is the idea of thinking of the opposite side of the work equation when I'm coding. Meaning I should try to think of the user, the tester, the manager when I'm working. I don't have a lot of experience with Quality Assurance testers, but I understand their role and I'm better equipped to work with them having read this.

Another concept that came up in a few different ways was to continue learning. Several of the authors recommended learning new programming languages regularly, reading the humanities, or learning other spoken languages. Communication is obviously pivotal when it comes to programming, and the advice in this book made that much very clear.




In the nugget "Pair Program and Feel the Flow" I enjoyed this particular part:
(By Gudny Hauknes, Ann Katrin Gagnat, and Kari Røssland)

Reduce the "truck factor": It's a slightly morbid thought experiment, but how many of your team members would have to be hit by a truck before the team became unable to complete the final deliverable? In other words, how dependent is your delivery on certain team members? Is knowledge privileged or shared? If you have been rotating tasks among pairs, there is always someone else who has the knowledge and can complete the work. Your team's flow is not as affected by the "truck factor."

Robert Martin had this insight to share:

What is a professional programmer?

The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others.

• If you are a professional, then you are responsible for your own career. You are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up-to-date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: They promise to pay you, and you promise to do a good job.

• Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to findnothing because they don't release their code until they've thoroughly tested it. Of course QA will find some problems, because no one is perfect. But as professionals our attitude must be that we will leave nothing for QA to find.

• Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help each other, teach each other, learn from each other, and even cover for each other when necessary. When one team-mate falls down, the others step in, knowing that one day they'll be the ones to need cover.

• Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue tracking database are tragedies of carelessness. Indeed, in most projects the very need for an issue tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them.

• Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, ever rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you. This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say: "I'll go back and fix this later?" Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism?

Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right. 

Here are a few of the topics that I found interesting, but in consideration for keeping this short, I'll just link directly to them:
Comment Only What the Code Cannot Say by Kevlin Henney
Continuous Learning by Clint Shank
Learn to Say "Hello, World" by Thomas Guest
Read Code by Karianne Berg
Ubuntu Coding for Your Friends by Aslam Khan
WET Dilutes Performance Bottlenecks by Kirk Pepperdine


And a list of all of the contributions in the book:

97 Things Contributions

Overall, I enjoyed the book. I took a while to read through it since I had a lot of things going on, but the book is cut up into small enough portions that anyone could read for 10 minutes and get something out of it. I'd especially recommend it to junior or senior undergrads. There were a lot of great concepts, but even if the reader knew them beforehand (as I mostly did) the book serves as a great motivator.

CCSC: Programming Competition Thoughts

Last weekend, several CS students from Ball State traveled to Huntington University, in Huntington, Indiana for the Consortium for Computing Sciences in College. We listened to several talks on various topics relating to CS. We also presented on our experience with Scrum and Agile, in addition to the Morgan's Raid project. Our topics were well received, and the team as a whole had a great deal of fun.

In addition to the talks and presentations, we six students also participated in the programming competition, in groups of three. No one on my team (myself included) had ever done a programming competition before, so it was a bit of a change from the usual. The other BSU team had a few members who had been before, and it showed. They ended up placing 3rd out of 16 teams, with our team placing 8th.

I wasn't upset with our showing, and I was happy that the other BSU squad did well. My team had slight issues with some basic parsing that we probably shouldn't have, which leads me to a few thoughts on the event:


Parsing, Parsing, Parsing
    All of the problems required the teams to parse data that was input by the judges. There was some confusion as to what the end of document character was. If I was going to study one thing to prepare again, it would be basic I/O.

Divide and Conquer
    Our team developed a strategy in the midst of the chaos. One member had a good hold on one of the problems, so we turned the keyboard and monitor to him and let him run. Myself and the third remaining member turned our collective attention to another problem. We ended up running out of time, but this approach seemed to work. I worry about putting a lot of faith in one person understanding something. If they end up faltering, that's a lot of wasted time.

Three Heads Are Worse Than Two
   I'm used to doing pair-programming, so doing trio-programming was strange. We weren't sure how to divide the work. We had a single machine and a single (very small) monitor to share. We made use of extra desk space and spare paper to write out code by hand. If I had to do it over again, I'd suggest having the three of us look at all of the problems, decide which ones are easiest, and work through them in that order - splitting off and working in pairs when necessary.



I had a lot of fun, and I look forward to doing the ACM International Collegiate Programming Contest in less than a month. It'll be a bit more difficult, so I'm working through some Project Euler problems to help prepare. I'll be sure to chronicle the events leading up to the contest.

CCSC: Quick Thoughts

The Ball State crew got back this afternoon from the Consortium of Computing Science in Colleges Midwest Conference, which took place at Huntington University. I'll probably take some time to think of some larger ideas, but I wanted to jot down a few thoughts and reactions before I retired for the day.

Overall, I had a lot of fun. The group we went with was interesting and quirky, so the conversation was always chuckleworthy.

Four of us from the Morgan's Raid project presented on Scrum and demoed Morgan's Raid itself. The feedback was very positive, and those that came to see our poster/presentation asked great questions. It's harder to explain something to someone else than it is to think about it yourself, so it was a good exercise.

The Programming Competition was fun, too. My group of three had never participated in anything like this before, so we aimed to take it seriously but have fun. I was a little disappointed with our results(2 successfully completed problems). The winning team had 6, and the other BSU team had 5, I believe, placing them 3rd. I was happy to hear that they placed in the competition.

My team was a few minutes away from getting at least two more problems submitted. Could've, would've, should've I guess, but after discussing the whole competition there was mention of going to another, larger competition in November. My guess is that we'll try to do it. Travelling is fun, and four out of the six of us who traveled this weekend will be graduating next May, so we're all trying to get as much out of the time we have left. We also got to work and socialize with two of the other BSU CS students who will be involved with the Spring Virginia Ball Center project. I hadn't really met them until this trip and they seem like good fellas, so I'm looking forward to things a bit more than I was (which was a lot already).

Huntington University had some great architecture and a nice campus. While I wish I had attended last year, I am happy that I had another chance to experience it. I'd highly recommend attending it as an undergrad.

I'll look at the Programming Competition in my next post.

CCSC Midwest Conference

The Consortium for Computing Science in Colleges is having their Midwest conference at Huntington University next weekend, up near Ft Wayne. During the conference there will be a few presentation sessions, several talks on various topics, and a programming competition. I've never attended, so I'm paraphrasing their website. Somewhere along the way I made it a goal of mine to participate in the programming competition. I've had a few friends who did it and it sounded like a blast.

I'm happy that the four of us leftover from the Morgan's Raid spring team were able to come together and get the paperwork in on-time to present on not one but two topics. We'll be presenting/demoing Morgan's Raid. We also will be submitting a competition poster about our experience with Scrum as undergrads. After writing the abstract, I'm not looking forward to making a scholarly poster. Another reason why I wouldn't want to be an educator: scholarly writing.

We'll see how the programming competition, the presentations, and the demo shake out, but it should be a great time. I haven't worked with two of the guys going with us, but the other five of us have a great working relationship, and it's always fun to get to meet other people from your field.

SCRUM for Two

The Digital Archaeology Simulation project is still alive. If you're unfamiliar with it, it was a 5 week course this past summer that attempted to create a video game geared at 4th graders which realistically depicts the anthropological and archaeological process. It was quite the courageous endeavor, as starting something like this and expecting to finish it completely in 5 weeks is borderline insane. So with that in mind, we set out to complete the guts of the game, and complete them we (mostly) did.

A fellow member in the project and myself are finishing things up(applying the shiny graphics) by working with a few artists, but it's proving to be quite difficult. After having SCRUM guiding us (and some stellar Product Owners), we're now on our own. We both have a lives and other obligations/family outside of schoolwork, so finding time to work on this is proving to be challenging.

I mentioned that we were guided by SCRUM. I really miss it. I don't know how to translate standup meetings, the retrospective meetings, the product backlog, all down to a level that makes sense for two people. We just don't need the daily standups, but the standups definitely helped me personally to stay motivated. Maybe we need them more than I realized. If they last a minute, but that minute saves hours, then it's worth it in my book.

However, not having a strong product backlog might be the biggest issue. Two-player development may not need the hand holding that a large dev team might, but having something to look at and know where you're headed next is invaluable. We could get away with not having daily standups, but a well-maintained backlog would be a game-changer.

The biggest reason we don't have a lot of this nailed down is because we don't have a set time and place to meet and work. Our schedules are too different this semester to sit down daily. Working on this project this past summer, colocation was a given. In the spring during the Morgan's Raid project development, we had a lot of success mainly because of this time and place that was established and well-structured through the course.

This past week we both sat down and worked on a quick backlog, just to give us some bearings. We also received some graphics which we had been waiting on, allowing us to get them in the game. I've said it before, but it still blows me away to see a game take shape right around me. In our case, it really changes the way the game feels.

I feel that we're on the cusp of wrapping up the brunt of the pre-alpha work and we're both excited to get things into the hands of testers. Here's to continuing our progress...one foot in front of the other.

An Update On Things

It's been over a month since I last blogged, which is longer than I meant. Needless to say I've been busy.

The biggest of my tasks involved our(my wife and I) move from Muncie to Fishers. Meaning I will have to commute every day to class for the next 9 months. Quite a bummer, but we decided it was easier for her (being the sole bread-winner for the time being) to live closer to her work.

I also started back in with classes this past week. I'm excited for a lot of things about school this semester. This will be the last batch of classroom classes that I'll be taking, as well as the last on-campus classes I'll be taking. In the spring, as I've blogged about, I'll be taking part in a Virginia Ball Center project about the Underground Railroad. It'll take place off-campus, so this is sort of the beginning of the end.

My classes won't be too challenging, I don't think. I'm finishing up a couple requirements: a statistics class, a course on Theory of Computation, a 3D Graphics class, and finally an independent study where I'll be doing some Kinect development.

I'm also planning on attending CCSC programming competition and potentially presenting on something.

I'm enjoying the 2 hours of commuting every day as well as anyone can. I'm looking into some books on tape, since radio gets repetitive quickly. Also, my automobile's A/C went out yesterday, so lets pray for cool weather(!).

My wife and I are really enjoying the area we moved to. The apartment complex is quite a bit nicer than where we lived in Muncie. They also have a pool, a (small) workout facility, and an indoor (carpeted, whaa?) half-court basketball court. My better half has had a bit of time off until she starts working, so she's been enjoying some R&R while I'm away in Muncie.

This past weekend we checked out the local library and we were pleased. They have a lot of books (surprise!), so we were both able to check out something that interested us. I stumbled upon the technical books, so I picked up 97 Things Every Programmer Should Know. It's a decently short book (< 250 pgs), and each "thing" is only 2 pages long. My instincts say that lists of important concepts like this aren't usually objective, so you're taking a risk that the author knows what they're talking about. In this case, the "things" are written by a slew of industry experts. I recognized a few names, so I thought I'd give it a whirl. It's proven to be a good book to pick up for 20 minutes and set down.

So far, I've known just about everything I've read. This is comforting. Sometimes I don't quite know the technical terms the author(s) use, but I know the concepts once they explain them. The fact that I know the majority of what I'm reading is a testament to the education I've received, which I've realized that (like a lot of things in life) it's really what you put into it. If you go to class and that's it, I don't think it'll completely prepare you for the work that awaits you. I've been fortunate to bump into some great people and situations, and I've learned a lot from these experiences.

We'll see how my classes go. I'll definitely blog about the programming competition, as well as the Kinect development if it gets interesting (which I think and hope it will).

Archaeology Simulation Assessment

The end of this past week saw the Digital Archaeology Project reach it's scheduled ending date. The team worked for 5 weeks on developing a digital, educational experience that was appropriate for a 4th grade level of student. This post will focus on the positives and negatives of the project.

Background On the Project
The team on this project consisted of eight students, four CS students and four Anthropology/History students, as well as three faculty advisors. The focus of the project was to create an experience that accurately depicted the archaeology process. The player would discover an artifact through digging, categorize the artifact, explore the house for more artifacts, research their findings in the library, all the while opening up interpretations. Their findings and research allowed them to make claims about the people who inhabited the land.

Our goals were pretty lofty considering that we had zero starting out. Knowing this, our advisors realized that we wouldn't be able to give the game the polish it would need. Therefore, our team of eight students would be in charge of the game design and initial development of the software. We wouldn't put the polishing touches on it, but we would have the game working completely by the end of our project. Then we would hand our product off to another on-campus organization to polish it up and prettify it.

Results
At the end of our 5 week period, we have a game. It's very, very raw, but it is a game. The data is there, the game flow is there. It's just ugly. It's all programmer and placeholder art, which is notoriously hideous, but it did it's job.

We didn't have to change our goals to meet our production rate, which is good. However, our goals were very, very aggressive - perhaps too aggressive. We weren't in a place where we could playtest a prototype with actual 4th graders, so we're carrying quite a bit of risk still. I say 'still' because the game can still be changed, once what's there is beautified. There are plans to playtest it and tweak what needs to be tweaked.



In the vein of SCRUM, I'll lay out areas that were successful and those that needed more work.

Positives

• Diverse team 
•  we had a very diverse team, but we were able to find a group identity and work well together.
• SCRUM 
• we used what I would call SCRUM lite, but the parts of it that we did use worked well. The group took to it quickly.
• New technology
• the tech team (the CS students) picked up C# and Unity3D quickly. It was fun to work with new software.
• Built off of past success
• Speaking from a tech team perspective, the Morgan's Raid experience was helpful in this project.
• Empowered team
• the faculty advisors did a good job of directing us initially, but by the end, the students were making the decisions, even the big ones

Negatives

• Pressure of lofty of goals
• while we were successful, had our goals been smaller we could've polished the game mechanics more
• Feelings of being unfulfilled
• handing off a project to someone else to finish isn't enjoyable. You get protective of a project and to see it go before it's done is a little saddening, even if it's necessary.
• Empowered team 
• having the students making the big decisions led to moments where the decision took longer than it might've, had an advisor just dictated what to do.
• Short deadlines
• having such a short timeframe for a big project led to some software debt. At the time, it made more sense to keep implementing new features instead of refactoring. Also, our Product Owners didn't dictate that they wanted code refactored, so I'm not sure who should've spoken up. 

Conclusions
After everything is said and done, the project was a success. We set out to create something educational while still being accurate and we did that. Things weren't perfect, but I feel that we (the four CS students and two of the advisors who have worked together before) are perfecting our process.

I'm glad to have taken part in the project and I would encourage others to look for similar Immersive Learning opportunities. While these projects are great learning opportunities, one problem with Immersive Learning is that not every major supports it as well as they could. I know that art students in particular have trouble finding room in their schedules to accommodate it. If I were on a tighter schedule I may not have had time for this project.

I'll use this experience, and the Morgan's Raid experience, to make the most of this Spring, where I'll be working on a project at the  Virginia Ball Center. I'm really excited about this opportunity, and I'm sure I'll blog about it in the coming months. I'm not entirely done with the Archaeology Project, as I'll likely be doing some additional development on it in the next few weeks, but I'm proud of what we were able to accomplish.

Blog Update

I noticed a few weeks back that whenever I previewed my blog things tended to lag out a bit. Scrolling up or down was very slow. Other Blogger blogs that I follow didn't, so I figured it was my background choice.

Recently I changed the background color to a solid orange. I don't really have a favorite color, but orange is one that I tend to pick when pressured. This change of backgrounds seems to have fixed it, so I'm happy.

As I was working on switching the background color, I noticed I had 4 or 5 blog posts started and saved in the backend. I'm planning on going through them and knocking out a few ideas that have been floating around my head. I started the posts and titled them as a reminder, but I've been too busy to do anything with them. The Digital Archaeology Project I've been working on for the past 5 weeks came to an end this week, so I have plans to write a summary about the experience while the memories are still fresh. I learned quite a bit so I'm excited to try to form some conclusions about how things shook out.

Unity3D So Far

We're about a week and a half away from our scheduled finish date for the Digital Archaeology Project. It's a little unnerving, but I'm not too worried.

The technical team decided to work with the Unity Game Development Tool, and so far it's pretty cool, albeit a bit overwhelming. It reminds me of Adobe Photoshop, but my past experience with entity systems and components has definitely helped.

I'm especially thankful for a nice, well thought out API site that Unity has implemented. It comes with code examples for all 3 of the supported scripting languages ("JavaScript", C#, and Boo).

Unity has many features, and a ton of preloaded components to add to your game objects. It's shockingly simple to create a physics-enabled environment. The power of Unity comes in the in the ability to run the game and modify values real-time. It makes tweaking things like the UI a cinch, allowing the developer to get back to doing things that are more deserving of their attention.

I'm at a near impasse at the moment, so I decided to write about my experience with Unity so far. Working with it has been challenging, as I had a few initial tasks not related to Unity or programming. The other three CS students on the project got a bit of a head start over me, so they're a little more comfortable with C# and Unity than I am. Note: my programming experience has been almost completely isolated to Java. I've done a few projects in C#, LISP, and Prolog. I've taken to C# fairly quickly, as it is pretty close to Java.

As I mentioned, Unity uses components pretty heavily. I've looked back to the Morgan's Raid source code a bit to get a comparable idea of what things are trying to do in Unity, which has been pretty helpful. Some of my difficulties now remind me of last fall, when the Morgan's Raid source hierarchy was, to put it bluntly, a mess. It's hard to get my bearings when the folders are such a mess. In the next week and a half we'll have to clear up the Digital Archaeology source hierarchy (among other things) as we prepare to hand the core game off to another university group to polish and apply the visuals. A lot remains to be done, but Unity affords us the biggest chance to succeed. I am glad that we chose to work with it, and I'm happy the developer license will be mine (hopefully) to explore with over the next several months.

This is a bit premature for a review of Unity, so take it as more of a preview. I'll try to sum up my thoughts on Unity as well as the Digital Archaeology Project in a future post.

Communicating and Google Reader

Using Google Reader has been an interesting, productive exercise for me over the last couple months. One of my professors mentioned it and I thought I would give it a whirl. It's an interesting tool, as it's relatively worthless out of the box. Start following a few people and subscribe to a few websites, however, and it transforms. Every day I wake up and several new items are in my new item list. Personally, I try to keep my feeds clear by at least reading a little bit of each post  (so they read 0 and not 1,251). If I don't find them interesting, I skip the post and mark it as read. There is always something that I can be reading to entertain and/or better my self, so to have that convenience in my pocket is an awesome thing...

I subscribed to an already existing set of feeds called Agile. There are several which Google have set up already, but this one deals with, well, Agile topics within software development. Some of it is a bit too self-serving for my tastes(people blogging about certifications and workshops, things that may matter to people other than myself). However, a few blogs that I've added to my subscription have been diamonds in the rough.

One post by Jeff Atwood really hit home with me. In his discussion on How to Write Without Writing, he gave me another reason to do what I'm doing in this blog. To summarize part of his post, he says that blogging is a great way to better one's communication skills. Atwood says that bettering these skills will make you a more proficient programmer. The more I work in groups and on teams, the more I realize that he's absolutely right. I've seen firsthand how difficult it is to come in months after someone wrote some code and try to piece their ill-formed thoughts together. Sometimes there just aren't enough clear comments. These are the kinds of things employers will be expecting, and it'll be one of the ways they'll love you if you're good at it...at least that's what I'm hoping.

This space has been all about that, taking ideas and putting them in their clearest form(at least to me). I'm definitely not the best writer or communicator, but this is my attempt to hone these skills. It's nice to know that someone like Atwood, with all of his experience behind him, is encouraging me to blog and collect my thoughts.

Atwood's blog can be found here, http://www.codinghorror.com/blog/.

Another interesting blog I found is, http://bjk5.com/ by Ben Kamens. He's the lead dev at Khan Academy, which is deserving of its own post, but I'll save that for another time.

Using Google Reader has been a great experience. I don't have many followers, but I try to share with them only the things which I find truly interesting. There's almost a hierarchy of things which are worthy of being shared: a Google Chat status is the lowest, a Tweet would be next (if I had a Twitter account), a Facebook status after that, and finally a shared item on Reader.

Searching for Other Options

A few quick emails yesterday afternoon all but nixed using JavaFX. Apparently it doesn't work at all with Mac, and our project is attempting to be cross-platform friendly from the beginning .

For our Digital Archaeology Project, we had a few ideas as to what software to use to design it:

• Swing
• GWT
• JavaFX
• Unity3D
• Slick

Swing was quickly eliminated, as there are more powerful options in the list. Slick is what was used for the Morgan's Raid project, so we all are very familiar with it. However, it doesn't have a good solution for creating buttons and a custom interface. Those things would need to be done by hand,which is possible but difficult. So that left us with GWT, JavaFX, and Unity3D. The latter option is a 3D game engine that has some really approachable tools. The downfall is that these tools cost money and aren't very recreate-able without going in and typing things in by hand. In other words, it can't be used in other instances programmaticly, other archaeology sites would need to be redone by hand.

So with Swing and JavaFX out, the team is focusing on GWT and Unity3D this weekend. We know what Slick can do, but the other two options are relative unknowns. I have GWT all set up on my machine here at home and a free afternoon ahead of me!

Digital Archaeology Project & JavaFX: First Impressions

For the Digital Archaeology Project I am working on, the Computer Science students in the group were given the weekend task of tinkering with JavaFX. So far, things are going well!

JavaFX was described to me as a language that allows us to do some interesting animation and visual effects, all while allowing us to build off of our knowledge with Java. It seems pretty robust, but I've only looked at a few code examples. Getting it going with Eclipse was fairly simple. I followed this tutorial Oracle JavaFX Tutorial and was able to work along side it very easily.

I have some plans outside of staring at a computer monitor tonight, or else I would continue on with these tutorials, but that is where I plan to get back into it tomorrow.

I haven't mentioned it in this space, but I am working with a few other students and professors on developing a digital archaeology simulation (a game) for 4th graders. I wrote a quick summary of our work so far, which can be found here. I'm not sure how to use this space in conjunction with a class-wide, shared blog. I'd like to keep working in this realm, as it's easier to wrap all of my thoughts up onto one page. I could also post to both spaces simultaneously.

I like the progress that was made today. I feel for the non-Computer Science students with the prototyping that we've done this week. They've done a great job so far, but the process can be frustrating initially. Those of us who were around for Morgan's Raid last fall were subjected to our fair share of prototyping, and, as Dr. Gestwicki would and does say, you do it so you can throw ideas out. It really saves you time later. Looking back, I wish we had done a bit more prototyping in Morgan's Raid at times, but with this project I think the Anthropology students are getting a good experience. One of them mentioned in a reflective post that they didn't think they would be doing so much design - that they enjoyed getting to take part in it. I'm glad they will have the opportunity to give a lot of feedback. CS people tend to be min/maxers, power users, so we might be more interested in the numbers side of things. A fresh perspective could really be huge for keeping the game fun on a surface level (I made an archaeology joke!).

Ubuntu

Tonight I finally bit the bullet and tried to get a version of Linux working on my home desktop. I wasn't sure what to try, but after a bit of research I decided on Ubuntu. I don't know where my Win7 disk is (I'll get reorganized after the upcoming move), so I didn't want to do something that would upset my productivity and home internet browsing back. So with that in mind, I chose the "install it on top of Windows" option, called Wubi.

It downloaded fairly quickly and asked for a reboot. I really look forward to the day when bootups take a handful of seconds. I walked away and missed the "choose which OS to boot into" choice, so it chose Win7. I came back to my machine and instinctively logged into my Windows account.

"Wait a second..."

*sigh*

Once I rebooted again and got into Ubuntu, I had to get some drivers - one of which was for my video card. After I got that going, and rebooted, I was mildly blown away at the beauty of the interface. The menus were crisp, the buttons were well bright and cheery. I halfway imagined the Matrix; my mind had anticipated something much more unapproachable than what was actually before me.

It wasn't long before I was trying to get it to do something that I couldn't figure out - get two monitors to register (I've got them, I might as well use them!). I'm sure it's something simple, as it's probably a fairly common problem. I'll leave it for another day. I'll keep my Windows 7 install around. If I want to play a great game chances are I'll have to use that to play it, but Linux has come a long way from when I last saw it. Maybe I didn't give it a fair shake, but this time around I aim to do so.

Morgan's Raid: Spring Semester

The Spring of 2011 saw a new semester of courses for me at Ball State University. Work still needed to be done to finish up the Morgan's Raid project, and I was asked late in the Fall to continue working on it with a few other students. At the end of the Fall Semester we had a working product. It did what it was supposed to do, but it really wasn't fun. Fun is, well, kind of important. There needed to be a fun injection, and the nine students working on it in the Spring would be there to administer it.

The player chooses their raid target priorities

This post will focus on my work on finishing up the Morgan's Raid project. It was a blast to take part in and I've missed working on it this Summer. Here is my synopsis of the events that took place this Spring.

Key Differences

Several students were carried over from the Fall to continue developing Morgan's Raid. Many, many things operated differently in the Spring versus the Fall semester. The main two were: the size of the team shrunk and the introduction of a dedicated workspace. 

Nine students were kept on the project from the Fall, which is a huge drop from twenty-five. Managing twenty-five people, all working on the same source code, would be a nightmare for me, so hats off to Dr. Gestwicki for doing as good of a job as he did. The Spring experience would be much more intimate but also much more intense. With only nine of us, the pressure would definitely ramp up if we were to be successful in our goals. There were a few of us who knew each other very well, but to be successful we would need to find a group identity, a personality that we all could take part in, day-to-day. By having a dedicated space (which I will talk about in a moment) and through several group activities, we were able to really get to know one another and develop some seriously deep friendships. I wish I had had this experience at the beginning of my college career, but that is another topic. Some of the group activities we took part in were: playing Team Fortress 2 after workday ended, meeting for lunch and eating together, as well as the almost weekly boardgame night. We worked together and we played together. By the end of things, we all knew what made the other people tick. It helped that we had similar personalities and life experiences, too.

For a great article on the importance of eating together, check out this Joel Spolsky blogpost: Lunch.

Overall, the team atmosphere was there much more noticeably in the Spring than in the Fall, despite having small teams within the bigger team in the Fall. Some of this can be attributed to the dedicated workspace in the Spring, versus the twenty-five of us spreading out as needed in the Fall. It's easy to see why working in one room for nine hours a week promotes unity. In the Fall, my group would meet for "daily" standup meetings, but after that we generally went our separate ways. Very little interaction took place outside of these meetings, other than pair programming.

In addition to having a much smaller team in the Spring, our group was privileged to have a dedicated workspace. We commissioned a rarely used room that was housing some servers. We maintained a good relationship with the System Administrators, and they returned the favor by helping us arrange the room as was needed. This arrangement of the room helped greatly. The desks were set up in a way so we could see each other easily, but we weren't all facing one another. Also, the ample supply of whiteboard let us have some very productive sessions of brainstorming and design.

We were also able to have a physical SCRUM Board, which was interesting. It was interesting to have the tactile version that we could look to daily for guidance. In the Fall, we had a digital version, which I preferred. I liked being able to access the digital version from any internet access point, but the physical version had a few pluses. It was motivating and encouraging to see the tasks move, physically, throughout the week, and since we did all of our work in one room, we didn't need to access the SCRUM Board from home.

Other Differences
In the Fall, the validation process was...chaotic. People would assume they were done, when, in fact, their approach was problematic and flatout wrong. This was a huge, huge problem later on. We would eventually uncover a rat's nest of issues, with the rat king being the overhaul of the classes pertaining to time and the retrofitting of the massive InGameState. This was avoided in the Spring, almost entirely, by having the final step in task completion requiring the person to validate that item with whoever we deemed should do it (we decided this when we created the tasks from the Product Backlog). Having this validation step (and more access to our gatekeeper, of sorts) kept us from straying off the path of righteousness.

In the Spring, we also had daily access to our artist. He wasn't on-site in the Fall, so our game looked pretty mediocre at the end of the first semester. Having him there, in person, sped up the pipeline quite a bit. We could get instant feedback on whether an idea was doable, as well as give feedback to him if we needed to tweak something. I cannot think of how we could have used him on-site in the Fall, as we were kind of meandering along through development. We had direction but we lacked the perspective necessary to create something that was focused enough to warrant a ton of artwork. In the Spring, we used our little artist (who we decided was a robot, as he was quite productive) to the fullest, and having him there with us was a great experience.

One other difference between the two semesters was the set worktime in the Spring. As I mentioned, we had our "daily" standup meetings in the Fall semester, but we didn't have a set work time. In the Spring, we established a schedule where we could all meet and work for several hours. The benefits of the latter approach are obvious, so I won't spell them all out, but to summarize: having a dedicated work time three days a week was a great improvement over the Fall and enabled a lot of our successes.

Playtesting
In the Spring, we had a solid enough game to run a playtesting session with real, live(important, they must be fresh!) Indiana 4th Graders. This was a great experience for me, personally, but also for the whole team. We did two playtests at a pair of elementary schools.

The first was a school in the Indianapolis area. They were a gifted and talented class. We had a very positive experience, as the students gave us great feedback. Looking back, our game lacked focus, but the kids loved it. They went so far as to say, "It felt like we were testing Halo or something."- high praise from the students. Their feedback was especially helpful because they were used to articulating their thoughts and they had some very valid concerns.

Our experience at the second playtest was quite different than the first. We playtested at a local school here in Muncie. We benefited just as much (maybe even more) over the first playtest. Economically the two areas are very different, and this wasn't a gifted and talented class, so we knew not to expect the same reactions from the kids, which was fine. We didn't make the game with any one level of student in mind, all Indiana 4th graders should get something out of playing it.

At the first playtest, we had a very rough game, so their enthusiasm for what we were doing helped motivate us early on (this playtest took place one month into Spring development). By the second playtest, our game had came a long way, but we were drunk with power. The game was trying to do too much and this became very apparent. Following the second playtest, we really scaled back what we were doing and focused our energy into making our game do something great instead of doing several things well.

The summary screen of Morgan's Raid

Summary of the Summary
The main things I took away from the Morgan's Raid project were:

• Game design can be fun, but challenging
• Software development is what I want to do for a living
• Working in an Agile environment is very productive
• Version Control Software is absolutely necessary
• I realize I haven't mentioned this at all, but it's such a big thing that it really warrants its own post
• I love history
• Working on something one is passionate about makes the whole process much more enjoyable

This class was my introduction to Game Design, and I am by no means great at it. I struggled at times but those were the moments I learned the most. This course was also my introduction to a long-term software development project, one where I had to reread a lot of code. This really cemented the concept of writing worthwhile, optimal code. Failing to do so causes more headaches later.

Agile and SCRUM were also fun to work with. It was a little difficult to wrap my head around the concept of there being no "manager" on the project, but eventually it all clicked. I feel I have a solid understanding of SCRUM, but I still need to work on making accurate time estimates. 

Screenshot of:
Civil War Generals 2: Grant, Lee, and Sherman

Working on a history project like this reminded me of my love for American History. I loved learning about the American Civil War and the Revolutionary War in school. I remember getting excited about Civil War History through the game Civil War Generals and Civil War Generals 2: Grant, Lee, and Sherman. Looking back, it wasn't a great game, but it did something that we were trying to do with the Morgan's Raid project: entice people (in our case, Indiana 4th graders) to learn about the era by participating in a simulation. 

I've had an absolute blast working on this project. I am truly sad that development is complete, as I had a lot of fun working with a lot of inspiring people. Moreover, I am proud to have helped create something, that, with a little luck, might be another kids inspiring moment.

I am working on another educational video game this summer. Several students in the course will be blogging about the experience, which can be found here:
Digital Archaeology Project

If you would like to check out Morgan's Raid, it can be found here:
Morgan's Raid Site

My professor, Dr. Gestwicki, did a write-up about the Morgan's Raid experience,
which you can find here:
Morgan's Raid Postmortem

Screenshot of Civil War Generals taken from: www.mobygames.com.
Screenshots of Morgan's Raid taken from: https://sites.google.com/site/morgansraidgame/screenshots

Morgan's Raid: Fall Semester

General Morgan

This will be a longer post, so I will break things down a bit as I go.

Background
John Hunt Morgan was a Confederate General in the American Civil War. Against direct orders, Morgan and over 2,000 cavalry units rode through Southern Indiana and raided several towns. They carried their raid on into Ohio, where they were ultimately caught. Morgan escaped from jail, but was later killed, ironically, in a Union raid.

The goal of my Game Programming class, which took place Fall of 2010, was to capture the events that happened during Morgan's Raid, create an accurate simulation, and turn it all into a tool that 4th grade teachers could use to engage students. Historical accuracy was pivotal -as was keeping in mind what worked when 4th grade students used computers. So to keep these two things in focus, we leaned heavily on a History professor who focuses on Elementary Education, as well as a History Graduate Student, who did the majority of the legwork when research was necessary.

This post focuses on the Fall Semester of Morgan's Raid development. Having worked on the project in the Spring of 2011 as well, I had very different experiences. Both had their positives and negatives, and while I filled out a course evaluation for the university, I feel that it is important to try to summarize what I took away from both semesters of the project.


SCRUM
As mentioned in my previous post, we used SCRUM and Agile methodologies to keep our project organized. In the Fall, we utilized a shared Google Document Spreadsheet as our Product Backlog, which saved our time estimates and automated our burndown chart.

Using a publicly shared document worked well enough, but there were hiccups associated with having such a large group. We often had to spread out to different rooms/labs to have enough space to talk as a group without disrupting other groups. It would have been nice to be in one place for planning meetings, but it just wasn't possible. Needless to say, our class regularly was pretty loud during these meetings, which isn't a bad thing. In the chaos, however, sometimes a group or two would nab the more desirable tasks. One group might have been working on a certain problem and the next week another group would take a task that would be best given to the first group. The first group had a better understanding of the architecture or the package that was being used, but the latter group might quickly take it. People didn't want to create drama, so in the first few Sprints people took what they could get, as far as tasks go. It paid to quickly take a task, and in retrospect I can say that we weren't following SCRUM practices to the letter during our planning meetings.

Later in the year we moved to a larger area and developed a way of pulling the SCRUM Masters together to discuss any of these issues. However, by this time it was nearing the end of the semester and people were either pulling more than their weight or easing up. If we had had a dedicated, larger space from the get-go, some awkward situations could have been avoided.


Entity System Architecture

Our professor had a vision of using an Entity System architecture (ES). He had us read several articles as initial assignments, one being here: Evolve Your Hierarchy. I have a good understanding of ES, but if I get a part of it wrong, feel free to correct me in the comments.

To summarize it, ES is a way of creating attributes (called Components), while using Systems to modify the Components. In our application, a Component we had was "Speed", which we applied to the Entity John Hunt Morgan. Entities are made up of Components, and generally you find the Entities based on the Components they have, not by a name. Morgan had a Speed value, and the Speed System would modify that value.

Components could be applied to multiple Entities as well. This allowed us to modify many Entities at once, without making systems for each individual Entity. In our case, every road was an Entity. We had a System that would render the roads (before we baked the image into the background). Another System also made sure our GPS coordinates lined up with the coordinates for the correct town.

Using ES required us to maintain the right scope when we developed our systems. If the systems are nested too "deep" then if that logic is needed elsewhere, a messy refactoring is necessary. This way, all that is required of the dev team is to apply the component to another Entity, and voila! Fun stuff!

In order to do ES well (and this applies to Software Development in general), logic should be pulled apart when possible. There might be a good way to determine when this is necessary, but from my perspective it's more of a gut-feeling one develops. For example, if our previously mentioned Speed System class is doing much more than modifying the Speed Component, it probably needs this functionality pulled out into its own space somewhere. If changes need to be made to Speed to use it in another instance, you know exactly where to look to carry changes through to other classes. This is kind of a "duh!" idea, but it wasn't touched very well in my experiences. It's pretty easy when asked to make a project for a class to do things the quick and easy way. The only expectations are that things are commented and the requested task is fulfilled. This is by far the largest project I have worked on, so seeing why it's so important to do things this way has been game-changing for me.

Colocation and Summary
For the Morgan's Raid project, I was on the "Map" Team. At the onset, our initial tasks dealt with the Map, but after the first Sprint we weren't assigned to "Map" tasks. The three other teams had similar names, but one team decided to rename themselves.

Week in and week out, the four teams took tasks and performed them to the best of their abilities. By far, the use of the Slick 2D Game API and Entity System Architecture gave students the most trouble. Slick was difficult for the team to get used to, but once we understood it we were rolling. ES was more troublesome (even into the Spring semester for those who hadn't worked with it yet). It was easier to make bloated, redundant classes. I found it easy to wander off the path and instinctively push my code away from ES. Having someone there (our professor) to keep us on-track was very helpful. In the Fall, one-on-one time with our him was harder to come by (25 to 1, vs 8 to 1 in the Spring ). Sometimes it was frustrating, but everyone tried to be patient. Generally, we all worked following our daily Standup meetings in a lab that is dedicated to CS students. This colocation of groups was great, as any questions that might pop up could be answered by someone in the room.

Fast forwarding to the end of the semester, we had a decent, shippable product. Some core game mechanics were present, but the lack of high quality art made it difficult to envision the game being played. Several people went above and beyond the requirements (as far as invested time goes). My programming partner and I showed an interest in fixing a few errors, and Dr. Gestwicki met us a couple weekends to try to come up with a solution. Many others, not just us, pitched in (or came in on weekends) to help. This goes outside of the SCRUM scope of things, as you're supposed to allocate the necessary time, but in crunch situations sometimes drastic measures must be taken. Our efforts were successful and in order to move forward at times we had to take a step or two backward. Much less of this was needed in the Spring semester, which I attribute to having a smaller team, having more clear goals, and everyone having a much better understanding of what we were trying to accomplish. Time estimates are difficult when the project is so far from being complete.

I was very excited and nervous when I was asked to continue working on the project in the Spring. In the Fall, I really grew as a programmer. I developed some confidence and a great understanding of what it takes to work on a larger team, as well as working with a partner. I learned a few lessons in the importance of not outsmarting yourself (developing such complex systems that you end up wasting more time than you're going to save). I also experienced the pains of watching bits of code that I (and my programming partner) worked so hard on disappear. These moments were small, but valuable failures - the kinds of failures you learn from and build off of.

And I would need it in the Spring, as we more than doubled the total lines of code, while removing maaaany bloated spots of the code (hellooooo InGameState!). In one of my next posts I will sum up my experiences in the Spring on the Morgan's Raid project! I've had a blast working on this project, and coming up with a summary of lessons learned proved difficult but very beneficial.

My Introduction to SCRUM

Sometimes something comes along that you're excited about but wholly unprepared for how it will change the way you think. Last Summer, I was coming off of an unfulfilling Spring semester, but I was looking forward to the Fall session. I was scheduled to take a few classes with the bright spot on the horizon being a course on Game Programming. I think the gut reaction when people my age see a course on Game Programming is "oh man, I love video games. That sounds fun!" My reaction was probably pretty similar, but I was especially interested in the logic that drove some of my favorite titles. The class would be taught by one of the younger professors, Paul Gestwicki, who I had not had up to this point in my college career. I had heard a lot about how his courses were demanding but very rewarding.

The first day, I knew the class would be different than anything I was used to. Once we had created four socially-constructed teams(we built them based on pre-existing friendships and proximity, not on areas of expertise or ability), we went over the organizational system that we would follow. With around 25 students, all working together, we would definitely need some guidelines to adhere to.

We followed SCRUM, which, by the Wikipedia definition, is:

an iterative, incremental framework for project management often seen in agile software development. 

In plain words, SCRUM incorporates several small teams (four to six people each), with one person designated as the SCRUM Master. Their job is solely to remove impediments, obstacles that are preventing the team from achieving their goals.

The teams work in sections of time called Sprints. Ours typically lasted two weeks, with some modification when holidays would cause the Sprint to end awkwardly.

We had Product Owners, who would create goals called User Stories. These User Stories would be arranged by importance in a Product Backlog. At our Sprint Planning Meeting, which took place at the beginning of each Sprint, we took these User Stories and broke them down into manageable, achievable portions, called Tasks. For example, if the User Story was to create a dialog box for something, a few tasks might be "Create the text for the dialog", "Sketch out some placeholder art for the box", "OK the dialog with a Product Owner".

Pairs of people would volunteer for the task that they were comfortable taking. They would then give their estimate as to how long it would take to accomplish. Every pair was asked to determine their availability in the next two weeks, and volunteer a maximum amount of hours. (This is important because as a legitimate college course, we wouldn't have lectures or labs to attend, so we would need to fulfill the credit hour requirements by working)

This process may appear complicated, but the following flowchart depicts the process from beginning to end, with the goal being to deliver a shippable, high-quality product at the end of every Sprint. If a feature couldn't be finished on-time, it was renegotiated (more on this process later) and left out.

(Image courtesy of Mountain Goat Software)


Typically, time estimates were tallied up and a burndown chart was created. This chart was useful for the teams to see their task progress visually. Also, the chart was useful in retrospectively spotting hiccups in progress. For example, a snow storm might cause the team to lose a bit of production for one day, which could be seen clearly on the chart.

Here is one of our actual digital burndown charts, taken from an old spreadsheet:

The red line indicates steady progress, and the blue line represents our actual day to day progress.


SCRUM Day to Day
Throughout the sprint, "daily" stand-up meetings were held. I say "daily" because many schedules did not sync up perfectly, at least in the Fall Semester, and meetings were held every Monday, Wednesday, Friday instead. These meetings were timeboxed (at fifteen minutes), much like our Sprints, and literally everyone had to stand up. This kept meetings short and focused, with the purpose of the meeting being to inform members of the team as to your progress since your last meeting. Scrum Masters were to pay attention to mentioned impediments during this meeting.

At the conclusion of the meeting, pairs would get to work on their tasks. When the work time ended, each pair was responsible for updating their estimate on the burndown chart. Keeping the estimates up-to-date was imperative for ensuring the burndown was accurate.

If team was going to fail at meeting a deadline for a specific task, it would be renegotiated several days before the end of the Sprint. Renegotiations would take place between the task-assigned team and the Product Owner(s). Sometimes specific requirements might be lessened, but in more extreme cases the task could be dropped entirely. Obviously this is a last resort measure.


This concludes my summary of how I understand SCRUM. While there is a lot to digest here if you're unfamiliar with SCRUM, it all is important. From what I've read, our implementation of SCRUM was pretty true to the standards established by industry professionals. Overall, this development strategy and organizational process suited the project well. Both semesters of development benefited greatly by using SCRUM, but each one did so in very different ways. I'll shed some light on that when I get to the respective semesters.

In my next post, I'll talk about the game, how software development with 25 other people (college students, no less) can be difficult but rewarding, and how SCRUM and Agile methodologies made it all work.

Uno

I'm basking in the glow that is my first blog post. I've wanted a place to collect my thoughts, and I am very happy to have fulfilled a small personal goal in this creation of my own cerebral whirlpool. A Facebook status or a Tweet might have seemed a more logical place for me to outlet thoughts, but I have a different idea in mind with this space.

Too often do I think up provocative and interesting (at least to me) thoughts, but in the overly saturated digital world I find myself overwhelmed. My thoughts are, at times, fleeting. I see an interesting topic on a forum, only to pass up the opportunity for a more visceral subject. As a society, I wonder if we are at a disadvantage in this regard. Would Thomas Edison or daVinci have pushed themselves as far if they had access to lolcats or Youtube? Probably, but my point is this: it is easy to get overwhelmed and fail to think critically on a regular basis.

I'm off-topic a bit more than I had expected (hooray, my first deviation from a topic!). My goals for this space aren't very concrete, but one that I will iron out is this: I want to dwell on ideas long enough to feel confident in my findings or explanations. By pushing myself to fully explore ideas I hope to learn quite a bit, as well as brush up on my writing skills.

Here's to a new beginning!