developerWorks: This is a developerWorks podcast. I'm Scott Laningham. My guest is Sundeep Goel, Worldwide Channel Sales with IBM Rational. Sundeep works with customers, partners, and analysts to articulate and quantify the need for better solutions in the build-and-release management space. And he joins us to talk about that today. Sundeep, thanks for doing this.

Goel: Thanks for having me, Scott.

developerWorks: Now, build-and-release best practices. Why are we talking about this? I mean, haven't people been building and releasing software for years and this is all kind of understood? Or what's the story here?

Goel: Yes. That's a great question. I mean, obviously, people have been building and releasing software for decades now. And clearly, customers have some process around doing that today. The reason I think that we're talking about it today and the reason we need to focus some more attention here is people have really never in any kind of systematic way tried to optimize those processes. People typically had a process that worked when they were a 10-person development shop, and then as the company grew and as the product grew and as the team grew, the kind of just took that same process and kept putting Band-Aids on top of that.

So, you know, over 20 years, you have this process that really started out solving a problem for a small company, and now that same process is being used for a giant company that maybe has development spread across the globe. Really, what I think needs to be done is some kind of scientific way of taking a look at the process, taking a look at the requirements and actually engineering an appropriate process for the appropriate problem.

developerWorks: Well, then this sounds like something that would be a logical thing for many lines of business to consider, which is refreshing oneself and not just sitting on your laurels or getting stuck in a rut, right?

Goel: Absolutely. And it's actually something I'm a little surprised hasn't happened over the last four or five years. If you look at the software life cycle, there's been a lot of work and investment around development environments, around testing tools, around source repositories, around change management, around a lot of the other areas of the life cycle. For whatever reason, build and release really hasn't received that attention. And I'm starting to see that change, but I think it's lagging some of the other parts of the life cycle.

developerWorks: Now, you and I talked earlier in a different podcast about Rational Build Forge, and I know that's important to you. This discussion isn't necessarily just a veiled sales pitch for Build Forge now, is it?

Goel: Not at all. And in fact, some of the principles around build-and-release best practices have nothing to do with Build Forge. Somebody can take these best practices and apply them to their process utilizing competitive tools or just utilizing some of the scripting solutions they may already have in place. These are just sort of technology-neutral best practices that people should think about when they're trying to drive value through build-and-release best practices.

developerWorks: So let's jump into some of them, if you would. Why don't you talk about some of those best practices a bit?

Goel: Sure. So one of the critical best practices that I see over and over is software reproducibility. We'll have customers out there that are building huge systems and iterating through those systems very, very quickly. They may be doing many, many releases a year. Maybe a couple of releases a quarter, even, in some extreme cases. With that kind of complexity, it can be very hard to be able to reproduce any specific version over five years, over 10 years, over 20 years.

If you think about an organization that has to support multiple versions of their system out commercially in the field, it becomes very, very important that they be able to fully reproduce any version of software that they've ever released — not just the latest version. My experience is that customers often can reproduce the last version of their product, but if you ask them to go back and, say, reproduce something from five years ago, it can become very, very difficult.

Another best practice is kind of decoupling your process from your hardware. So one of the other common things I've seen is customers have a build machine and a build script that runs in that build machine, and the only way that they can build their system is utilizing that one script on that one machine. Well, if that system goes down, or if the operating system that that machine is running becomes obsolete, this can create a major business risk for the organization because they're fully reliant on this one machine.

developerWorks: Right.

Goel: The logic of the process isn't abstracted out from this one machine, and it becomes kind of a black box. One other best practice that I'll mention is build early and often. So for some of you out there, you may have heard a lot of kind of noise around "agile development" or "extreme programming" — a lot of sort of trendy development methodologies that have received some press recently. I think fundamentally those processes are about constantly building software. Don't wait until the end of your development life cycle to try building your software and testing it. Always be building it. Always be testing it.

