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.

After reading the software engineering Wikipedia page, I find it interesting that Dijkstra didn't look very kindly upon the field of software engineering. Dijkstra's quote on the Wikipedia page got me interested in what else he thought, so I followed the source to his On the cruelty of really teaching computing science essay. There were some very interesting things in it, but I really liked these two paragraphs, because even now, 25 years later, they are still relevant.


"The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger."

"Besides the notion of productivity, also that of quality control continues to be distorted by the reassuring illusion that what works with other devices works with programs as well. It is now two decades since it was pointed out that program testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence. After quoting this well-publicized remark devoutly, the software engineer returns to the order of the day and continues to refine his testing strategies, just like the alchemist of yore, who continued to refine his chrysocosmic purifications." - prof. dr. Edsger W. Dijkstra

Welp... Welcome to my legen-... wait for it....






















...



























...-DARY blog! (see what I did there? I amuse myself too easily).

This is my first blog post ever, so I didn't want it to get straight down to business... business being obtaining imaginary internet points; y'know, the ones that make you feel all cuddly inside... and by obtaining imaginary internet points that make you feel all cuddly inside, I mean CS 460.... So I'm just having a little fun with it.

Also, all of you other people... don't steal my blog title! Land O' Coderissian®, Trademark pending*.





*not really.