People have been comparing software components to LEGO blocks for a couple decades. We should be able to assemble applications by snapping together modular components, just like LEGOs. There has been progress, but for the most part we haven’t realized the promise LEGO-style software development.
Integrating two software systems is usually more like performing a heart transplant than snapping together LEGO blocks. It can be done—if there’s a close enough match and the people doing it have enough skill—but the pieces don’t fit together trivially. And failure may not be immediately obvious; it may take a while to see signs of rejection.
Related post: Visualizing software development effort
Heh-heh… Just yesterday, I was thinking about the commonly-held view that DNA is analogous to an organism’s code or software.
But I have never, ever run across two pieces of software or code that could somehow be mated together to reproduce viable offspring. Heck, it’s practically impossible within the same piece of software — it requires a lot of careful efforts to merge a dev-branch onto the trunk without getting compiler errors, much less a working build :-)
I think DNA must be more like a config-file. Which makes me wonder — if it’s a config-file, where or what is “the” executable?
But I have never, ever run across two pieces of software or code that could somehow be mated together to reproduce viable offspring.
Well there is Genetic Programming (PDF). Probably not what you had in mind though :-)
That’s a very apt metaphor :)
I’ve mused in the past that a LEGO-style way of composing software would definitely be nice, but sadly it’s far from reality. But if ir worked that way all kinds of cool things could be built.
Maybe, but functions like Git forking facilitate code reuse, messaging/queuing allows loosely coupled functions, programs like Jenkins allow a software factory from dev to deployment, including base infrastructure build.
So, not quite the tight fit of Lego, which, as tightly coupled, probably wouldn’t be that helpful anyway, but composition in ways not thought of years ago.
Love that analogy. All too often assumptions are made about integrating technologies that may not be a good fit for each other. Careful consideration is needed to determine if re-use will actually speed up dev efforts and solve the intended problem.
Do you think that analogy perhaps best describes well the screen scraping technologies of the late 1990s?
Organs were not designed by humans for transplant.
But we now architect, design and build our software with layers and interfaces with that purpose explicitly front in mind. (And have for a decade.)
Perhaps a minor difference.
Totally agree, even though all code stands above reusable code, so a more fair analogy would have been Tetris that Lego…
It is as if software has an immune system! I have been promised software components, like integrated electronic circuits, a closer analogy, which never materialized, for a long time (1980s). Software libraries are the closest thing that approaches but doesn’t quite reach the reusability implied by a LEGO metaphor.
Btw, since it was mentioned in this thread, I have done quite a bit of research with genetic programming (GP) systems, and while fascinating for building certain structures like parameter-free statistical models, is long from writing code like a programmer, much less reusable code, automatically defined functions notwithstanding.
But still, I hope…
As someone who has some experience with both experiences, I would have to say there is a surprising amount of similarity – gotta keep that data clean and flowing.