I am currently very happy, ecstatic even; our group provided a very fine performance of our pitch presentation after all of our practice, and the results couldn't have been better. We received the 1st Place UNM CS Software Engineering Project Showcase award, bragging rights, and a $200 dollar cash prize (extremely unexpected, but a pleasant surprise). I am glad that I was able to perform my part up to par with the others to achieve this; I feel that I have redeemed myself of my poor performance on my project pitch early in the semester. We split the cash prize in such a way that Dan was able to recoup his out of pocket costs for flyer prints and image licensing: Dan got $100, and Zach, David, and I split the remaining $100. We are all on good terms and will definitely get together after this semester to have a few drinks in celebration of this achievement in light of our hard work.

I am very relieved that this semester is over after this blog post; I have already turned in both my group member evaluation and  final self-evaluation, and all of my other classes are finished. I hope that my increased effort in these last three weeks has been noticed in regards to CS 460 to better my grade. This class has been a good insight into what it is like to be a software engineer. It has also been nice to compare my experiences within CS 460 with my experiences in my internship; there are a ton of similarities. The amount of work I have had to do this semester has blown all of my past semesters' work loads out of the atmosphere; however, even with how much work this semester has demanded, I appreciate the vast amount of experience I have accrued.

I am glad that this semester is at an end, I am glad that I will (hopefully) be graduating, and I look forward to see what life brings my way.

My group and I have worked on our showcase pitch for more than 6 hours over the weekend and today. It has improved a lot during this time, and I believe that we'll be able to perform very well for tomorrow. We are covering all of the bases; an intro into the problem, why what is currently available is bad, why our web application helps solve the problem, the technology behind our web application, how we plan to generate revenue and market our web application, and demos for both the manual scheduling, and the schedule generator. I really hope that what we have prepared will be well received by the judges. Since we've had a code freeze for the last week or so, we have been able to focus on our parts as well as being able catch up on other classes; it has been insane how much time CS 460 eats into your other classes. However, with a team like ours, we've been able to keep the stress down, get what we needed implemented, and maintain the CS 460/other classes work balance, resulting in a healthy work/work balance throughout the semester (see what I did there?). I hope that Professor Ackley sees that I'm attempting to redeem myself from my poor project pitch performance and graces me with a passing grade for the class.

It's the last week of classes and I'm feeling pretty damn good, I'm essentially done with three of my classes after tomorrow (Thursday), and I have plenty of time to focus on my remaining two classes (cs460 and cs 442).

This semester has probably been one of my most difficult, mainly because of all of the group projects/homework and having a 20 hour internship doing front end web development. I was pretty down trodden with such a low projected grade for CS460, but I'm trying to make the best of it. My group and I are planning to meet tomorrow and Saturday to polish up our pitch for this coming Tuesday. I know my project pitch at the beginning of the semester was extremely poor, due to various reasons (lack of confidence/front teeth), but I feel much more confident in being able to perform to a professional standard for our final pitch. I've also been asking other members of the class how they did their self evaluations, so I hope I'll be able to create a final self evaluation that is better than my mid-semester one.

My predicament.

