Cost of Not Having Continuous Integration & Deployment

No really, hear me out for a minute.

By now you’ve heard the terms CI & CD and that it’s the greatest concept since the espresso.  So as any natural and curious developer would, you began trying to understand what it is all about and how you can look like a superstar to your bosses and colleagues.  But this proved to be an extremely daunting task because you don’t control the product/project.

In reality it is suppose to be a daunting task otherwise it would be caked into a project for you.  Lets face it every project has separate and certain needs and trying to create a mold around that would only add to the complexity of the problems.

Nevertheless, I’m here to informed and cheer you on as I believe anyone can achieve CI & CD with a little perseverance!  The hardest part of this won’t be doing the work to get the bits flowing, but to convince you boss(es) and colleague(s) that this is a NEED not a nicety, so that they purchase the tools or allow for the time.  So I’d like to help you make the factual case so you can focus on what really matters.

I’ve previously gone through this process and was successful at the CI & CD and the selling to the “higher ups”.

Cost of Manual Steps

What do business people care about the most?  A good product? Yes.  Happy customers? Hopefully!  Enthusiastic employees?  Of course!

But at the end of a day, they care most about the bottom line of the business.  Therefore, we must make that our target when selling the process to the right people.  I’ll use a real world example that I’ve been apart rather than make something up.

Let’s say you are working at a company that has an established product and “process” that has been “working” for 10+ years.  Why would you ever want to change it?  Well when you start to break down this process you begin to understand that it doesn’t work as great as it could.  The “higher ups” believe the process hums along like a Hellcat Supercharged 6.2 Hemi, but its more like a MOPAR 2.2L I-4.  This is because there are a few select individuals that actually know how the 2.2L runs and if they are out or no longer with the company everyone is left scratching their heads.  If bad enough the company burns the entire team’s time just to get this process re/started.  But since “Frank” always needs his report, the select individuals continually added Gorilla-Tape to the 2.2L, which gets everyone over the hill (for now). 

Usually, this means that the team ignored Industry Standards and “just made it work”.  Which eludes that there the one or two individuals that have “tribal” knowledge on how it works.  Which then leads to an individual having to do 1-10 manual steps just to get the engine started, rather than turn a keep.  And if you can not get a hold of that individual on their vacation then your company cannot produce a product.

Starting to see the problem yet?

Not quite?

Yea but the cost is too much to swallow because we don’t know what it’ll take…

Okay, lets talk some numbers to put into perspective.  Lets, take Bob who is a Quality Assurance Senior and is currently the person in charge of testing and deploying the product out to the customers.  Bob makes 65K a year, which means he gets paid 31.25 (65000 / 2080) an hour.  A mediocre salary for what Bob actually endures on a day-to-day basis, but that’s not the point here.

Now the developers have notified Bob that they’re work is “checked in” and ready for testing.  So Bob begins the process of creating the necessary bits to test with; however, the first step takes about an hour.  Until now, no one has ever questioned “WHY?” it just how it was.  So now Bob waits an hour (31.25 paid) just for the bits to be ready.  Once that is completed, Bob has to then install the necessary bits on remote machines to simulate what is in production; however, Bob knows that this is a joke because the QA machine is 1/18 of what a production machine is capable of.  Because of this it takes Bob about a half hour to install the bits anyway (46.875 paid).  Mean while, the developer realized that something was left out by accident and informs Bob that he’ll need to do another “build”.  So Bob obliges and starts the process over again (93.75 paid).

Up to this point the company has just paid Bob ~100$ for waiting!

Lets stop and think about what this means.

  1. It takes roughly an hour and a half to go from developer to something testable (and that’s if the process doesn’t break down, which it will).
  2. Bob isn’t the only person waiting on a “build” to finish, so the additional analysts’ salaries should be included in the current paid amount.
  3. Obtaining multiple builds a day is extremely time-some and painful.
  4. The business spends a lot of money waiting.

Think about an entire year.  Let’s say a team does an average of three builds a day. That means that Bob is being paid 140.625 (46.875 * 3) a day to complete a “build”.

  • Weekly: 140.625 * 5 = 703.125
  • Monthly: 703.125 * 4 = 2,812.50
  • Yearly: 2812.50 * 12 = 33,750.00

    This is if everything goes perfect, which experience tells me with this kind of process it never will!

This is just one person’s cost to wait to be testing.  This doesn’t include the developer(s) who are waiting on feedback from the items Bob is trying to test.  Now think about scaling this current process out to a team double, triple, quadruple the size.  This is in-deterministic equation since there is no possibility to predict the future!

What Does This Mean?

It means that you need Continuous Integration & Continuous Deployment, unless your company likes throwing money in the wind!

Pretty accurate when you think about it isn’t it?  Why is this important for you the developer?  Well think about the money that their paying Bob to sit around and wait, if Bob could improve this process he has a card in his deck to catch some of the money on his next review!

Challenge those around you how important it is to “pull a lever” and have a testable product.  In the 21st Century there is no reason to be waiting for code to compile for an hour and installations to half that time, let alone having a human manually execute all these tasks!

Now there are a plethora of options when designing a Continuous Integration &| Continuous Delivery system.  Personally, I find it more beneficial to strive to use current Industry Standards for you frameworks.  This way individuals that come behind you in another 5 years won’t be cursing your name every 15 minutes.  Nevertheless, strive to have a prototype running when you go to pitch your plan to the necessary individuals.  People are naturally more visual and makes presenting your case easier, in addition remember talk NUMBERS, NUMBERS, NUMBERS.  If you can show that a process taking over an hour can be automated down to even 20 minutes, you can prove how much money the company will save and how much more work will get done throughout the year!

 

Till next time!