Time to Read: 7 MinutesComments
In August 2018, the doors finally closed on the old Assessment System. I’m not completely clear on when the old Assessment System was originally released however judging by some comments in the oldest files, I can estimate it dating back to 2010-2011. Relatively young, all things considered. It grew over time to accommodate multiple requirements and additions and modifications from multiple graduate assistants until its final summer in 2018.
Nevertheless, the new Assessment System had formally entered design and development in August 2015 and would formally be deployed in August 2018 to begin the 2018-2019 academic year. Ever since being hired as the full-time employee for the university, my responsibility had been the joint development of this new system and the maintenance of the old system. The data migration process outlined in previous posts would be executed one final time to ensure that all remaining most recent information would be migrated over to the new system prior to launch.
The previous Spring and Summer I had conducted workshops with the faculty and staff to help facilitate a smooth transition to the newer system and to also help them familiarize themselves with the new interface; creating a sandbox for them to work within before the system officially launched. The Winter before that, I had finished creating a Usage Manual totaling nearly 300 pages detailing all of the functionality of the new system in a manner that it could be easily partitioned and distributed in a Quick Guide format for certain roles; it would serve as a training tool for the aforementioned workshops.
For the most part, all of the functionality for the new system was complete and ready for launch barring a few specialized reports which were later completed and had no bearing on the functions of the system that would be mostly hit. And that was the plan, I wanted to see how the system would bend and where it would basically break with the workload of being hit by hundreds of users. Since the system was very large relative to the number of active developers (i.e., one), this was my best bet of discovering potential issues that I may have overlooked in testing and development. And for the most part, the deployment went smoothly with only superficial issues that required resolution.
So looking back…
Though I am tying a bow on this series, it is obvious that the new system will continue to grow in some capacity. There will be new bugs and issues uncovered as the system remains live and continues to be hit consistently. However, in this section I wanted to reflect a bit on some points, things that I may have done differently now, obvious shortcomings, so forth.
For starters, though the entire experience of designing, developing, and deploying a large system as the sole developer is exciting. There are some obvious shortcomings to this approach such as: as a cowboy coder you generally do not have to appeal to technical management for your implementation decisions. Some may argue that this is a good thing since constant appeals stifle development, but as a fairly junior developer, you do not have that correctional mentor to expose your blind spots, naivete, or poor design/development decisions. The project progresses and performs to your competence level only.
You’re essentially teaching yourself through your own experience but if you’re not careful you’ll find that you may artificially limit your domain to only the areas that you’re familiar with and not explore possible solutions that lay outside of your immediate expertise. Similarly, as a cowboy coder, you do not have the collaborative experience of working on a full software development team that commonly use agile methodologies to perform development sprints, schedule stand-ups, and so forth.
Though, I did use a git-based version control system for the development of the system. Merging branches and pull requests were unnecessary because I was the sole developer on the code base. I had also introduced my own official naming conventions for the various languages and developmental use cases (i.e., file names, directory names, etc) but since I was the only developer, it was almost superfluous.
From the very beginning, I shied away from using any existing PHP frameworks. I simply did not want to be limited by the framework itself and preferred the simplicity of using vanilla PHP. I also believed that this would make future development and deployment by other institutions easier because it would not require the personnel to learn a framework nor would the system will be dependent on the lifespan and support of the framework. Though I had no interest in reinventing the wheel, I also tried to limit my usage of external libraries primarily depending only on jQuery for client-side interface-related functionality and a couple of PHP libraries for the SMTP batch emailing functionality and HTML sanitation.
The core functionality of the system is held in its modules which are directories structured in the following manner:
Most of the pages’ functionality is fairly straight-forward and could be easily substituted with another server-side language. Most of the pages are simple forms that follow a Post/Redirect/Get pattern and change templates based on the execution of the page.
The system’s structure itself is pretty straightforward.
A PHP directory for system-wide PHP files.
A ‘lib’ directory for holding external proprietary libraries.
A ‘Page Components’ directory that is responsible for storing the files for the components that structure every system’s page.
My original plan during the design and development of the new system was to make it as plug-and-play adaptable as possible, keeping the core functionality and interface within a work space that could be inserted into any institution’s existing theme or layout and the organization of the above page components was to ensure this ability.
In the end, the statistical size of the new system could be described in the following way:
Are there things that I would have done differently? Sure. There’s an adage that says that if you don’t look at code that you’ve written three months prior with some degree of disgust then you haven’t grown as a programmer. In hindsight, I wish I would have followed a more disciplined TDD approach. I wish I adhered more-so to Automattic’s WordPress PHP Guidelines. But altogether, it’s been an enjoyable learning experience and I am happy to contribute a worthwhile and robust solution for my employer and I am also thankful for their allowance of full autonomy and time to ensure the completion of this project for them.
This post is about the project, DREAM
An online electronic assessment system for the purpose of collecting assessment data regarding student teachers and counselors throughout their collegiate career. The system also electronically facilitates a large number of other institutional processes in an effective manner.
Software Developer Career Tips: Closing Thoughts
12 February, 2020
Fitness Series: Illnesses and Injuries, Make a Contingency Plan
03 February, 2020
Software Developer Career Tips: The System Design Phase
27 January, 2020
Software Developer Career Tips: The Technical Phase
21 January, 2020
Software Developer Career Tips: Do Your Preliminary Research
13 January, 2020
The Power of Habit
19 December, 2019
Rich Dad Poor Dad
14 October, 2019
19 August, 2019