So... I am currently freaking out about my "mid-semester" review for my CS 460 class, much more than I was initially, after speaking with Professor Ackley after class today. I had been under the impression that he had already completed the mid semester reviews and that there was going to be additional padding of the grade after the fact... but with recent knowledge, the additional padding has already been applied to the grade... and thus, my lowest possible grade as a D+, and my highest possible grade a C+. This is really hard for me to comprehend since I usually get A's and B's, and currently have a 3.61 GPA at UNM with only my CS and Minor classes (my core classes were completed at CNM and are not included in the UNM GPA). It is even harder for me to comprehend that my projected grade is this low in a class that's grading criteria is almost entirely subjective: there was no syllabus stating how each aspect of the class would be graded besides a little fuzzy explanation on blog posts. It completely baffles me. This class, from what I can tell, is purely about experiencing a faux real world software development experience in a protected environment; anyone that has been actively attending classes and working with their group is garnering this experience, and, thus, should be passing the class with flying colors.... except, apparently not. I've attended every single lecture, I've participated in the discussion when I felt comfortable I could without getting mocked, I've attended 20+ hours of meetings with my group, and have worked more than that on the our project itself. Sure I could have done better on my project pitch, I'm not very comfortable doing those kinds of things (especially knowing that there was no way in hell people would pick my project anyways, thus it's kind of hard to pep yourself up), but I did what I could given that I didn't have front teeth (I was in the process of getting implants): it's a hell of hard time trying to motivate yourself to present when you don't have front teeth. And not only that, my grade has been impacted significantly because I didn't present well, which is a purely subjective grading criteria. The only person who should receive negative marks would be someone who did not present a pitch at all. Also, the grading criteria for the mid-semester self evaluations was also non-existent and is based subjectively; There were only some fuzzy guidelines in what to do. Essentially, everyone should receive a minimal grade of a B so long as they attended and participated in the class in it's various aspects, since everything is "graded" subjectively.

I've been struggling through this semester with a 20 hour internship, and all of my classes essentially consisting of group projects: That's a lot of time having to meet after class with different groups. I've also been struggling internally because of the aspect of actually graduating and having to enter the real world; It's damned scary. I've essentially been attending school for my entire life, and now I have to ram my head against the reality of finding a job and entering the work force; It's daunting for me.

Do I think that this blog post will affect my grade? Probably not in a positive way; but I felt that I needed to get what was on my mind out there.

Note 1: I have typically been writing my previous blog posts rather curtly, since I am more of the type of person to get to the point and avoid the fluff.

Note 2: During a client meeting with Professor Ackley, the topic of what the life of our project was going to be after the class was discussed. He asked a question about who all was going to continue working on it and I mentioned that I planned on graduating: he then made a little jibe about seeing if that happened and chuckled (this was before we received our "mid-semester" reviews). Looking back on that, I am rather offended that he would make light of something like that (since he likely knew my projected grade at the time).

Besides meeting about and working on the schedule generator this last week, we have been focusing on planning out our pitch so that it is a little more cohesive; our first pitch was received rather well, but I feel that we didn't get much feedback because of having presented in the middle of the three presenting that day. I know that we will be presenting in the same order, but I feel that what we have developed and implemented since the first pitch will really have our pitch stick in the minds of the audience (class).

The schedule generator is looking really good. We've got it implemented and have it generating schedules that we can now show on the schedule generating page. There are a few optimizations we could implement on it, such as organizing the class section lists from smallest to largest and then running the algorithm, but that is something that can be dealt with later. I really think that the class is going to be blown away by this feature.

After our last meeting we have divvied up the rest of the work load for this semester. There can only be one person working on coding up the schedule generator algorithm (outside of pair programming), and, thus, we have come up with other minor stories for bug fixes and minor tweaks for those of us that are not working on implementing the schedule generator.

We recently got together and discussed the algorithm we are going to use for the schedule generator. We've come up with a way so that it performs better than brute force, but still gives us all of the permutations of the schedule that we want. It will take in a list of classes, the algorithm will then create a list for each class of each of the class's sections. We will then step through the list of lists and compare each section to the other class's sections. On the comparison of the first two section lists, if the sections fit, another list of the possible schedule will be created. We then use the new schedule lists to compare with the other classes. The growth of the # of lists is the number of current schedule lists * the number of classes in the next section list. If there is a class that does not have a section that fits with any of the possible schedule lists, the algorithm will short circuit and declare that there are no possible schedules with the selected set of classes.

Our client meeting with Dave this past week was very helpful. His urgency on us implementing our final feature (the schedule generator) put our time frame in perspective. However, I feel that we should be able to implement the feature in time for the next demo.

