Why I Threw Away a Week of My Work

In a previous post, I wrote about how important it was for CTOs and engineering leaders to do proof of concepts and other special projects. Those projects are critical to removing unknowns, proving something can be accomplished, and speeding up project timelines.

In this post, I want to tell you about a proof of concept I did recently. I want to dive into why I did it, what I didn't do, and why I am throwing all the code away!

What was the project?

My company does digital marketing, and the key to our business is dynamically changing the ads based on scheduled appointments and service availability. Currently, our customers use our software to manually change how many appointments they have. Believe it or not, it isn't automated! 👀

As you can imagine, automating this by integrating with appointment scheduling systems is a big deal for our company and our customers. The project sounds simple at first glance, but it isn't. To integrate with this other vendor, we must first understand how their UI works and what APIs to use, as they have dozens of APIs.

It is complex because these companies have multiple services and potentially dozens of employees with many weird rules.

Why did I create a prototype?

Projects like this are a perfect example of projects that need a CTO or very experienced and product-savvy engineer to work on them. There are a lot of unknowns and ambiguity in not only how to do the integration but what to do with the data we can even get out of it!

Software commonly gets prototyped using Excel, Figma, or other tools. Since this project is based on API integration, doing it in code was the best way.

That is where I come in. As a CTO, I can use my product expertise and technical skills to figure out exactly what we need to do for this integration and what to do with the data we extract from it. It took me a week to hack together a working prototype to prove how we would do this integration, what data we needed, and how to use it exactly.

It would have taken one of my other developers weeks to figure this out because of all the unknowns. So I aimed to eliminate all the unknowns so someone could complete the production version in a couple weeks.

I shaved several weeks off the project by being able to remove the unknowns and finalize concrete requirements.

This is a crucial job for a CTO, especially in smaller companies.

What did I prototype?

Integrating a list of appointments from another vendor sounds like a simple ETL project. However, we must call multiple APIs and mash up data together. My job was figuring out which 7 APIs to call and the business logic around using that data.

The hardest part of my task was figuring out the business rules and an algorithm. I had to do this in code to figure out how to combine the data and get the reporting I needed. The output of my prototype was actually a spreadsheet of data to analyze!

We can now take that spreadsheet and finalize how we want to use this data.

Mission accomplished!

What my prototype didn't do

The goal of my project was to build something other than production-ready code. Instead, the goal was to hack together some code to do a proof of concept for calling all these APIs.

If we were going to use my code, it would need a lot more work to make it usable. Since I was building a prototype, there are many things my code doesn't do:

• Hard-coded credentials and URLs

• It wasn't designed with multi-tenancy in mind

• Nothing calls my integration code on a schedule

• No error handling or logging

• No configuration exists to configure this API

• No data from the API calls are saved anywhere

• No unit or integration tests

I didn't do these things because they weren't part of the goal. The other developers on my team can easily do these things for the final version. I also didn't worry much about making well-organized or clean code.

My app was a simple console, and the output was a spreadsheet.

Warning: Prototypes are rarely meant for production

Prototypes are not designed to be finished products. I just listed off a bunch of things mine didn't do. In a startup, it is common and fair to say that the software's first version, or MVP, is usually a prototype of some form.

You don't want to commonly hack prototypes together and then ship them to clients thinking they are fully polished products. This will come back to haunt you.

Remember that the first 90% of the project takes 90% of the time, but the last 10% also takes 90%! A lot of time is spent perfecting all the details of a project. You don't want to keep shipping things that are 90%, or effectively, 50% completed.

One of the best things a CTO can do is build the first 90% and let the team do the second 90% on critical projects. 

My prototype is actually going in the trash, and that's OK!

To make things even more interesting, I used a different programming language for the prototype than the team typically uses. I feel most comfortable using C# while the rest of our integrations are done in PHP or Node.js.

In a perfect world, doing the prototype in the same programming language would have made more sense. However, for a proof of concept and prototype, I accomplished my goal of proving how to do this with the tools I know best. ChatGPT might also convert my C# code to PHP!

The other good news is my code isn't going to production, so the team can't blame me when their crappy code blows up in production instead of mine! 😂

Sometimes a company needs a Visionary CTO to flex their technical skills and complete prototypes and other critical projects.