developerWorks: Now what about some, you know, examples of real-world application of this? We always try to bring that up because I know the listeners love, they're interested in the message, but they really want to hear how this stuff is actually functioning in some real-world settings.

Goel: Absolutely, yes. So on reproducibility, I think that was the first best practice that I talked about. That's one that's especially applicable to some customers I've talked to in healthcare. So for people that write software in medical devices, and pacemakers are a good example. A couple of customers I know write pacemaker software. Well, if you think about that market, if you put a pacemaker in somebody, you need to be able to support the software that's running that pacemaker. You can't easily upgrade software that runs in a pacemaker. So having the ability to reproduce and patch any version of pacemaker software that you may have used over 20 years is a critical business requirement for a lot of customers that I've talked to.

If you think about the problem, it's more complicated than just having all the source code. Operating systems change, compilers change, the build processes change, the team changes in and out. So if you're looking to have a fully automated, fully reproduced process over, let's say, 20 years, that's a very large problem to solve. And the solution to that isn't something that you can kind of, obviously, just do.

developerWorks: Right. How about some other examples like that? That was an excellent one.

Goel: Yes. So I think abstracting the process from the hardware is a best practice I talked about, as well. That one's especially important. I worked with a customer out in Silicon Valley — a commercial software vendor. And they basically had a problem where they were using an old Windows® 95 machine to build every version of their system. And that was state of the art back in, you know, the mid '90s. But as we're now several generations of Windows past Windows 95, it became increasingly difficult for them to be able to build their newest releases on that Windows 95 machine. Really, what they were forced to do is take a step back, re-engineer the process from the start and then reimplement that process in a way where it's not a black box; it's not one script that nobody understands on a machine that's old.

And by doing that, they're able to take a lot of risk out of their process. And also they're able to future-proof their system, so 10 years from now, hopefully that process is still going to be managed in a way where they're not dependent on, let's say, a Windows XP machine, which will be obsolete in a decade.

developerWorks: Now what about the third best practice you mentioned: build early and often. Do you have a case study about that one?

Goel: Yes, absolutely. So actually IBM used Build Forge as a customer prior to actually acquiring the company. And the reason they were able to do that was they firsthand saw the value within their engineering team. They wanted to build a version of the Rational ClearCase® and ClearQuest® system every day, so their QA team could be testing the latest version every single day. The problem they had was that to do any one build of the system, it took 24 hours. So the consequence there is the QA team's always going to be testing something that's old. You know, at best, it's going to be a day old, and sometimes it could be older.

By utilizing some best practices around building early and often, by shrinking the amount of time it takes to run through any of these processes, they're able to get that build time from 24 hours down to three hours. And, therefore, they're able to build a system every single day and drive tremendous QA and development efficiency.

developerWorks: That's great. Now, you know, and a summary thought: We talk about best practices in different regards on this podcast a lot. And again, I think this is another example of a case where these best practices can mean the difference for many companies between minor success and excellent success and sometimes, outright failure, can't they?

Goel: Absolutely. So, you know, my take is that a product, a commercial product alone, is not going to solve your problem. You can take the best product and apply it to the worse process, and you're not going to get very much value out of it. Really, the most powerful solution, the most valuable solutions, are those that combine the best commercial technology with the best human process — kind of re-engineering. And the combination there can drive an order of magnitude greater value than simply automating or optimizing a bad process.

developerWorks: An important message. Sundeep Goel, with Worldwide Channel Sales with IBM Rational. Thank you for your time, Sundeep, we appreciate it.

Goel: Thank you for having me again, Scott.

developerWorks: Find out more on this topic through helpful links in the show notes for this podcast. You can access that at ibm.com/developerWorks/podcast. That's all for this time. For developerWorks, I'm Scott Laningham. Thanks for listening.

Resources

• Demo: IBM Rational Build Forge: Build and release process management
  
  
• IBM Rational Build Forge
  
  
• Podcast blog
  
  

About the author

Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments