Starting With Production in Mind

How do applications typically start?

Think about how applications are typically developed.

Applications often start out as a proof of concept. There is a known problem, and you are tasked with finding a solution to that problem. The proof of concept is created to prove that it will solve a known problem.

Often, a proof of concept involves learning a new technology. For example, the technology may be a new framework that has not been used before, or a new platform that has not been previously deployed. Whatever the case, there is usually some type of new technology involved in development of the proof of concept.

You then build out a minimum viable product (MVP) of your solution to quickly provide value to the business partner and deploy it to production.

While the application initially meets the needs of the business partner, it also may have lurking technical debt.

What technical debt accumulates with this approach?

You proved your proof of concept does in fact solve the problem, and your MVP is in production. But wait…

Lack of Tests

Did you take the time to write any unit tests, integration tests, or end-to-end tests while you were building out your proof of concept? If not, what confidence do you have in your code? How do you know you didn’t break existing functionality as you begin building more features into your new product if you don’t have tests? How do you actually know your code works?

Code Structure Issues

You may have introduced software architecture problems into your code if unit tests were not written. There is the possibility that you introduced tightly-coupled code with low cohesion. These problems can often be detected as “code smells” when you are writing code and tests together, either test-driven or side-by-side testing. This way, you can detect problems early and fix them.

Security Issues

Did you run any security scans during the building of your proof of concept to find out if there are any vulnerabilities in your code or in your code dependencies? In the example above, you may have introduced brand new technology in your application. Does that introduce any security issues? As you go to production with your MVP, will you bring vulnerabilities along with it?

What’s the Big Deal?

Your application is in production and meets the needs of your business partner, so what is the big deal?

You are likely going to face some future struggles if your application has accumulated technical debt from its inception.

While you may have felt like you were going fast in the beginning, chances are your software delivery pace is going to slow down. If you continue down the path you started on, you could easily end up with an arbitrarily structured, sprawling, messy, pile of spaghetti code. You have likely seen this type of code, or even created it yourself, if you have coded for a period of time. This “big ball of mud” becomes more and more difficult to add and extend code. This code is likely fraught with bugs and software architecture problems, resulting in production support issues.

If your “big ball of mud” slows down your pace of software delivery, then it also impacts your ability to put new functionality into the hands of business partners. In most cases, business partner confidence in your product is largely based on your team’s ability to regularly deliver new, quality features. That confidence in your product can begin to erode if your software delivery performance begins to decline because you are mired in code architecture issues, software bugs, and support issues. All of this can negatively impact your team’s morale.

Starting With Production in Mind

Before you write a line of code, take the necessary steps to prepare the way for your application to go to production.

1. Build your continuous integration pipeline

   This pipeline includes the build, test and security scans of your code. It could also include:

   • Deploy your code to your test environment
   • Write automated tests
   • Prepare your deployable for production
   • Create an evidence of test package

2. Build your continuous delivery pipeline

   This means you build out your production deployment workflow, for example, GitOps.

Ready to Code

Now, you are ready to write your first bit of code! This usually means more than a line of code, but this is the very first deployment. This might be the homepage of your application for a User Interface (UI), or the first endpoint for an Application Programming Interface (API). Follow the positive engineering practices your team has developed: Make sure you have proper code coverage, perform code reviews, and have a good automated test suite. If the team hasn’t developed these practices, now is the time to start!

Commit the code, push it to your branch, follow your team’s defined workflow, and merge it to main. At this point, the continuous integration pipeline should kick in. This is the time to work out the pain points with your build to get everything running smoothly. Once you have a successful build, it is time to go to production! Run the continuous delivery pipeline and again, work out the pain points to help ensure you have a smooth path to production.

Why should I do this?

1. From this point on, part of your “definition of done” for every agile story can be “Go to production!” You have determined all the steps to production from the very beginning with a small code base. You have laid the foundation for business partner satisfaction, motivated your development team, and created quality software.

2. There is a feedback loop from the very beginning. When you merge your code to the main branch, your pipeline will help ensure you have not broken any prior functionality, your software has quality, you have not introduced any security vulnerabilities, and your code is production-ready.

3. You create a constant feedback loop with your business partner by deploying your code to production after every agile story. This helps ensure that the solution you built is what your business partner wants. As your business partner sees this solution unfold, it builds confidence in your team’s ability to provide them with what they need. In turn, having a satisfied business partner energizes your team and motivates them to continue to deliver. There is a joy and delight in satisfying your business partner with the solutions you create.

4. Your mindset changes when you know your code is going to production as soon as you merge it to the main branch. There is a positive psychological effect of knowing your code is going to production when your agile story is done. You take more care in practicing engineering disciplines (e.g. tests, code reviews, code quality scans) to help ensure your code is “production-ready.”

Conclusion

Consider starting with production in mind the next time your team ramps up a proof of concept or begins to build out a new application. You may not feel like you are going fast enough in the beginning, but in the words of the renowned author and software engineer, Robert C. Martin, “The way to go fast, is to go well.” The way to go well is to build those quality practices into your development process from the very beginning. You will be much more equipped to serve and delight your business partners!

To learn more about technology careers at State Farm, or to join our team visit, https://www.statefarm.com/careers.