Concluding the Semester

On the Purpose of the Assignments

While on an assignment by assignment basis they each taught us a specific implementation, design, or engine process. I think there is a larger lens to look at the semester as a whole.

In previous semesters we've written engines where we were instructed on what to do, but for the most part not HOW. While the difficult part for me wasn't the exact implementation of a given feature, it was often times the design or coming up with the sensible decisions on WHERE to place things. By having an existing code base to work within, I had immediate examples for design centric decisions when it came to writing the various systems that we've done.
​
I also enjoyed the "directedness" of the assignments. Because of this, I was able to spend most of my time on the "HOW" to accomplish a goal. Not "WHERE" that has tripped me more than once in the past. I felt like the learning was that much more effective because I didn't spend too long spinning my wheels wondering on the best practices to go along doing something. Since I could just look elsewhere in a different system and see how it was implemented, and try my best to stick to an existing design. By imposing this arbitrary design consideration on myself, I also got experience on working, and sticking to an existing designs. Which, may be more useful if working on a large team.

What did I get out of the class?

Of course, the exact topics that we covered were at times completely new to me, so it was great to get my first experience with some of these systems and topics. Although, the best insights I got out of the course were directly related to Engine DESIGN and the thought processes / justifications for doing things a certain way.
I do want to comment on the fact that at the beginning of the semester I had thought the codebase was quite huge. But, at the end I believed that I had a decent grasp on the code base as a whole. I may not know every system intimately, but I had gotten to the point that I knew the DIRECTION to look in for specific things and questions.
 

Thoughts on General Software Architecture

After the experiences of this semester, working in this engine while also alongside a "large" engineering team. Time and time again I found myself practicing the design mantra of things should be where you THINK they should be. Meaning, sensible. I used that word far too much this semester... I do believe that there needs to be a period of planning prior to beginning major work on a project, whether that be the raw outlining of systems and where they exist or directly on the code habits of working with these systems. I prefer the upfront planning, even if it be brief and sparse. I have always been a person that prefers a plan of attack versus "winging it".

This semester one of my colleagues made the statement concerning what constitutes good code (paraphrased):

"It needs to be easily iterable, flexible enough that changes can be made to match the needs of the developers and design without too much rework".

To do this, what does it entail? Surely we can't be aware of ALL of our future needs for the entirety of the project. But there are base design considerations that can be made. For example, in my latest project NOT having on screen buttons tired DIRECTLY into the graphics system. This would server better in its own interface system that speaks to graphics. By having multiplatform being a high emphasis this semester we can take steps to ensure that our code is as platform independent as possible by using a multitude of the strategies this semester.

I believe good software architecture should be easily iterable.
​
Bad software design ties systems together, with dependencies going back and forth requiring a single end change, to take numerous changes along the way. Or more succinctly:
 
Bad software architecture is when a "small" end change requires a "large" internal change.