That's not the idea. Our vision is not of programmers working as mindless drones driven by others. It's of programmers building tools that make their lives easier.
Why use a compiler? Because it handles a lot of uninteresting details. I used to write those details by hand, writing applications in assembly language. I really appreciate having a tool that does it for me.
Why not take the same idea farther, or do you think we have reached the zenith of automation in programming?
I don't think we've reached it yet. We can identify many recurring problems and good solutions for them, and we can write them down as patterns. The next step is to bake some of those patterns into frameworks. From there, we can build tools that make it fast and easy to instantiate, configure and assemble components based on the framework.
Don't believe me? How do you build UIs? By hand or using a tool?
Software Factories are the same idea, just tackling more of the problem space. UIs are well enough understood and well enough automated. Let's work on some of the problems that haven't been solved to that degree.
Read the article. The point it makes is *exactly* the point you're arguing. You assumed you knew what it said without reading it based on your own interpretation of one word in the title, but that assumption was incorrect.
It contrasts production with development (which includes design), and notes that in the software industry, production is done by machines that stamp out CD-ROMs, while development is done by engineers.
But that doesn't mean we can't automate some aspects of development. If you use a compiler, you're already using a tool that automates some aspects of development.
I used to write a lot of assembly code. The decisions now made by the compiler were made by programmers in those days, and a lot of tedious work was done by hand to implement those decisions. I no longer care about those decisions because the compiler does a good enough job of making them for me, and automates all the tedious work that went along with them. That buys me time to do more interesting things.
Software Factories are not about building the *same* thing over and over again. They're about building similar but different things from common design fragments.
Compilers do that every day. They write programs from specifications that you supply in a higher level language by combining the members of a fixed set of machine instructions using patterns. We're talking about the same thing, just taking it up another level.
Right on the money. It's not about building things that are the same. It's about building things that are similar but distinct, like different configurations of SAP.
We're not suggesting, however, that the mods be handed off to a specialized house. It's not about developers working in sweatshops.
Rather, we're thinking about more modern factories, where robots designed by engineers do the work. The analogy is tools designed by programmers. Programmers build the factories to make their lives easier.
We think development can be automated in many other problem domains in much the same way that SAP has automated it for ERP - i.e., by building frameworks that codify useful abstractions and supplying visual tools that make it easy to iterate rapidly over them. Do that for many pieces of more complex applications, and you have a software factory.
No worries. I think your objection has merit, given the postings on this thread. Clearly, many readers were smitten by horrifying images before getting far enough to see that I'm not suggesting proceduralized creativity. Too late to change the title of the book, so I've started thinking about simple ways to quickly communicate what we really mean. Good feedback helps improve the message, so this has been good feedback. Thanks for writing.
I guess my idea of a factory comes from more recent times. Modern factories are designed to support mass customization, where a diverse set of products can be rapidly assembled from common components by robots to meet specific requirements. When you buy a Mercedes, for example, you place an order that defines the configuration of your car out of approximately 20,000 possible configurations. The factory is programmed just in time to build the configuration you requested. Times have changed. Perhaps the connotations of the word factory haven't yet caught up.
Thanks for the pointer to the Centers of Excellence model. Any suggestions for good places to look for more information?
Good insights. One of the issues we address in the second article is the rigidity of components as we know them today. Would appreciate hearing your thoughts on the piece about development by assembly.
I think your second point is spot on. We *are* saying that we don't really need to keep writing essentially the same thing over and over again.
Once we know how to solve a problem, with variation, we can automate the application of the solution to some extent.
This is what a visual GUI builder + widget framework do. We've built enough UIs that we don't have to keep solving the problem from first principles over and over again. Instead, someone who chooses to invest in providing a reusable solution builds a widget framework. Then, they build a visual builder that makes it easy to instantiate widgets defined by the framework, set their properties, combine them in interesting ways.
While a few people would rather build the UI entirely from scratch every time by hand, most choose to use the framework + the tool because they have other fish to fry, and can't afford to spend a month reinventing that wheel.
I agree with you that some Free Software is heading in this direction. Eclipse, for example, provides a base architecture, with well defined extension points, tools to help build out the unique extension you want to add, and an organzation that helps manage the contributions from multiple participants, etc.
Keep an eye on Visual Studio. There are some interesting things coming.
I also agree with you that this doesn't totally eliminate duplicated effort. There will always be more than one supplier for the same thing. Some will survive in the marketplace. Others won't. That's how it works in every industry. This is a social and economic phenomenon, not a technical one.
Finally, I appreciate your point about IP law. Brad Cox wrote an interesting article on this topic in reply to Fred Brooks some years ago, explaining why this is such a challenging issue.
At the end of the day, softare is a bit like music or video content, with digital property rights issues. As artists often point out, without some compensation, they can't afford to practice. Of course, one could argue that they receive too much or too little. The marketplace will ultimately decide that question.
We expect to see software leasing become the primary means of compensating those who supply reusable components. The line between development and maintenance is really just a question of when you decide to cut a release, when you're supporting many customers with constantly changing needs.
There are many other issues that make this kind of development by assembly a challenging problem. There are also some interesting approaches to solving them. Both are the topic of the second article.
If you read the whole article, you will find that it *specifically* addresses the difference between production and development (which includes design, along with requirements gathering, analysis and implementation, though preferably not in a waterfall).
It then goes on to say that Software Factories are *not* about automating production. We can do that with CD burners.
They are about automating development, but not by trying to turn out identical things over and over again.
Instead, they focus on combining reusable design fragments (think patterns)to produce many similar but *different* results.
Compilers to this every day. They combine the members of the same fixed set of machine instructions to produce an infinite variety of different programs.
You probably do the same using higher level language primitives in C# or Java.
You don't question the value of having the compiler generate the byte code, or having the JITer generate the machine instructions, since there isn't much value in working at that level of detail.
What we're advocating is the same idea, just moving up to the next higher level of abstraction.
Read the whole article. It deals with exactly this issue. It does not claim that software can be mass produced, as you suppose. On the contrary, the central theme in the paper is the difference between mass production and development.
It is possible to reduce complexity by raising the level of abstraction. It's been done many times before. We take it for granted when we use a compiler.
What we're advocating is just more of the same. Rather than turning developers into factory workers, Software Factories automate rote work using tools, so that developers can focus on the creative endeavors that require human intellect, in the same way that compiling a higher level langauge like C# or Java automates a lot of low level details that don't really matter, but that used to be done by hand.
Sorry, but I have to disagree on the first point. New things almost always draw from things that went before. This is true even for paradigm shifts, as noted by Cox and Kuhn. The reason is that people need to relate new things to things they already know.
When we chose to use a factory as the basis for analogy, we didn't think about the turn of the last century sweatshop. Instead, we thought about modern factories, which are populated primarily by robots. In fact, my primary mental model was the factory that we had at NeXT, since I was a programmer there for many years, and greatly admired the level of automation that was attained.
In such a factory, tools developed by engineers do the work.
That may be beside the point, however. I agree with you that any analogy is superficial at best. That is why it is usually a good idea to read an article in its entirety before commenting on it. Then, the commentary can be based on what was actually said, not merely on a presumption of what was said inferred from a subjective interpretation of a single word in the title.
We had to pick some words to name the ideas. There are only so many to choose from in the English language, and most have already been overloaded multiple times. We like the factory metaphor when the engineer is the factory designer. It has been quite a surprise to see how quickly respondents have jumped to the conclusion that we're trying to turn engineers into mindless drones. Many have assumed that article claims that software can be mass produced, when in fact the article says just the opposite. Clearly, they didn't read very far. We assumed that people would read at least a little bit of the material before posting public commentary.
I think we're very much on the same page on your second point.
Last I checked, good programmers like to build tools that do things for them, so that they have more time to sleep and eat. That's what Software Factories are about. Programmers building tools that automate grunt work, so that they can get on with more creative things.
Who said anything about stuffing programmers into factories? I hate grunt work, so I'm interested in building factories to make tools do things for me. It's not about making programming a mindless job. It's about automating the mindless parts of programming, so that we can get on with the creative parts that drew most of us in the first place.
Actually, the previous poster had it right on the money. Yes, a game engine is a library. That's what Software Factories are all about. Building reusable abstractions that can be combined or configured to do new things.
The article said nothing about code factories. It talked about combining pieces to build similar but different things. Isn't that what we do with libraries?
The gestalt of Software Factories is not programmers working in sweatshops doing mindless work under the eye of an overbearing manager. To the contrary, it's programmers building tools that automate grunt work, so that they have time to do more creative things.
Interestingly, the article says nothing about assembly lines, nor does it equate programming to the work of an unskilled, uneducated factory worker.
Quite to the contrary, it's about building tools to automate grunt work, so that humans can get on with more creative things.
As I said in another post, programmers are the designers of factories, not unskilled workers laboring inside them. The idea is to build tools that do the work.
Do you remember the monks who claimed that the printing press was the work of the devil? Granted, it put many of them out of the business of hand lettering manuscripts, but it also opened up the world of reading and writing to many more people.
Monks who could think about the content of the writing, in addition to lettering it on paper, did quite well in the new world of the printing press.
Software Factories can actually help with all three of the things you list.
When you build a new thing, is it entirely new, or are some parts similar to things you've built before? If some parts are similar, then you may be able to reuse some design fragments. After doing that a few times, you might sit down and write out those deisgn fragments as patterns. That's exactly the idea behind a Software Factory. Why not build some tools that implement some of those patterns?
When you change something, do you have any idea how it might change, or do you shoot completely from the hip? Chances are, you have some idea about how it might change, again because you've done that before. There are number of well known refactorings out there, so why not use them if they apply? And if you can write a tool that does the work for you, why keep doing it by hand?
When you fix bugs, how often do you find that the bug is due to something being configured incorrectly or not being changed to take some other change into account? Probably happens a lot. I used to write a lot of assembly language. The number of little details that had to be gotten right was enormous. The compiler takes care of most of those now. If you can build tools that keep things synchronized, why keep doing it by hand?
I agree with you that programming is an art form. However, a lot of the time seems to be taken up not doing things that involve creativity, but doing grunt work. That's what higher level languages did for us. They took away some grunt work, as you point out. It's a good that that we don't spend much time juggling pointers or writing memory allocators in Java. I used to do plenty of both, and freely admit that the compiler and runtime do a better job than I did. I like not having to worry about them. That's exactly what Software Factories are all about. Building tools to automate rote and menial tasks, so that developers can get on with the creative aspects of development. What I don't understand is what specialists have to with any of this, however. The article doesn't talk about people focusing on narrow tasks. It does talk about forming supply chains, and there will be some amount of specialization as complexity ramps up. But, as I said in another post, this will happen at the level of companies supplying coarse grained components, not at the level of the individual developer. Most shops use DMBSs supplied by people who know that problem domain, for example. Why? Because it takes a long time to really know the domain, and because using a DMBS supplied by someone who really knows the domain takes less time and involves less risk than writing one yourself, learning by trial and error as you go. Using a DBMS supplied by someone else is an example of a supply chain with two links. The DBMS supplier and you. This can and will go much deeper. This does not mean that individual developers will be constrained to narrow and uninteresting problems. I'm sure the folks who work on Oracle find it interesting. The message here is a bigger picture message. It's about reducing risk on a project scale by leveraging the expertise of other companies. It's not about turning individuals into narrowly focused specialists. I also agree with you that programming will continue to favor the broadly skilled artists who can solve hard problems. Anyone whose job is threatened by giving away some grunt work to tools was never in a very secure position, anyway.
The article contrasts mass production with development and points out that Software Factories are about development, *not* about mass production. It also suggests using supply chains, not specializing individuals by tier.
Well said. Software Factories are not about programmers in production lines bashing out software. They're about programmers in the back room creating production lines. Instead of people and robots, think tools, like compilers. I like it when the tools I design bash out the things I want.
Read the whole article. As it points out, you can automate bridge building, not by turning out the same thing over and over again, but by combining design fragments and in some cases reusable parts based on those fragements in different ways.
That's not what the article suggests. It does talk about breaking up large projects across many suppliers, but that doesn't mean that each piece is built by a person who works on only a small chunk of code. Look at how supply chains work at Daimler Chrysler. Daimler assembles the system that runs the car, but many subsystems from other suppliers, like Bosch and Siemens. As software gets more complex, it's only natural to expect people to specialize in different areas. You may write everything you deliver from soup to nuts, but on many teams, there are some folks who work mainly on UI, and others who work mainly on the persistence end of things. Ramp up the complexity and you'll reach a point where it's just not cost effective to have everyone know everything. Does that reduce the participants to drones working on only little things, as in Snow Crash? Far from it. It merely means that we scale up the way other industries do.
The article never suggests an assembly line. It does point out, however, that there are two ways to automate. One is to build EXACTLY the same thing over and over. That's not what Software Factories are about. The other is to build many similar but different things from the same piece parts. That *is* what Software Factories are about. It's also what a compiler does. It builds many similar but different programs from the same machine instructions. It's also what you do when you write software. You build many similar but different programs from a fixed set of language primitives and other piece parts. Another word for this act is configuration. A compiler does fully automatic configuration. A Software Factory does some fully automatic configuration when it generates one file from another, but it also provides scaffolding to support manual and partially automatic configuration.
Interesting posts. But, where did anyone read that Software Factories are about making developers into drones or monkeys?
Not in the article, I'm sure, because that's not what it's about. Quite the opposite, in fact.
Software Factories are about building tools to make life easier by taking care of housekeeping. Why spend time on rote tasks, like copying and pasting things from one file into another, when tools can do that?
Why write a web app in assembly language, when you can use C# or Java? I wrote a lot of assembly code in years past. It's fine for device drivers, but I don't need to scoreboard registers by hand to build a web app.
I would rather use tools to do tedious things that don't involve much thinking, like copying and pasting files, or things that aren't the best use of a human brain, like register scoreboarding, which my compiler does well enough for most applications. That way, I can buy time for more interesting things.
Software Factories just take that idea to the next level. Instead of just using existing tools, however, you build them, and then use them. It's like emacs in the large.
Jack Greenfield
Slashdot Mirror
Why use a compiler? Because it handles a lot of uninteresting details. I used to write those details by hand, writing applications in assembly language. I really appreciate having a tool that does it for me.
Why not take the same idea farther, or do you think we have reached the zenith of automation in programming?
I don't think we've reached it yet. We can identify many recurring problems and good solutions for them, and we can write them down as patterns. The next step is to bake some of those patterns into frameworks. From there, we can build tools that make it fast and easy to instantiate, configure and assemble components based on the framework.
Don't believe me? How do you build UIs? By hand or using a tool?
Software Factories are the same idea, just tackling more of the problem space. UIs are well enough understood and well enough automated. Let's work on some of the problems that haven't been solved to that degree.
It contrasts production with development (which includes design), and notes that in the software industry, production is done by machines that stamp out CD-ROMs, while development is done by engineers.
But that doesn't mean we can't automate some aspects of development. If you use a compiler, you're already using a tool that automates some aspects of development.
I used to write a lot of assembly code. The decisions now made by the compiler were made by programmers in those days, and a lot of tedious work was done by hand to implement those decisions. I no longer care about those decisions because the compiler does a good enough job of making them for me, and automates all the tedious work that went along with them. That buys me time to do more interesting things.
Software Factories are not about building the *same* thing over and over again. They're about building similar but different things from common design fragments.
Compilers do that every day. They write programs from specifications that you supply in a higher level language by combining the members of a fixed set of machine instructions using patterns. We're talking about the same thing, just taking it up another level.
We're not suggesting, however, that the mods be handed off to a specialized house. It's not about developers working in sweatshops.
Rather, we're thinking about more modern factories, where robots designed by engineers do the work. The analogy is tools designed by programmers. Programmers build the factories to make their lives easier.
We think development can be automated in many other problem domains in much the same way that SAP has automated it for ERP - i.e., by building frameworks that codify useful abstractions and supplying visual tools that make it easy to iterate rapidly over them. Do that for many pieces of more complex applications, and you have a software factory.
No worries. I think your objection has merit, given the postings on this thread. Clearly, many readers were smitten by horrifying images before getting far enough to see that I'm not suggesting proceduralized creativity. Too late to change the title of the book, so I've started thinking about simple ways to quickly communicate what we really mean. Good feedback helps improve the message, so this has been good feedback. Thanks for writing.
Thanks for the pointer to the Centers of Excellence model. Any suggestions for good places to look for more information?
Good insights. One of the issues we address in the second article is the rigidity of components as we know them today. Would appreciate hearing your thoughts on the piece about development by assembly.
What gave you the idea that the article advocated black boxing programmers?
Once we know how to solve a problem, with variation, we can automate the application of the solution to some extent.
This is what a visual GUI builder + widget framework do. We've built enough UIs that we don't have to keep solving the problem from first principles over and over again. Instead, someone who chooses to invest in providing a reusable solution builds a widget framework. Then, they build a visual builder that makes it easy to instantiate widgets defined by the framework, set their properties, combine them in interesting ways.
While a few people would rather build the UI entirely from scratch every time by hand, most choose to use the framework + the tool because they have other fish to fry, and can't afford to spend a month reinventing that wheel.
I agree with you that some Free Software is heading in this direction. Eclipse, for example, provides a base architecture, with well defined extension points, tools to help build out the unique extension you want to add, and an organzation that helps manage the contributions from multiple participants, etc.
Keep an eye on Visual Studio. There are some interesting things coming.
I also agree with you that this doesn't totally eliminate duplicated effort. There will always be more than one supplier for the same thing. Some will survive in the marketplace. Others won't. That's how it works in every industry. This is a social and economic phenomenon, not a technical one.
Finally, I appreciate your point about IP law. Brad Cox wrote an interesting article on this topic in reply to Fred Brooks some years ago, explaining why this is such a challenging issue.
At the end of the day, softare is a bit like music or video content, with digital property rights issues. As artists often point out, without some compensation, they can't afford to practice. Of course, one could argue that they receive too much or too little. The marketplace will ultimately decide that question.
We expect to see software leasing become the primary means of compensating those who supply reusable components. The line between development and maintenance is really just a question of when you decide to cut a release, when you're supporting many customers with constantly changing needs.
There are many other issues that make this kind of development by assembly a challenging problem. There are also some interesting approaches to solving them. Both are the topic of the second article.
That was article 1 of 4. The second is already posted. The last two are on the way.
If you read the whole article, you will find that it *specifically* addresses the difference between production and development (which includes design, along with requirements gathering, analysis and implementation, though preferably not in a waterfall).
It then goes on to say that Software Factories are *not* about automating production. We can do that with CD burners.
They are about automating development, but not by trying to turn out identical things over and over again.
Instead, they focus on combining reusable design fragments (think patterns)to produce many similar but *different* results.
Compilers to this every day. They combine the members of the same fixed set of machine instructions to produce an infinite variety of different programs.
You probably do the same using higher level language primitives in C# or Java.
You don't question the value of having the compiler generate the byte code, or having the JITer generate the machine instructions, since there isn't much value in working at that level of detail.
What we're advocating is the same idea, just moving up to the next higher level of abstraction.
Read the whole article. It deals with exactly this issue. It does not claim that software can be mass produced, as you suppose. On the contrary, the central theme in the paper is the difference between mass production and development.
It is possible to reduce complexity by raising the level of abstraction. It's been done many times before. We take it for granted when we use a compiler.
What we're advocating is just more of the same. Rather than turning developers into factory workers, Software Factories automate rote work using tools, so that developers can focus on the creative endeavors that require human intellect, in the same way that compiling a higher level langauge like C# or Java automates a lot of low level details that don't really matter, but that used to be done by hand.
When we chose to use a factory as the basis for analogy, we didn't think about the turn of the last century sweatshop. Instead, we thought about modern factories, which are populated primarily by robots. In fact, my primary mental model was the factory that we had at NeXT, since I was a programmer there for many years, and greatly admired the level of automation that was attained.
In such a factory, tools developed by engineers do the work.
That may be beside the point, however. I agree with you that any analogy is superficial at best. That is why it is usually a good idea to read an article in its entirety before commenting on it. Then, the commentary can be based on what was actually said, not merely on a presumption of what was said inferred from a subjective interpretation of a single word in the title.
We had to pick some words to name the ideas. There are only so many to choose from in the English language, and most have already been overloaded multiple times. We like the factory metaphor when the engineer is the factory designer. It has been quite a surprise to see how quickly respondents have jumped to the conclusion that we're trying to turn engineers into mindless drones. Many have assumed that article claims that software can be mass produced, when in fact the article says just the opposite. Clearly, they didn't read very far. We assumed that people would read at least a little bit of the material before posting public commentary.
I think we're very much on the same page on your second point.
Last I checked, good programmers like to build tools that do things for them, so that they have more time to sleep and eat. That's what Software Factories are about. Programmers building tools that automate grunt work, so that they can get on with more creative things.
Who said anything about stuffing programmers into factories? I hate grunt work, so I'm interested in building factories to make tools do things for me. It's not about making programming a mindless job. It's about automating the mindless parts of programming, so that we can get on with the creative parts that drew most of us in the first place.
The article said nothing about code factories. It talked about combining pieces to build similar but different things. Isn't that what we do with libraries?
The gestalt of Software Factories is not programmers working in sweatshops doing mindless work under the eye of an overbearing manager. To the contrary, it's programmers building tools that automate grunt work, so that they have time to do more creative things.
Quite to the contrary, it's about building tools to automate grunt work, so that humans can get on with more creative things.
As I said in another post, programmers are the designers of factories, not unskilled workers laboring inside them. The idea is to build tools that do the work.
Do you remember the monks who claimed that the printing press was the work of the devil? Granted, it put many of them out of the business of hand lettering manuscripts, but it also opened up the world of reading and writing to many more people.
Monks who could think about the content of the writing, in addition to lettering it on paper, did quite well in the new world of the printing press.
Software Factories can actually help with all three of the things you list.
When you build a new thing, is it entirely new, or are some parts similar to things you've built before? If some parts are similar, then you may be able to reuse some design fragments. After doing that a few times, you might sit down and write out those deisgn fragments as patterns. That's exactly the idea behind a Software Factory. Why not build some tools that implement some of those patterns?
When you change something, do you have any idea how it might change, or do you shoot completely from the hip? Chances are, you have some idea about how it might change, again because you've done that before. There are number of well known refactorings out there, so why not use them if they apply? And if you can write a tool that does the work for you, why keep doing it by hand?
When you fix bugs, how often do you find that the bug is due to something being configured incorrectly or not being changed to take some other change into account? Probably happens a lot. I used to write a lot of assembly language. The number of little details that had to be gotten right was enormous. The compiler takes care of most of those now. If you can build tools that keep things synchronized, why keep doing it by hand?
I agree with you that programming is an art form. However, a lot of the time seems to be taken up not doing things that involve creativity, but doing grunt work. That's what higher level languages did for us. They took away some grunt work, as you point out. It's a good that that we don't spend much time juggling pointers or writing memory allocators in Java. I used to do plenty of both, and freely admit that the compiler and runtime do a better job than I did. I like not having to worry about them. That's exactly what Software Factories are all about. Building tools to automate rote and menial tasks, so that developers can get on with the creative aspects of development. What I don't understand is what specialists have to with any of this, however. The article doesn't talk about people focusing on narrow tasks. It does talk about forming supply chains, and there will be some amount of specialization as complexity ramps up. But, as I said in another post, this will happen at the level of companies supplying coarse grained components, not at the level of the individual developer. Most shops use DMBSs supplied by people who know that problem domain, for example. Why? Because it takes a long time to really know the domain, and because using a DMBS supplied by someone who really knows the domain takes less time and involves less risk than writing one yourself, learning by trial and error as you go. Using a DBMS supplied by someone else is an example of a supply chain with two links. The DBMS supplier and you. This can and will go much deeper. This does not mean that individual developers will be constrained to narrow and uninteresting problems. I'm sure the folks who work on Oracle find it interesting. The message here is a bigger picture message. It's about reducing risk on a project scale by leveraging the expertise of other companies. It's not about turning individuals into narrowly focused specialists. I also agree with you that programming will continue to favor the broadly skilled artists who can solve hard problems. Anyone whose job is threatened by giving away some grunt work to tools was never in a very secure position, anyway.
Where does the article say that Software Factories involve creating an assembly line with interchangeable employees? I didn't see that in the text.
The article contrasts mass production with development and points out that Software Factories are about development, *not* about mass production. It also suggests using supply chains, not specializing individuals by tier.
Well said. Software Factories are not about programmers in production lines bashing out software. They're about programmers in the back room creating production lines. Instead of people and robots, think tools, like compilers. I like it when the tools I design bash out the things I want.
Read the whole article. As it points out, you can automate bridge building, not by turning out the same thing over and over again, but by combining design fragments and in some cases reusable parts based on those fragements in different ways.
That's not what the article suggests. It does talk about breaking up large projects across many suppliers, but that doesn't mean that each piece is built by a person who works on only a small chunk of code. Look at how supply chains work at Daimler Chrysler. Daimler assembles the system that runs the car, but many subsystems from other suppliers, like Bosch and Siemens. As software gets more complex, it's only natural to expect people to specialize in different areas. You may write everything you deliver from soup to nuts, but on many teams, there are some folks who work mainly on UI, and others who work mainly on the persistence end of things. Ramp up the complexity and you'll reach a point where it's just not cost effective to have everyone know everything. Does that reduce the participants to drones working on only little things, as in Snow Crash? Far from it. It merely means that we scale up the way other industries do.
The article never suggests an assembly line. It does point out, however, that there are two ways to automate. One is to build EXACTLY the same thing over and over. That's not what Software Factories are about. The other is to build many similar but different things from the same piece parts. That *is* what Software Factories are about. It's also what a compiler does. It builds many similar but different programs from the same machine instructions. It's also what you do when you write software. You build many similar but different programs from a fixed set of language primitives and other piece parts. Another word for this act is configuration. A compiler does fully automatic configuration. A Software Factory does some fully automatic configuration when it generates one file from another, but it also provides scaffolding to support manual and partially automatic configuration.
Interesting posts. But, where did anyone read that Software Factories are about making developers into drones or monkeys? Not in the article, I'm sure, because that's not what it's about. Quite the opposite, in fact. Software Factories are about building tools to make life easier by taking care of housekeeping. Why spend time on rote tasks, like copying and pasting things from one file into another, when tools can do that? Why write a web app in assembly language, when you can use C# or Java? I wrote a lot of assembly code in years past. It's fine for device drivers, but I don't need to scoreboard registers by hand to build a web app. I would rather use tools to do tedious things that don't involve much thinking, like copying and pasting files, or things that aren't the best use of a human brain, like register scoreboarding, which my compiler does well enough for most applications. That way, I can buy time for more interesting things. Software Factories just take that idea to the next level. Instead of just using existing tools, however, you build them, and then use them. It's like emacs in the large. Jack Greenfield