In-Depth
Q&A: Strategies for Automating Software Development
Programming automation gives developers more freedom to do their jobs
At the Object Oriented Programming, Systems, Language, and Applications conference this week, Microsoft is expected to tout a new vision for software development, called the “Software Factory.”
As envisioned by Microsoft, the software factory lets organizations achieve greater levels of code reuse as well as more effectively expose the knowledge of developers and business domain experts.
We spoke recently with Alan Brown, director of the IBM Rational Development Accelerator Team, about programming automation in general and the software factory concept in particular. Brown thinks there’s a lot to be commended in Microsoft’s software factory vision: Software development could benefit greatly from automation, he says, and organizations have long been looking for ways to extract domain-specific expertise and expose it more easily.
In the final analysis, Brown argues, programming automation—even if it’s called a “software factory”—isn’t about replacing software developers with IDE robots, but, if done right, should give programmers more time and freedom to do their jobs.
The idea behind the software factory vision as I understand it is that software development can be automated, whether by means of code-reuse or by building intelligence into the development tooling itself—or both. Is automation of this kind something that IBM Rational is also pursuing?
I think it’s something we’re all very interested in. One of the people at Microsoft doing a lot of writing and thinking about that is Jeff Greenfield [a former Chief Architect with Rational], and another big player in Microsoft’s view is Keith Short, who was at Texas Instruments and then Sterling Software before he joined [Microsoft]. I worked with Keith at Sterling, and we were working on a lot of the model-driven techniques, trying to address things like how you could help organizations extract knowledge from some of the key designers and use them to help some of the downstream developers who would be sort of the nuts and bolts developers.
The overarching idea is, how do we get people thinking more about software from a factory assembly process, rather than as a hand-crafted [practice that] has to be done fresh each time.
I’ve heard from a few developers who say that this isn’t exactly a new idea.
From a developer point of view, they’ve seen this come and go. They’ve seen the push toward code reuse, asset reuse, [and] subroutine libraries. We’ve seen many examples where managers said, “Why do we keep rebuilding this stuff from scratch each time?” Developers are left at the sharp end of figuring out how do they address this, and there’s a lot of bottom-up efforts to do so.
What’s different this time is we’re beginning to see some broader strategies that will help people be effective in applying some of these factory ideas. The ideas of things like struts and Java Server Pages and others is that you put in place a basic structure of an application and then you build the solution by extending and adding to that basic structure rather than building from scratch each time. Languages like Java have capabilities that make this easier by helping people to think that way. That’s encouraged a kind of medium ground between the developers who are working bottom up to reuse code and the managers who are working top down to reuse practices.
So you’re saying that the software factory idea isn’t just Microsoft’s hobbyhorse, so to speak? To what extent do the details of Microsoft’s software factory vision coincide with your own take on programming automation?
I think many of the ideas are shared amongst the community and have been shared for some time. Some of the execution ideas are a little different. I think what Microsoft has been doing lately is trying to position their whole software factory idea as a way of extending the .NET platform.
What we see with a lot of our customers is that they’re in much more of a diverse situation, they have multiple platforms, multiple skills across their organizations, they create very different kinds of applications across their groups, so when they look at the software factory idea, they have to be very careful about not overly constraining themselves to a particular set of technologies. So what we’ve done is introduce techniques and technologies that allow them to customize a set of base tools for their particular techniques.
Software factory proponents, including Microsoft, typically use an assembly-line metaphor when they talk about programming automation. To a very large degree, this involves code reuse. But just how effectively are organizations reusing their code today, do you think?
If you think about what’s going on in most large IT orgs, there is a huge amount of reuse, depending on your scope and definition of reuse. Typically what happens with reuse is that it codifies and captures practice and what’s going on, so that in existing projects what seems to be common is extracted and reused. In one way, what happens is the programming languages themselves evolve. If you look at things like the WebSphere Application Server, or the Portal Server, or the integration server, a lot of things that were done by hand to create these sorts of dashboard applications that collect information from multiple sources—instead of building those things by hand, you get a lot of support in the run-time for doing exactly that. Our tools enable you to assemble portlets to build portal-style applications almost with no programming. That’s one example of reuse that gets pushed into the platforms and the run-times and gets reused in the tooling.
I hear from developers all of the time who say that, absent the application server tier, they’re not able to achieve pervasive code reuse across all of their projects. Do you think that’s a potential impediment to the success of the software factory vision?
This is the heart of the issue around reuse and software factories. Whenever you’re embarking on a software project, you’re essentially making a set of trade-offs, and you’re looking for a set of consistencies about what you’re trying to do. Reuse in the factory approach relies on a certain consistency that must exist somewhere—what is consistent about the situation you’re in that will support a reuse approach. Now, what is consistent about an organization is the people and the knowledge of the people as they move from one project to the next. So you can optimize for that and create very agile, coherent teams that move from one project to the next.
Other situations are very different. You see other situations where what’s consistent is the domain they’re working in. Regardless, as long as there’s a group of consistencies [organizations can optimize for], they can create very much a factory style similar to an automotive plant—providing that the domain doesn’t change too frequently, because then it has to be retooled.
Just to clarify, what do you mean here by “domain?”
The easiest way to put it is expertise in a given area. If you take any organization with the typical skill profile, you have some people—top gun kind of people—who are very skilled [programmers], and then you have a larger majority who are the more average, run-of-the-mill sort of people. And then you have people who are domain specialists, who understand the retail domain or the financial services domain very well, but might not be the top technologists; you have people who are very good at the technology but don’t understand the domain very well. You have business-focused people who don’t understand how the domain relates to that. You have this profile of skills, and taking advantage of that is also key. The software factory idea effectively asks, “How do you understand the consistency that exists in the domain, and how do you help the top domain experts extract their domain-specific information in a way that can easily be applied to the [overall] software development process?”
Microsoft has said that SQL is an example of this idea, which I think is what it calls a “domain-specific language,” because a SQL programmer doesn’t necessarily have to know anything about the relational database he or she is using. Is that what you’re talking about?
Yes, about programming—but also about the architecture and also the processes of [that domain]. In normal cases, what organizations are looking for is a way of taking their highly talented people who understand the technology and the implications of distributed development, or the people who understand the key architectural implications, and being able to extract that [expertise from them]. And this whole software factory metaphor seems to fit that very well. You can have this small group of skilled developers build the factory—design the architecture or do most of the work on the WebSphere Application Server that connects to all of these different domains—and you have the domain-specific people help write the reusable code for their domains.
When I think of a “factory” of any kind, I automatically think of automation—and when I think of automation, I think of job losses. Is there a danger with approaches that seek to automate the production of software code?
I don’t think so. These domains aren’t going anywhere; these people are still going to be working in their areas of expertise. This sort of factory idea implies that you’re creating a large number of similar things, but the classic assembly line view is that you’re producing thousands of similar, assembly-line things. I don’t think most IT organizations have that kind of thing in mind.
The question isn’t "Can they produce thousands of similar pieces of software?" The real question is, "What are the common aspects between [software projects] that they can reproduce?"
It could have to do with skills, testing, [and] domain expertise. There’s no sort of cookie-cutter approach to this that they can just stamp out 10,000 of these things; it’s not like they’re producing the one millionth Ford Escort. But what they are doing is building systems that have enough commonality that they have the same architecture, they’re working in the same domain, and they’re using the same testing principals.