The Two-week COBOL Sprint: Software Development Bottlenecks
Let’s say you’ve been making progress with your DevOps initiative. You’ve significantly sped up software delivery, but you haven’t seen much of an improvement during the last few iterations. “Is this as fast as we can go?” you ask.
You discuss your fears with others and discover their DevOps teams are going four times faster than yours. This is unnerving. It’s probably time to look for software development bottlenecks—the kinks, sharp curves, slowdowns, roadblocks and just plain silliness preventing you from increasing speed with the two-week COBOL sprint.
For the last blog post in my series, I’m going to discuss some of the actions you should take to eliminate common software development bottlenecks. Doing so will help you improve the speed and efficiency of your two-week COBOL sprint.
How to Eliminate Software Development Bottlenecks
Standardize Systems and Infrastructure
If you have various system configurations requiring unique processes, you need to push for standardized systems. Standardization allows you to automate things more easily because you write the automation once rather than for each configuration. Additionally, you can standardize manual processes and have the flexibility to move people around since more people understand the standard system.
Automate, Automate, Automate
Manual unit testing is a limiting and error-prone software development bottleneck. Automated testing is required for developing faster. It enables detailed testing which is often impossible to do manually. You may have to create some test stubs to do it, but once automated unit testing is built, nothing will speed up your processes and boost your confidence in releasing changed code more.
Automate Integration Testing
Automated integration testing flushes out issues related to incorrect system versions and incompatible software components. Eliminating this software development bottleneck should happen in your integration or pre-production phase.
Subsequently, automate your smoke test, which should tell you within minutes if there’s something fundamentally wrong after deployment. You should know in less than an hour if you’ve failed the smoke test and shouldn’t go to production.
Automate Configuration Management
If possible, do an automatic a comparison between what’s in production and what you’re about to deploy. It’s faster to automate the comparison and look at the exception cases where something has changed. A quick look at comments regarding the change in the source code management systems will validate the differences.
Careful management of configuration files should include:
- Manage configuration files in source control system
- Version configuration files as part of the release
- Automate the comparison to production to eliminate forgotten configuration changes
- Automatically deploy configuration files when you release to QA, pre-production and production
Use Variable Substitution for Deployment Environment Settings
This eliminates the software development bottleneck commonly referred to as “I forgot to change that configuration to the production setting.” To avoid this, if possible, store the environment variables in source code management and deploy them as part of the release before anything else is deployed.
Learning is expensive—perhaps more expensive than manual testing—and when you have to continually relearn something it becomes a software development bottleneck. Once you’ve learned something, you need to capture the lesson learned and incorporate it into your automation system. It takes discipline, but it pays for itself many times over.
For example, if you learn a production memory requirement has increased on a system, update the new memory requirement in the configuration file. Save the configuration file in source control and deploy it to all of your systems, which should be standardized now, so you don’t have to relearn this lesson with other unmanaged configuration files on various systems.
Identify Resource Constraints
Do you have too few systems to test on? Do you have too few licenses for tools? These resource constraints are software development bottlenecks. Fortunately, automation makes much better use of scarce resources.
For instance, automated testing typically reduces the number of necessary test systems. Just look at the things you have that are moving faster—they lock up resources for less time and, chances are, save you money.
Measure Duration of Process Steps
The theory of constraints suggests a chain—in our case, a DevOps toolchain—is only as useful as its weakest link. What’s the slowest process in your software development lifecycle? What’s the fastest? What approval process takes the longest? It’s hard to eliminate the software development bottleneck of a slow process if you don’t know what steps are slow.
Pay Down Technical Debt
Like everyone, you have code containing bugs. This technical debt is a software development bottleneck that slows you down because it forces you stop your current work and fix the mess a program creates when it abends. Technical debt causes operations grief because they have to restart and rerun programs, which costs time and money.
The first step to eliminating this software development bottleneck is identifying the worst code and programs that need fixing because they abend. Fortunately, there are tools that point you to the line of code that’s abending, making it a faster fix. You can probably justify the cost of paying down technical debt in bad programs with the savings gained by avoiding program reruns.
Build the Right Deliverables, Work on the Right Requirements
Once code is created, even if it isn’t used it’s still maintained for years. Building the right stuff improves throughput, improves your business and eliminates rework. A bad requirement costs you a whole release cycle, and that’s a major software development bottleneck.
In an Agile environment, development and business stakeholders should identify the most important items to work on next. If development is unclear what’s important and what the requirement is, they may build something useless and be forced to rebuild, retest and re-deploy the right thing.
Moving Forward with the Two-week COBOL Sprint
Eliminating software development bottlenecks is a process you should continually circle back to each time you hold the two-week COBOL sprint retrospective meeting. By doing so, you decrease the time spent solving old issues and instead spend time automating more of the software development lifecycle. This gives you more time to focus on things that matter to the business as you develop and work towards the delivery of better products.
As we’ve learned throughout this series, the two-week COBOL sprint is the result of implementing the Agile/DevOps culture, processes and tools required for an enterprise to develop and deliver mainframe software faster for the digital economy. You can read more on this set of culture, processes and tools below:
- “The Two-week COBOL Sprint: Why Mainframe Shops Need It?”
- “The Two-week COBOL Sprint: How Agile Mends Broken Trust”
- “The Two-week COBOL Sprint: Having a Critical Conversation About Agile”
- “The Two-week COBOL Sprint: How to Build a Scrum Team”
- “The Two-week COBOL Sprint: Developing a Process of Continuous Builds”
- “The Two-week COBOL Sprint Agile Feedback Loops”
- “The Two-week COBOL Sprint: Deployment Automation”
Use this series as your guide moving forward, and as you make progress with the two-week COBOL sprint I hope you begin to notice other, deeper-level aspects of the development process where you can make your own adjustments according to the context of your enterprise.
Latest posts by Glenn Everitt (see all)
- Reducing the Danger of Shadow IT with DevOps - May 15, 2018
- Living in a ‘More Data, More Problems’ World with Unit Tests - September 6, 2017
- No Mock Objects for Your Mainframe? Create COBOL Program Stubs - March 23, 2017