Until it's in Production, it doesn't matter ...

It doesn’t really matter until it’s in production!

Yep, we can all work hard, play and enjoy what we are doing, but it doesn’t count until we’ve packaged it all up, wrapped it in a bow and moved it into production.  But, that being said, how many of you are planning your implementations vs just moving them into production.  And, yes, just moving them into production is a plan - not, a very good plan, but it is a plan.  Similar to my comments on no process being a process.

So, let me ask this question - if you’re “just moving it into production”, how much time do you spend afterwards cleaning up the mess:

1. Oh, forgot to update my stored queries to account for the new data elements that I implemented in my users table.
2. Oops, what’s that, the billing app doesn’t recognize the new billing codes that were implemented along with our new service?
3. Argh, Bob didn’t tell me that I needed to move that property file into the models directory.
4. Why didn’t someone tell me that the XML configuration file needed to be updated?
5. Great, we forgot to begin replicating the new data elements into the warehouse, management’s reports are all busted.
6. Are you kidding me, we’re getting calls saying that the install is bombing out - they’re getting some message about a missing property file.

When I speak with students, I try and get them to understand that coding is actually a small part of what they need to be concerned about as a professional software engineer.  They need to think through all of the phases of the lifecycle.  Side note: a frustration point - our higher educational institutions for the most part skip a great deal of the software development lifecycle.

If students are going to successfully transition into the workplace, they are going to need to understand and hold themselves accountable for the entire lifecycle - that means everything from the initial vision all the way through to ensuring that the final product can be installed in a production environment or shipped out the door/over the internet to be installed by the final end user:

1. Scoping/Discovery: In many organizations, the software engineers work alongside partners across the business organization to define what will/will not be included within the specific release.  Today, it is difficult for non-technical resources to solely make these decisions as technology is pervasive within the business and the technical resources understand the various capabilities and constraints of the systems being developed/modified.
2. Requirements: Some organizations make it the responsibility of the software engineers to drive discussions and document the requirements for a particular application.  Even if the software engineers are not responsible, they need to understand how to read the requirements, clarify any outstanding/open issues and use the requirements to drive the rest of the process.
3. Technical Design: Yep, before you start coding you better have a plan in place.  Most developers want to hit the keyboard and start chunking out code.  As much as I like to code, I’ve learned over the years that planning is the better part of coding.  It will more than pay for itself on the back-end.
4. Coding: Finally!  Yep, this is where the rubber meets the road and you get to do what you love to do.
5. Testing: In previous posts, I’ve talked long and hard about testing - in short, don’t forget or you will pay for the transgression.
6. Implementation: I’m done coding, time to move on to the next project.  Hold up there, partner.  Until someone is using your code you’re not going anywhere.  Yes, now that you’re done, you need to put the finishing touches on that present, wrap the bow and hand it over to the users.

See, it’s not just about creation of something wonderful.  It’s also about ensuring that the people that originally wanted this beautiful thing created, actually get to use your masterpiece.

How many of us actually sit down ahead of time and plan how we are going to move our code into production or how we will create the install packages that we deliver to our customers?  How many of us actually execute the implementation plan to ensure that we have identified every step, every property file, every change to the database, the removal of files that are no longer needed, the removal of data no longer needed, the removal of property files or registry entries no longer needed?

And, by the way, you also need to plan a graceful fallback!  If you’re in the middle of the implementation and something starts to go bad - can you back out?  How do you back out the changes?  Can you put Humpty Dumpty back together again so that your users can go about their business?  More importantly, have you just shut down the companies ability to make money?  Don’t place yourself in a career limiting situation just because you didn’t plan.

None of this is rocket science, but if you don’t go through the exercise you will get caught.  You may be able to move minor projects into production without too much concern, but I guarantee the bigger the project, the more interconnections with other systems, you will need to have a plan.

Hey, but I’m on a 2 week sprint and the system automatically performs the build and moves things into production.  It does it in the middle of the night, nobody even has to be there.  Has it ever failed?  If it does, what will you do?  Can you promise your manager that you’re not going to take the site down for a day because the auto-build/deploy process broke?  Have you ever walked in the morning after one of your automated installs to have calls coming in from your user community because something isn’t working right?

I work for an organization whose systems must be accessible 24x7x365.  We don’t get downtime to perform installs on our OLTP engine - we need to replace pieces in flight without interrupting our ability to handle transactions.  Luckily on our other applications, we can take small outages in the middle of the night to install our code.  That said, those windows are extremely tight and we must have things planned extremely well so that we don’t waste time and that we can recover quickly if something does go sideways.

The teams that I have the pleasure of being associated with, plan extensively to ensure that our OLTP engine is always available - even when we are installing new pieces of code.  They also ensure that on our offline systems the outages are as small as possible.  This takes time and energy to do right.  Yes, we have automated some of the pieces, but there are still steps we take manually to ensure that we have proper gating through the implementation process.  We test our implementation plan, and if it is a critical system, we’ll actually test the fallback plan to ensure that we can back changes out quickly.  The teams are on-site for the implementations and we are monitoring our systems to ensure that transactions continue to flow and that entries propagate through the various systems accurately.  Monitoring is a key driver for the success of our installs - there are typically checkpoints along the way where we validate certain events across the system.

So, the question is, how are you your teams implementing code into the production environment?

Tags: #SDLC #softwaredevelopment #qa #lifecycle #implementation

If you'd like more information on my background: LinkedIn Profile