Matt: Greetings. Thanks for joining us for Chapter Seven of our series, Building a Better Software Delivery Platform. I’m Matt DeLaere. Let’s say hello, the star of the show, Compuware Executive DevOps Solution Architect, Rick Slade. Hi Rick.
Rick: Hey, Matt. How are you today?
Matt: I’m good, good. Each week, our podcast episode and Friday Q&A sessions cover a different aspect of the modern software delivery system. This week, we’ll be talking about transitioning to a modern software development interface with our special guest, Compuware Group Product Manager, Steve Kansa. Hi, Steve, thanks for joining us.
Steve: Hey, Matt. Hey, Rick. Great to be joining you today.
Matt: It’s good to have you. So, Rick, to start us off, can you talk a little bit about modern interfaces and explain why they’re important to what we’re trying to achieve?
Rick: Yeah, glad to, Matt. And I’ve got to correct you on one thing, Matt, with regard to the star of the show, it will definitely be Steve today. When I first came to Compuware, Steve’s one of the first guys that I talked to, and I came in as a DevOps guy, that’s where I spent a lot of my time. But it was with a different company and with different tools and there were a lot of things that I needed to learn, and I’m still learning. But I’ve been in the business, development business, for a long, long time. But Steve is just a wealth of knowledge with regard to how developers today are working and how to leverage a lot of the tools that will have a huge impact on software delivery from a velocity standpoint and from a quality standpoint. So, when I first got the Compuware, I spent some time with Steve, and he truly is an amazing resource for all of us here and for our clients.
To your question, and one of the reasons that I wanted to add the modern software delivery interface as a part, as one of the topics for our podcast was the criticality of that, and there is a transition that is occurring in the marketplace today, especially for those of us who’ve been around mainframe software development for a long time. Most shops that I go to, or a lot of shops that I go to, in trying to help them develop a transitional strategy improving software delivery, I still see a lot of green screen software development occurring for mainframe developers. It’s changing, and we’re starting to see that the masses move, but there’s still some green screen development, and from a business standpoint, it’s going to be important that we or that they are able to provide an ecosystem or software delivery environment that’s not only going to be attractive to new people coming in to support applications, and specifically those applications that require interface or interaction with the mainframe, those organizations are going to need to provide an environment, an ecosystem, and the IDE or the interface into work is a huge, huge critical component to that, and I thought it necessary to talk about that.
Our customers, the industry, needs to start thinking about what developers need in order to be more productive, and talking with Steve in prior conversations, I’m not exactly sure what that’s going to look like in the future, I’m sure Steve will has some ideas and we can ask him that, but the critical component is having a productive environment, and so does that mean a single IDE, or does that mean letting developers leverage what they can be most productive at with regards to the specific task at hand? There’s a lot of discussion in the marketplace and there’s a lot of tools coming out to support that, so I think that’s important. I think it’s important that organizations start to think about what that interface to work looks like. Now, one of the things that I like as part of Agile is that we want an environment to where developers can make code changes, create new code, and be able to move from platform to platform. Now, that sounds certainly a lot easier said than done, but it’s something that we need to be thinking about because moving… resources continue to be short, and costly, and so the business has got to figure out, how do we provide that environment that will allow us to bring in new resources that may not have experience with traditional green screen software development for the mainframe. How do we bring those people in, and how do we give them an environment that will allow them to be productive quickly. And then how do we take existing developers and provide them an environment to where they can start to transition or be able to deliver code to multiple platforms, and regardless of the targets?
So, I think those are important questions, and one of the reasons I wanted to talk to Steve and have Steve on the program today. So, I’m going to stop talking. What I’d like to do at this point in time is to introduce Steve Kansa. Steve, my welcome to the podcast. We appreciate you being here today.
Steve: Well, thanks, Rick. And just to share a little bit about me and to touch on some of the points you brought up, so I’m the group product manager for our application development suite at Compuware and I lead the teams that are responsible for the IDE aspects with Topaz, source control management, debugging, fault analytics, and also our data capabilities within the suite.
And you mentioned having talked to me when you first came in to Compuware… I’ll share a little bit about my background and how I do kind of have a slightly different background than a lot of people that have been in the mainframe space for a while. So, when I first left college, I was approached about a job in the mainframe, and to be perfectly honest, I ran away, screaming, I wanted to work on web applications as the dot com boom, and I had stayed away from the mainframe. I certainly knew about it, I knew it was really at the heart of enterprises, it did amazing things, but being young, I wanted to work on things that were new and shiny. And I ended up where I’m at today because I was approached about the opportunity at Compuware and what really excited me and talking to Sam Knutson and Chris O’Malley about the opportunity was their vision, their goal of trying to mainstream the mainframe and make it just about syntax. I can remember sitting in Chris O’Malley’s office and he talked about using things like JIRA in doing Agile development on the mainframe, and I had a long history with Agile and working with cutting edge DevOps tools on other platforms, and I knew that the history of the mainframe, I knew having worked on a bank conversion and seeing how mainframe development was done a decade ago, I did have some experience. And I knew there was a huge opportunity to improve, and it was something that I looked at as this awesome challenge, if I can help change the course of how mainframe development is done, that would be just a great, great thing to be involved with.
And it absolutely has been a great thing, so it’s been very exciting. I remember when we first started our path five years ago by looking at how can we integrate with Jenkins and SonarQube, and being able to show that to someone, a customer, and for the first time being able to see COBOL code scanned in SonarQube, it was just like a light switch turned on for people, and you could understand that there are modern ways and you can connect this platform and really mainstream it into the way development is done on other platforms. So, it’s been a great journey.
The Modern Software Development Interface
Rick: I didn’t want to mention age when we started the conversation… I remember coming and visiting you and talking to you, your hair is definitely a lot different color than mine, but it’s… The knowledge is certainly there… Let me ask you this question to kind of get to kick things off, talk to me a little bit about, I guess, Steve Kansa’s definition of the modern software development interface, what it looks like today. And a term that’s interesting to me is, is integrated, and I know that at Compuware, we spend a tremendous amount of effort from an architectural standpoint, from a design standpoint, making sure that the capabilities needed for software development are delivered so that they can be leveraged easily and our own Topaz interface. But talk to me a little bit about, with regard to your ideas about the software development interface that’s inclusive of the mainframe and how you describe it and why integration is so important.
Steve: So, I think there’s multiple aspects there. Ultimately, you want to arm your developers with something that’s going to make them as productive as possible, and you want that to be a truly integrated experience, so they’re not having to jump between disparate tools or struggle to go from one area to another. So, whether you’re going from analysis to code to debugging, you want to be able to flow through that, keep people in a productive flow, and do that in a manner so your developers are being more productive, because really they’re ultimately at the heart of your enterprise. There’s the phrase, “every company is a software company,” so you need to think about, “How can I make my developers productivity at its max?” And the IDE, the integrated development environment, is a key part of that.
You also want to think about your workforce and how you want that workforce to evolve, what are the barriers to bring people into that workforce? So, that’s where the modern aspects of how you’re approaching your integrated development environment can be important, because I guess I’m past the age where I’m always chasing the brightest, shiniest new object, but that’s certainly a factor that comes into play when you’re trying to bring in new talent into the mainframe, and it is something that you need to keep in mind. And we want the mainframe platform to succeed because it’s so critical to today’s digital economy, in order to do that, you have to face things like retiring workforce, and you have large applications that can be very hard to understand, so you want to create an environment that addresses all those aspects, brings it together, so you can ultimately deliver for your business.
Rick: Yeah, and I think that you said something earlier that I agree with, and I talk to my customers, consult with them, that I think is so important is that ability to get people up to speed quickly. And if you’re trying to bring in new resources to replace retiring resources to support these applications that are targeted for the mainframe, being able to provide them an environment that they are comfortable with, that they’ve got some experience with, is certainly more attractive to them when you’re trying to bring in new talent. So, I think that’s a huge part of the decision-making process that IT organizations are having to make.
Steve: Just along those lines, I think it’s a critical point for the mainframe. It’s something that has been in the news recently in terms of the crisis with the global pandemic, and you can look at that in a couple of different ways; you can kind of have a defeatist attitude towards it, and that’s ultimately, it’s going to lead the bad outcomes for the people, the company; or you can really look at it as, “Let’s embrace a new way of working. Let’s figure out how to overcome these challenges.” So, there’s definitely… You can have a bit of a fork in the road and you’ve got to decide the path you want to go down, but continuing to work in the same environment with the same tools that have been done for 20, 30, 40 years, you’re really setting yourself up for a crisis, and we’ve seen that play out a couple of times.
Rick: I couldn’t agree more. When I spend time with clients, I actually, I make the statement, that it’s not that the tools, these green screen interfaces and the methods by which we’ve developed software for the mainframe over the years or are inherently bad—I wouldn’t say that. They’re good, and the reason that you have to confess to that is the stability and the longevity of some of these applications that are in place. So, we built good software using the tools, the problem that I think that we’re experiencing and that we have to overcome in, to your point, is that we’ve got to deliver the same level of application quality at a much higher speed, and I think that these new tools and the capabilities within these tools give us that opportunity. But, you’re right, change is hard, and I think it’s just, it’s going to require commitment from the organization and a willingness by the developer to consistently or continuously look at different ways, better ways of doing their work. And I think these type of tools are critical to that.
Key Features of Modern Tooling
I know that you spent a significant amount of time in the last few months, maybe longer, looking at editors and upgrading our editor within our tooling. And I know editors, there’s not a lot of sexiness in talking about editors, but I did want to ask you about what do today’s developers want into their editor, and in their debugger and in their data management tools? What are the key features within these tools that developers are looking for today?
Steve: At the end of the day, I think what everyone wants is a tool that will make them more productive, and the editing experience is something that we’ve been investing heavily in. We had an editing experience that was a good editing experience, but what happened was, it sort of locked in a period of time and we weren’t able to advance it, so we’ve been investing heavily in that to get it to a point where we can now start to add in some of the features that people have asked for for years that just weren’t able to be accomplished in the past. And really at the heart of an IDE, is the editor. And it’s definitely a critical thing. If you look at how work has been done in the past with ISPF development, the ISPF editor is something that was developed over the course of many, many years.
It is an environment that If you’re experienced in it, it can be something that you become comfortable with, and transitioning into a new editing experience can be something that people frankly, they have to get over a hurdle of learning, they have to be willing to embrace new ways of working. But once you get over that, you start to unlock a lot of the tremendous value that can be brought from a modern development experience: being able to quickly jump to sections of the code, hide sections of the code, being able to find things very quickly across your IDE, the program analysis capabilities to be able to take all that logic, and there’s some crazy amount of programs that have hundreds, thousands, tens of thousands of lines of code that people are trying to maintain, and what your IDE should be doing is making that a simple process, something that is not going to be something that turns people off or you become so scared to modify your programs because there’s so much there and you just can’t understand and break it down, and you don’t understand how the flow of logic happens, or dead code is left within programs because people are just scared to modify them. And that that type of technical debt is something that can really weigh down an organization or the course of time and make it harder and harder and harder to go faster. So, you want your development environment to make it really easy to be able to modify those applications and take care of the technical debt, be able to support new business requirements in them.
Rick: Yeah, and that integration is just so important and that’s to me is what I just, quite frankly, where it’s better at in a tradition graphical environment versus traditional green screen. I had essentially everything I needed as a green screen mainframe developer, but time required to pop in and out of different screens to get work done, it doesn’t seem like a long time, Steve, to move or to navigate through those different screens to get work done, but it takes time. And in a modern graphical environment that transition from one work objective, which may be editing code to another objective, which may be get manipulating test data to support some tests or a debugging effort that you’re getting ready to exercise. That little bit of time. over 50 developers over a year period has a substantial impact. And it can make a significant difference.
With the last company I worked at, we did a significant study to try to understand the value of a modern interface versus the traditional 3270 ISPF/TSO interface, and it’s not that they’re bad, but what we found, we created a set of tasks and they were traditional tasks that the developer would typically execute on a regular basis, and we did time studies to look at how long it took to do 100 tasks. And we took those same hundred tasks and provided a more modern interface to that work, and the results were incredible. Not to oversell it, but were incredible. And what we did is we took developers who had no experience in an ISPF environment, developers who had less than five years, and then guys like myself, who had more than five years development, and we had each of those groups run through that effort, and for every group, the through-put impact was very significant in how fast they could execute those tasks. I just… Again, it’s not so much the work that you’re doing, the actually editing of the code, but it’s the time savings that some of those features provide you that you talked about. But a lot of it is about transitioning from tool to tool and having an integrated environment will certainly save you time.
Steve: Yeah, and another point in terms of transitioning is people, sometimes they want the easy way out, they think, “Okay, I hear what you’re saying, integrated environments, the way to go. I’m going to give my developers an integrated environment, I’ll drop it in, and all of a sudden I’ll get the productivity gains.” That’s the easy approach, but it doesn’t end up working out well. You really have to… It is a transition, it is a change, and you have to support that change both from a management perspective, and then you have to consider the human factors there, where people do become comfortable in a way of working, and human nature is that you will resist change and you’ll stay within the patterns that you’re comfortable with. Well, that can be a recipe for a lack of success in terms of achieving the true productivity you can get out of the tools. You need to look at it as a change transition. You need to support that change, you need to have champions for that change, and you ultimately need to start to consider changing the work that’s done. If your goals are to release more changes more frequently, you have to get to the point where you’re not just accepting that, yep, I’m going to do that change, I will spend two or three weeks analyzing all of the changes that need to be made, then we’ll start making that change over four to five weeks, and then we’ll start testing that change. You really need to… You need to look at that and say, that’s no longer the way work needs to be done. We need to be able to break that down, we need to do very quick analysis, we need to make an incremental change, get that change tested, and iterate on that through something like a Scrum methodology where you’re continually then tackling the next change and the next change. The analysis can’t be done by a separate group from the developers, from the testers, you really need to bring it together in a way that ends up changing the work that’s done, and the tools are in place that support that work.
Rick: Yeah. And talking about that change, it is hard. I have seen this with several different developers.There are a lot of developers, there’s a lot of mainframe developers who embrace this type of change, but there are folks that find it more difficult. In your experience with the tools, is there anything that can be done to make that transition easier for the guy like me who’s been writing code under TSO/ISPF for 15, 20 years. Are there things management can do, are there things from a technology that can be done to make that transition easier?
Steve: You know, I think from a management perspective, again, you look at it from… You need to invest some time, you need to put in the right support processes, you need to make sure that training is available, and you need to realize that you’re going to invest that time up front. You’ll go through a transition period, and then as that transition period ends, you’re going to start to see those massive productivity gains. There is a Forrester study we did, that’s out published on our website, that talks a little bit about this, and the impact, a lot of it is related to the impact that the automated testing brings into the mix in terms of productivity change, but it does talk about the initial dip and then the big gain in productivity that occurs. So, as management, you do need to be able to support that, you need to allow for that transition period to occur in order to get the payoff.
Matt: Rick, you kind of asked about particular developers who are used to doing things a certain way. Iin terms of the whole enterprise, so you have hundreds of developers, would you implement the IDE or any changes to it all at once, or what do you do it by groups, as we’ve talked about in the past, with the whole software delivery system?
Rick: Let me… I’ll take a shot and then I’d like Steve’s thoughts on it as well. I think most people now who listen to the people, who have listened to the podcast, know that I’m a believer in leveraging Agile means, and incrementalism to roll out, or to implement essentially any new technology. I’m not a big believer—now, maybe I’m wrong, this is just based on my experience—you roll new technology like this out to everybody at one time, I think that that creates a couple of problems. I think one, it becomes a nightmare to support from a time perspective and a resource perspective, and obviously a cost perspective. And so, I think that’s an issue from a support standpoint, because change can be difficult and there will be a need for what I call “over the shoulder support,” so no, I’m not big into rolling it out all at one time.
The other thing that I think has an impact on that by using incremental methods to roll the software out, you give yourself the opportunity to learn a lot about what works and what doesn’t work, quite frankly. And then you can leverage those learnings as you scale and as you begin to roll out the others. So, like I said before, I’ve thought like this for a long time now, I think that you use Agile techniques, you define work to be rolled out, you leverage the traditional two-week sprint to get that work done, you roll it out and you do it incrementally. I think that gives you the best results. And quite honestly, I think it shortens the overall time to be effective with the technology, if that makes sense. Steve, your thoughts on it?
Steve: Yeah, I 100% agree. I think the ability to incrementally roll out and learn is a huge thing. Particularly when you get into larger organizations, you’ll get… in a big bang approach, you’ll get pockets of resistance. If you’re incrementally doing it and building on success, it makes it much easier to look at naysayers, or people that are resistant to change and say, “I hear you, but in this area, we’ve already been successful, we’re seeing these results.” It just makes it a much simpler process and it makes it something where you can get immediate benefits in some areas and continue to roll that out to the other areas in a much smoother process. So, I think that definitely is a recipe for success that we’ve seen at multiple customers going through these types of change.
Just to add on to that, this is a never-ending journey. You think about… You have something that’s in a state that’s been developed over 30, 40 years, you’re going to start to change that process, you think about Compuware, for instance, is putting out new releases every 90 days. Every quarter, we have new functions, new capabilities that are available, new products that are available. That change cycle is something to get very good at and get good at rolling out, adopting new things, tackling the next horizon, continually.
The Impact of the IDE on Automation
Rick: There’s a question that I was thinking about today, Steve, and I have my thoughts on it, and I’ll share those briefly, but I’d like to get your thoughts on the impact that the IDE or the development interface has on testing automation and delivery automation, if it does. Typically, I think a lot of people could make the argument those are two separate initiatives, but I’m thinking that with that IDE, you want the ability within that IDE to very quickly being able to create your test cases, your test case scenarios, and you want those capabilities and those features as part of that interface as you’re building that code.
The modern developer, in a lot of shops that I talk to, not only are his finished means working code, but it also means working test cases, and so my thinking is that interface needs to be integrated. I’m not sure that’s the right word, but to make it as easy as possible for that developer to create not only the finished code, but also other assets that are important in the automated delivery of that code to a production state at some point in time.
So, let me ask you your thoughts on the impact of the IDE or the interface to testing automation, delivery, automation?
Steve: They… If you think about the development cycle and what drives that cycle as you’re changing code, the quicker at the point you’ve changed code, the quicker you can get feedback on that code, the faster you can go. So, if you think about, I’ve written code, is that code… Are there potential syntax errors in that code that I want to know about right away, so I don’t waste the time of trying to compile that code. Is that code of the quality standards that it needs, then you take it to the point of automated testing, does that code function the way that it’s supposed to function? So, I think the IDE is critical in that, and you do have to think about the automation because ultimately you want to be able to feed the feedback to the developer as rapidly as possible in different layers of that feedback. So, the IDE has a key part of it, and then the other aspect that you have to consider is at the point that developer’s complete with that and then they then move that code to the next level, what does your pipeline look like? Having an automated pipeline is a key thing in order for you to speed up your velocity of development. So, that’s another key aspect to think about in modernization is, a lot of organizations, there’s a lot of manual steps that are done in each one of those processes for feedback to the developer, and then their pipeline is a series of manual steps, often across many different groups, and that slows down the ability to deliver things quickly, and the other thing it does is it robs time away from your developers.
Yeah, we have a customer that did analysis of the time in manual, the time in manual steps, the developer spent promoting each change, and what they’re able to do with our technology is they took that time out, 95% of that time went away. It was automated away. Part of that remaining time could also be recovered as well, but since they had just put in that pipeline, they’re waiting a little bit just to give people the comfort that they really truly didn’t need any more manual stops. But, you think about that, you’re talking about hours, if not more, of developers time per week recovered that can be spent on things other than just kind of wasted manual effort. And those are the types of productivity gains you can get as you modernize. It really can be a huge benefit for organizations.
Rick: Yeah, and I think that that integration and access to that information via the developers interface environment is just critical and of those things that our customers and hopefully listeners are thinking about as they start to think about that transition.
Steve, man, this has been awesome. I could do another one. In fact, we ought to do another podcast at some point in time. I’m talking to you, so many things that you’ve taught me and I appreciate it, I appreciate your time here today, talking to us about the importance of the modern software developers interface environment, and thank you very much. So, Matt, I’ll let you close us out and we’ll go from there.
Matt: Okay. Yeah, that was a great conversation. Thanks, Rick, and thanks again, Steve, for taking the time. Thank you also to everyone listening. If you have any questions about development environment or any aspect of the software delivery system, please join us this Friday, 11 AM Eastern Daylight Time for Office Hour with Rick Slade. It’s a live online session, you can ask Rick your questions. You can set a reminder for yourself for that at https://www.compuware.com/goodcoding/. And while you’re there, you can also find all the episodes in this series and past Office Hours. You can also submit your questions on Twitter, using the hashtag #goodcoding. So, Rick we’ll see you Friday, and until then, can you take us out?
Rick: Thank you, Matt, I appreciate it. And guys, if you want to contact me directly, don’t hesitate, you can reach me at [email protected] Thanks, Matt. Thanks, Steve, I appreciate it. Guys, I look forward to hearing from you. Again, join us at the live Q&A on Friday if you’ve got additional questions about the topic of the day or other topics, questions that you might have.
Take care, have a good week, a safe week. And good coding, everybody.