SE450: Requirements: Example Text [12/16]

Successes and Failures

In an embarrassing act of hubris, I spent the initial three weeks on this project building my own model, without regard for the provided example code.

This proved to be a very poor decision, as I eventually cycled through at least four full versions of the model before realizing the error of my ways and repenting the Sunday prior to the final project due date.

Each of the four draft models ended up being a horribly unworkable, albeit elegantly structured simulation model.

Ironically, I found that considering the design patterns first is an awful way to develop solutions. My initial drafts all tried to implement a similar design concept, which involved a radical decoupling of the Road and Car classes.

As the final project due date neared, and as I realized the dire consequences of working with my inspired implementation, I made the crucial decision to throw it all out and start fresh the Monday prior to the deadline.

I took the day off from work, began to program at eight AM and did not stop until well into the evening. This time I took a much more utilitarian approach to writing code, focusing on getting a working solution first rather than an elegant solution.

Armed with the new focus - valuing code that worked above code that was creative, the final build-out went extremely smoothly. This time, as I encountered dilemmas I began to consider ways that I could restructure the code. If one potential solution was more obvious and simple than another, I realized that it was in fact the correct solution to use.

For example, as I began to consider how to structure the Light class to allow for three states instead of two, I knew that I needed something that would allow the internal state of the Light to change in an independent fashion. As the internal state of the object needed to be encapsulated and handled elsewhere, and not just behavior, the solution was clear - to use a state pattern.

Similarly, after completing a working model and connecting with the Controller, I discovered that I hadn’t thought of how the users would be allowed to change the model parameters.

Knowing that the static class wouldn’t suffice for updates, and that all internal objects needed access to a single object, I had no hesitation to implement a singleton.

In summary, apart from learning useful ways of structuring code, I learned a valuable corollary lesson through this course - that laziness is a virtue. The more I think about it, this virtue of development encapsulates the purpose of good design, to make creating, adapting and maintaining solutions easy.