![[RoutineLogo.png]] # What Is It Routine is an application to help people schedule a studio's process. This application should make the scheduling process time be reduced by 70% and wholly should be automated and create tools that are easy for instructors to reduce the overhead of scheduling. I started work on Routine about 5 years ago and worked on it for almost 3 years. After I graduated college, I had to put to down for a bit due to other priorities, and now working to pick it back up after. I wanted to capture my non-organized notes over the next few months of working on it. # History When I started this project back in 2012, I didn’t have much background in working on a solution like this. I was excited to work with someone who had an idea and make it to fruition. Here commenced a multi-year effort for me to learn how web applications worked, (this was before the “JavaScript framework wars” pervaded) and I picked the common cool kid stack of MEAN.js. I had a little bit of web knowledge but looking back, I learned more practical elements of software engineering. Things like, getting software into production, a modern web stack (like what is front end and what is server side) to what is product management, and scope creep. Scope creep is something said in later college classes and something I hadn't quite experienced until I did, IYKYK. After doing many iterations on the project I realized that the core of the solution I was expected to solve was the hardest. I was all about solving easier problems that didn't quite solve the ask. After some introspection and a few years of added maturity, I realized that for this project to be successful picking it back up was to summarize the learning and keep the eye on the prize as it were. What, you may ask was the scope creep. The task I wanted to solve was to make scheduling easier. I accomplished some of that by collecting schedules but what I hadn't considered was the time, complexity, and difficulty of solving the actual scheduling problem. If you don't know, the schedule falls into one of those categories that a direct brute force approach makes this problem space uncomputable. Little did I know that at the time but each time I tried to solve the problem it got difficult, so I would add new features that weren't the main problem but made it look like the project was moving forward. After a year of working on it, I was wrapping up school and realized that this problem space fell into the "uncomputable" problem space and didn't know how best to solve it. Fast-forward many years later with a few experience points, and I have an approach and what I can do to move in that direction. # Plan 2.0 The approach and business model are more manageable and believe the best POC is more reasonable. Add on the fact that technology has improved significantly since early 2012 and creating a POC can be more realistic. Investigation and research into a genetic algorithm allow this problem space to be heuristically solved. This means that while we can't find the provable most optimal approach we can get close. The plan is to merge this is some level of predictive AI and maybe a splash of quantum computing if I can and maybe have some modern or next generation scheduling. Now if you think I'm saying all the buzzwords, you got me. I'm interested in solving today's problem but also solving some future problems, call me optimistic, but hey, this is my project. :) I've written out the scope I want to approach with a guiding light on adding new features and checking myself and hopefully that will help me solve the problem I've set out to solve. If not for the industry, at least myself. ## Tech stack Ok, so what's the planned tech stack? This can always be interesting because it could be opinionated but honestly, I'm going with a C# backend, and a nextJS frontend (mainly React.) There are so many other options but I like the C# for its simplicity and scalability and better familiarity with it and it's one of my favorite programming languages. Looking at databases, probably going with a postgresDB for now but early POC's will just be in memory. ## Why So why? The early days, I was doing this for a piano teacher I was put in contact with, after some investigation and putting the project down unfortunately the project died out but little did I know, my future wife (another piano teacher, not the one I originally did this for) is also interested in surprisingly after so many years there still isn't great solutions for this. Another reason? Curiosity. Honestly in the day and age where technology and AI and all this is consuming the world, good old-fashioned problem-solving is still needed. Even AI can struggle a bit with this and could be considered the wrong tool for the job. Finally, I already know the problem space pretty well. I've done a fair amount of research and thinking over the year and this is something I'm still interested in solving. Even just for my own benefit, I get to work on some cool technologies. After working for five years on [Olleh](https://ollehapp.io) it's time to start a new project. # What's Next Well, I'll likely update this page or sub-pages with my noodlings and learnings.