We recently had our meeting for filling out the business model form to help solidify what information we are going to present for the pitch. It is really amazing at how something with so little can eek out so much thought of what would actually have to be done to create a fleshed out business model. We, of course, did not fill out everything since we only have 4-5 minutes to actually present the information during the pitch. It was interesting that there was a lot of overlap in the topics within each box. As we were filling out the information, we would get to another whole box that would be there to flesh out a single aspect of a previous box.

VisualScheduler is looking good. The static pages are done, the backend is essentially complete, and the Scheduling page is making wonderful progress for the the pitch demo.

Finally finished the html frontpage for the web app. It looks pretty bare at the moment, but it's at least ready to be polished to everyone's liking. Time to start on the about, help, and contact pages.

Hell f*****g yeah! Intellij fixed my project problems (though it took me a few hours to figure out how to set everything up). I can finally code without having to deal with janky hacks around the problems (still don't know why they even existed) and can now jump on making our html pages with piece of mind.

Since I've been having severe issues with our project on eclipse, I have been looking into Intellij by the recommendation of Zach Harding. I really hope that it is as good as it claims to be and will resolve my issues.

The lecture from the guest speaker was really interesting to me. The main reason being that I see a lot of similarities of what he was talking about with my current internship. A lot of the processes sound the same, the commit sizes are small because of a mature code base, etc. The only difference is that there isn't too much significance of time at the moment, or it may just be me being out of the loop since I'm only a lowly intern.

Things are looking really good for our project. Dan's girlfriend has delivered on a massive scale with a wonderful series of mockup images. Dan is thinking that the backend is almost done, and that we can begin focusing on working on implementing the front end to look like the mockup images.

I've been having issues with my eclipse project folder settings for a while so I haven't been able to keep track of everyone's work; so I have just been working on the calendar portion and some of my own simple mock up pages that are coded to start off with.

Our project is moving along well. Dan recently got a remote server up and running using Amazon's AWS services. Our backend is looking to be in good shape and we've started on developing a basic front end. Unfortunately, I've been running into project/repository issues with the recent project consolidation/cleanup from the initial repository. Hopefully I can get that resolved quickly with the help of Dan.

I've found something very promising for the calendar visualization. There is an AngularJS framework based utility packaged called AngularUI. AngularUI has a full calendar (month view, week view, day view) that I think we'll be able to use for our project. I've started looking into it and hope to have a demo up within the next couple of days.

I've been tasked with researching how we are going to visualize the schedule. It will most likely be some sort of weekly calendar, similar to what UNM has for their weekly schedule or Google's calendar, in which you can add schedule objects that will then appear as blocks of time in the calendar.

I'm feeling good about our project, it looks like all the separate pieces that we've been working on are fit together well and we're able to get basic query functionality. With the basic guts implemented its now time to start working on the front end design of things and make it look pretty.

It has been a really interesting time figuring out how we're going to store and update our SQL database for the potential feature of notifying registered users (another potential feature) that a class that they chose for their schedule has changed. We've had to change routes a couple times already, and know that what we were doing wouldn't quite work correctly. We still have quite a bit to discuss to figure out exactly how we are going to implement our database structure for this feature. One thing that we do know is that it will most likely have some sort of global version control that we will then utilize for various things such as deleting old versions, and comparing old version data to the new version data to look for differences.

Recently,  I've been catching myself thinking about what type of algorithm we're going to be using to compute schedules. I've been trying to think of various ways to do it, but have not really thought too deeply; I've mainly just been accruing starting ideas to then run on and see where they might lead to when it comes to the point of actually developing the algorithm. I've tried searching online to see what might already be out there, and found a thing that used a genetic algorithm to create a class schedule. Unfortunately, we have many more variables that would have to be accounted for, and the genetic algorithm is probably out of scope for this project at the moment; the best bet for now is to create a simple naive algorithm or a greedy algorithm to create schedules when the time to comes.

Well, finally got around to writing a bash script to download the xml data from the opendata unm website. Juggling work and classes has been much more difficult than expected. The bash script is just a simple wget followed by the url to the download link. It can be run from anywhere, but there is no central server yet, thus there is no reason to start a cron job to keep the xml up-to-date while we are still in component development.

I know it may be a little delayed, but I've been reflecting on my project proposal not being chosen. I am extremely relieved that it wasn't chosen for many of the same reasons that were brought up in class: I'm glad that I don't have to take charge of a project, I'm glad I don't actually have to plan things out thoroughly to actually complete the project, and I'm super relieved because I'm pretty sure I wouldn't know where the hell to begin on working on my project. I've also been thinking about how much work my project would have required and am really glad it wasn't chosen because it would have required a "metric-crap-ton" of work.

Overall, I'm glad I don't have to stress about leading a project, and I got my first pick for the project selection.

It took a bit of time to think things through a little more. Alas, there is always more things to think about when it comes to projects. Thus, here is my final project proposal: ArcadeStyle

Blog HW: Describe your ideal project team in exactly three words.

Main Choices:

Creative : when it comes to developing a project that starts with the entire universe but then down to a single something, you need to have a lot of creativity.

Driven : it is always important to be hardworking to actually achieve the goals of a project, otherwise nothing will get accomplished.

Teamwork : it is important to work as a team when it comes to large projects, if the team is not cohesive, and does not working properly together, the project will fall apart.

Runner-ups

Honest : it is important to me to be honest about things. If you don’t think you can complete something on time, say so; the rest of the team would be able to help. Being honest also helps team bonding by knowing that you can rely on your fellow team mates.

Professional: This can certainly cover a lot of other descriptors, but I mainly use it as a form of conduct. It is to standardize the format of interaction between the team and other stakeholders. If you act immaturely/unprofessionally others will not want to work with you.

Communicative: Communication is a key to getting things done, and is a sub-aspect of teamwork. If there is no communication between team members, confusion will takeover and no one will know who is doing what.

Review of Proposal : “Demigod”

Proposal author: Matthew Smith (artintal@unm.edu)

Reviewer: Kellen Zelle (kzelle@unm.edu)

Part 1: Proposal restatement

The purpose of this project is to create a web application that users can use to keep track of and challenge themselves in the areas of physical fitness, nutrition, and mental acuity. The mission statement is “...every person should be able to reach the level of a ‘demigod’.”

Part 2: Reviewer reaction

This is a great idea to help increase the overall health of people. Combining various other app functions into a single webapp definitely increases desirability due to the convenience of it. The major problem that I have with this proposal is the sheer size of the task at hand: the companies that developed the apps mentioned in the proposal took way longer than a mere 11 weeks to develop. Also, it appears that this app would run purely on the ‘honor rule’ in which users have to be extremely honest to the app, and with themselves, to actually make use of the app in the way it was intended: It would be way too easy for user to cheat. There is also no convenience in the way of tracking, especially when it comes to physical activities, especially for running: users would most definitely need a fitness watch to keep track of distance traveled and speed. Another thing that I feel iffy about is the mental acuity tracking; it occurs to me that this is rather hard to do, especially if you’re only taking into account GPA/courses complete/Languages known etc. There needs to be some kind of standardized measurement, and deciding on what that is will be a large debate/challenge itself.

Part 3: Quantitative Scores

Format: 4

Formatting is good. Not much else to say.

Writing: 4

Writing is good overall; there are a few spelling/grammar mistakes.

Goals and tasks: 4

The goals are stated clearly and tasks are laid out in the timeline.

Scope: 3.8

It is clear what this product is meant to do. Though it should be more detailed on communication with other applications, and hardware such as fitness trackers.

Plausibility: 2.8

This would be a very scary project to undertake in 11 weeks if your life depended on it. There are so many facets of this this project that, if not fully fleshed out, will only detract from the overall product from shoddy functionality. The sheer size of what needs to be done really makes me think that this should be a project that has a timeline of a couple of years to bring everything up to a polished, user friendly state.

Novelty: 5

If this app is successfully created and polished, it will be the only one of its kind.

Stakeholder identification: 2

You should have a section on stakeholders. Sure, you mentioned users, and other developers, but you should have them in more detail that specify their relations to the project.

Support and impact: 3.5

Good detail on initial support plans: with asking for donations and having ads on the webapp. Though one thing you should consider is having a one-time donation/subscription to remove ads for that user.

Evidence: 3.5

Some use cases would go a long way in providing how a user would use the product.

Challenges and risks: 4

Good detail on possible challenges and technological limitations.

Review of Proposal : “A/V Synthesizer”

Proposal author: Trent Small

Reviewer: Kellen Zelle (kzelle@unm.edu)

Part 1: Proposal restatement

The purpose of this project is to create an audio/visual synthesizer that takes in midi input and visually displays the audio with a range of visual effects. The software will be combined with hardware to sell to the customer.

Part 2: Reviewer reaction

It’s a really cool idea, but I think the way that you have it planned out requires the customer to do too many technical aspects to get the A/V synthesizer configured and set up. The thing that could remedy this would be to develop a user friendly GUI interface with all of the configuration options easily accessible. Another thing that was a little iffy to me was the blanket statement of ‘hardware’, there was no detail as to what the ‘hardware’; does the hardware consist of arduino’s with LED lights/projectors attached to them etc.

Part 3: Quantitative Scores

Format: 3.8

Easy to follow. Though, there could be a few more sections to provide more detail (hardware in particular). Very bare.

Writing: 3.8

Good overall. A few misspellings and grammar mistakes.

Goals and tasks: 4

The goal is very clear and the tasks are easily identifiable from the Timeline, but there should be more detail in a section of it’s own for goals and tasks.

Scope: 4

It is clear what the scope of the project is, but it may be a bit large for the time given to complete it.

Plausibility: 3

I can see being able to create an AV synthesizer that can be run on any screen that can be used with a computer. But developing the AV synthesizer and hardware to run the synthesizer over wifi seems like it may be a little unreachable given the available time.

Novelty: 4

It’s a cool idea, but there is nothing explaining how this AV synthesizers will set itself apart from other synthesizers.

Stakeholder identification: 4.5

The stakeholders are clearly identified in the proposal.

Support and impact: 3

There were no detailed plans on:

• How much the hardware would be sold to the customer for.
• Is the software portion of the project given freely or is its cost included with the hardware cost? What makes this hardware unique that a customer wouldn’t be able to buy it from somewhere else and run the software on it?
• How would you market the product for it to get into the hands of the public?

Evidence: 3.5

There is a decent amount of evidence that the project can be complete, but there is none that shows that the resulting product will be marketable.

Challenges and risks: 2

There are some inherent challenges seen in the proposal, but there should be a section going into detail about the various challenges that need to be overcome to complete the project. There should also be a small risk section going over the risks of early hardware prototypes failing and how much that could cost over the full development of the product.

Review of Proposal : “Turing machine-inspired puzzle Game”

Proposal author: Luke Balaoro (lbalaor@unm.edu)

Reviewer: Kellen Zelle (kzelle@unm.edu)

Part 1: Proposal restatement

The proposal is to make a Turing machine inspired puzzle game that teaches basic programming and logic targeted toward casual gamers with a focus on those who enjoy puzzle games. The game will have ‘story-mode’ levels, user created levels, and an online scoreboard.

Part 2: Reviewer reaction

It’s a good idea, well thought out for the planning, but not much detail on how the actual mechanics of the game will work. One thing that I noticed is that you want to keep the style strictly neutral; I think that if it is strictly neutral, the game will appear to be bland, the style should have a theme that is eye-catching. Another thing is that there are no ‘theoretical’ plans to distribute the finished game for monetary compensation. Other than that, everything is well planned and detailed.

Part 3: Quantitative Scores

Format: 5

Very straight forward; easy to navigate.

Writing: 4

Style is very monotone and descriptive. There were a couple of errors and a few phrases that were awkward.

Goals and tasks: 4

The goals and tasks are cleanly laid out and planned throughout the rest of the course. Though I think the hour estimates might be a low.

Scope: 4.5

The scope of the project is laid out well within the proposal, and there are no open ends that need to be thought about.

Plausibility: 5

This idea is highly plausible in the sense that it can be completed in the set amount of time.

Novelty: 3.5

It’s an ok idea, but it can be lumped in with other educational/puzzle game software, unless something is developed that makes it stand out from the others.

Stakeholder identification: 4.5

The stakeholders are clearly defined.

Support and impact: 3.5

There was not a plan on how to generate revenue to support the game after release. There were also no plans on how to market and distribute the game to the public.

Evidence: 3.8

There is a lot of evidence that it is possible to develop the game, but there is no evidence as to why people would want to play this game over other games of the same genre.

Challenges and risks: 3

Only one challenge is displayed and explained. I’m sure there are more challenges than just creating intuitive and interesting levels.

Review of Proposal : “Ambient Algebra”

Proposal author: Brandon Lites (blites@unm.edu)

Reviewer: Kellen Zelle (kzelle@unm.edu)

Part 1: Proposal restatement

The proposal for Ambient Algebra is to create an online webapp game platform that hosts fun games that help the targeted populace, college students, learn algebra in a fun and interactive way instead of doing problems out of a text book. The webapp would keep track of students progress in the games, and will provide an online scoreboard to encourage students to learn more to earn the top score. The design of the webapp would not be to replace textbooks, but as a supplement. The motivation behind the project is due to the poor performance of the US in math.

Part 2: Reviewer reaction

I really like the idea, and agree that the youth of the US should not discard math as “too hard” and instead, attempt to learn it to the best of their abilities. The one issue that I have with this proposal is that the main targeted audience are college student’s: I believe that this project should mainly target high school students, but also be accessible to college student’s. This is because I think that the problem of college student’s not knowing algebra should be fixed by them knowing algebra before they get into college. Other than that, its a solid idea, though, I think coming up with games that are actually fun and conduce learning will be a real challenge.

Part 3: Quantitative Scores

Format: 5

The formatting of the proposal was spot on, and cleanly transitioned from one topic to another.

Writing: 3.5

There were a few errors, and the wording in some places was awkward.

Goals and tasks: 3.8

The goals are clear, and the tasks are stated, but there is not an idea on what a game would consist of.

Scope: 4

The scope is clear: this project is targeted towards college students, and will consist of a webapp with games.

Plausibility: 4

The idea is highly plausible, but the main issue in the development will be  coming up with games that produce the intended results of the project.

Novelty: 3

There is a lot of other educational software out in the world; this idea is somewhat different in that it targets an older age group.

Stakeholder identification: 4

Good identification of the stakeholders; from the students, to teachers, to possible educational consultants.

Support and impact: 3.5

The support plan is decently fleshed out, but there is no explanation on how to get the product to be adopted into the educational world.

Evidence: 4

There is strong evidence that something like this should be developed to help increase the math capabilities of students due to the poor performance statistics supplied in the proposal.

Challenges and risks: 4

Challenges and risks are clearly stated in it’s own section and some possible solutions are given to the largest of the challenges.

The following is a link to my project proposal : Multigame Platform for Arcade Style Unity Games.

It is really hard to try to think of all of this stuff by yourself. I'm sure it is a lot more thorough to make project proposals as a group in a work place setting.

It is really quite impressive how extensive and detailed the Volere template is, and is extremely helpful t'boot. It sneakily forces you to have to think about things that you normally wouldn't, just by reading the template and attempting to complete the sections. It had me having to fully realize who the users are, and what their intended relationship with the end product of the project is supposed to be, and it's only the second section of the template. I would be completely lost and in despair without it. Back to the proposal writing I go...

I really like the idea of Agile software development, mainly because I think I've inherently been doing it throughout my CS undergrad degree without knowing it. It is really nice to have a very well thought out and codified software development approach that enables you to work efficiently and gives you the versatility to work how you want to.

Throughout my classes, I had heard of Agility software development, but had never really looked into it. I find it interesting that there are two different kinds of Agile methods: the waterfall method and the lightweight method. After reading about both of them (skimmed), the lightweight method is definitely the most agile between the two; the waterfall method feels too structured and restricts freedom of workflow, while, in my experience, having something so structured in programming never really works out too well: mainly because things appear unexpectedly and you have to go back a step or two to fix something. One of the main things that I agree with the most about lightweight vs waterfall is that lightweight has continuous testing of your code as you implement features instead of just a testing phase where you test everything at once.

This is the my preliminary timeline for my proposed project in CS 460.

I'm not sure what the timeline needs to consist of, so I did what I thought was necessary.

Found this nice little blog post about Killing the Crunch Mode Antipattern. It explains this individual's reasons (with some link backup information) on why the fabled "crunch mode" in software engineering is a stupid and unhealthy practice. Crunch mode essentially deprives software engineers/programmers of sleep and causes coding errors and bad habits to develop.

Reasons crunch you shouldn't go into crunch mode:

• The less sleep you have, the more prone to errors you are going to make in your code. This will cause major slow downs in development because you then have to go back and fix your sleep deprivation caused errors.
• If you do it too much, you might lose your passion (if it existed in the first place) for software engineering/programming. I can't remember ever thinking, "let's work crazy amounts in a short period of time, over and over again."
• It makes you lazy and less productive in the long run. After working really hard for a burst of time, you begin to rationalize that you should take it easy during the non-crunch times.
• You might not make your deadlines even with going into crunch mode.
• If people know that you've been working like crazy, they don't expect you to not make errors.
• It makes you wonder if the team leader / management really cares for your health over meeting a business goal.

Essentially, in more brain intensive work, crunch mode doesn't give good results; thus it doesn't really mesh well with software engineering/programming.

Reasons crunch mode is activated:

• Unrealistic expectations for project deadlines are set.
• Managers fear setting far off deadlines.
• Heroic feeling of finishing a ton of work in a small amount of time.
• It drastically increases the focus level for that period of time, enabling team performance to soar.

Alternatives to Crunch mode:

• Missing the deadline.
• Set smaller goals.
• Measure progress concretely.
• Set realistic goals.

So how exactly does one end the practice of crunch mode? Well, it appears that it is up to each individual within software engineering. Managers need to hold themselves accountable for poor planning, and need to view going into crunch mode as a personal failure. Everyone else needs to hold themselves accountable for their every non-crunch time minute at work; if the work is done evenly throughout the deadline, there won't bee a need to activate crunch mode.

Concept Paragraph for CS 460:

There are many old multigame arcade-style game platforms in the World today, but there is not (that I know of) a modern digital multigame platform with modern arcade-style games with online scoring; most modern arcade games are standalone arcade cabinets. All of the current multigame platforms are antiquated arcade cabinets or emulators of compilations of old arcade games.

For this project, the team will create a suite of arcade-style games with online scoring that will provide user entertainment using a modern development engine, Unity, and package them in a multigame software platform where it will be visually pleasing and user friendly to access the games.

Arcade-style game lovers, who have played and continue to play arcade classics through multigame arcade cabinets or emulators, will enjoy playing and using this software because it has multiple games with the style of games that they enjoy but with modern polish.

This platform will be open-sourced to allow other game developers to add their own games to the platform and will result in a very large game library of modern arcade-style games. The online scoring server will be monetarily supported through donations.

If you have wanted to or have enjoyed game development, please support this project where we can create one of the first modern arcade-style multigame platforms.