Most conversations about instructional design assume a logical, linear process. Standards are defined, curriculum is developed, and courses are launched. In reality, large projects often encounter unexpected policy changes, administrative directives, or shifting requirements. One of the most valuable lessons I learned while developing computer science courses for the Texas Virtual School Network was that strong instructional design is not about defending the original plan. It is about adapting quickly when the rules change.
Building the Original Vision
Everything in Texas public education begins with the Texas Essential Knowledge and Skills, better known as the TEKS.
In 2015, the Region 6 Education Service Center secured funding to develop computer science offerings (Computer Science I & II) for the Texas Virtual School Network and approached us because of our experience developing and delivering online courses.
The project placed me in an unusual role. While most curriculum development projects separate subject-matter expertise from instructional design, I was effectively serving in both capacities. My academic background included a minor in secondary education and successful completion of the certification examinations for secondary computer science. Although I was not employed as a secondary computer science teacher, I had both the technical background and the instructional design expertise needed to build the course while ensuring alignment with the Texas Essential Knowledge and Skills (TEKS).
Based on the published standards, we designed the course around Pascal using the open-source Lazarus development environment.
The choice was deliberate. The language was approachable, the tools were freely available, and the curriculum aligned well with the learning objectives outlined in the TEKS.
More importantly, the alignment work was meticulously documented. Through Blackboard’s goals and outcomes tools, every required TEKS objective could be traced to specific learning activities, assignments, and assessments. The course had even undergone an external accessibility review, and the handful of issues identified during that process had been addressed. From both an instructional and compliance perspective, the course was ready.
So we submitted it for review.
That’s when the rules changed.
Despite the flexibility contained within the TEKS, reviewers informed us that the expectation had shifted toward aligning all computer science offerings with the language used in AP Computer Science.
In practice, that meant Java.
The course wasn’t partially complete.
The course was finished.
And suddenly it wasn’t acceptable.
That experience taught me an important lesson about curriculum development in regulated environments: written standards and operational expectations are not always the same thing. We had built exactly what the published requirements supported. Unfortunately, the expectations used during review had evolved beyond what was written.
Choosing Pragmatism Over Perfection
Rather than treating the review outcome as a setback, I served as both subject matter expert and instructional design lead to redesign the affected coursework, rewrite instructional materials, and prepare the revised curriculum for launch.
Instead of creating everything ourselves, we focused on finding and integrating the best available resources.
We incorporated high-quality Open Educational Resources wherever possible. We also licensed a comprehensive instructional video series developed by an experienced Texas computer science teacher who had already created effective content aligned with the state’s expectations.
That decision allowed us to move much more quickly than if we had attempted to recreate every component ourselves.
More importantly, it gave students access to proven instructional materials without delaying the project’s launch.
The experience reinforced something that is easy to forget in academic environments:
Building everything yourself is not always the best solution.
Sometimes the best solution is assembling the right pieces and integrating them effectively.
Good Architecture Survived the Pivot
The programming language changed, but the standards did not.
Because the course had been architected around TEKS requirements, learning outcomes, and assessment alignment rather than specific syntax examples, much of the underlying structure remained viable. Assignments required revision, examples had to be rewritten, and supporting materials changed, but the curricular framework remained largely intact.
In retrospect, that became one of the most important lessons from the project and one of the foundations of a saying I have repeated throughout much of my career:
“Good instructional practice is good instructional practice, regardless of the setting.”
Strong instructional architecture often survives changes in technology because it is anchored to outcomes rather than tools.
A Complete Lifecycle
What began as a frantic redesign ultimately became one of the most stable courses I ever helped develop.
The course operated successfully for roughly a decade. Software versions changed. Learning platforms evolved. Submission processes were updated. Yet the core curriculum remained remarkably stable because the standards that supported it remained stable.
Much of the credit belongs to the dedicated instructor who championed and maintained the course throughout most of its operational life. Once the course was established, my role became largely advisory, occasionally providing technical assistance when unusual problems emerged.
Eventually, however, the course reached the end of its natural lifecycle. Around the same time the instructor retired, the TEKS underwent a substantial revision. Supporting the new standards would have required a significant redesign rather than a routine refresh. Without grant funding to support that level of redevelopment, maintaining the course no longer made strategic sense.
After serving students successfully for ten years, the course was retired.
Looking back, I find that ending just as interesting as the launch. Educational technology professionals often focus on creating new systems, but mature organizations also understand when it is time to let an old one go. The course had fulfilled its purpose, delivered value for a decade, and reached a logical conclusion.
That’s a complete lifecycle.
What I Learned
This project reinforced a lesson that has appeared repeatedly throughout my career.
People often confuse commitment with stubbornness.
Being committed to successful outcomes does not mean remaining committed to a particular implementation.
The original Pascal-based design was thoughtful and defensible.
It was also no longer the design we needed.
The ability to pivot quickly, leverage existing expertise, and adapt to changing requirements ultimately mattered more than preserving the original vision.
Final Thoughts
The educational technology field often celebrates innovation.
Innovation is important.
But adaptability is often even more important.
Projects rarely fail because their first design was imperfect. They fail because teams become too invested in the original plan to respond effectively when circumstances change.
In this case, a late-stage policy shift forced us to rebuild part of the course from the ground up.
What could have been a setback became a lesson in flexibility, resourcefulness, and pragmatic problem-solving.
The course ultimately served students successfully for nearly a decade.
Looking back, that longevity had far less to do with the programming language we chose and far more to do with our willingness to adapt when the rules changed.
