Specifically, products are often said to "mirror" the architectures of the organizations from which they come. Such a link, if confirmed empirically, would be important, given that product architecture has been shown to be an important predictor of, among other things: product performance; product variety; process flexibility; and future industry evolution. We explore this relationship in the software industry by use of a technique called Design Structure Matrices (DSMs), which allows us to visualize the architectures of different software products and to calculate metrics to compare their levels of modularity. We use DSMs to analyze a number of matched-pair products--products that fulfill the same function but that have been developed via contrasting modes of organization; specifically, closed-source (or proprietary) versus open-source (or distributed) development. Our results reveal significant differences in modularity, consistent with a view that distributed teams tend to develop more modular products. We conclude by highlighting some implications of this result and assessing how future work in this field should proceed, based upon these first steps in measuring "design."I've seen work on this subject before (including similar diagrams that show code module relationships)-- not usually in business press, although it's nice to see this get a wide audience. Recently I read Becky Grinter's essay in HCI Remixed which reflects on Parnas 1972's "On the Criteria to Be Used in Decomposing Systems into Modules" and on Conway's Law: The structure of the code mirrors the communication of the organization that developed it. Or lack thereof.
More than that, I'd say the UI design and the broader corporate outside facing design often reflects the organization's internal structure and different goals. Marketing groups that don't talk to engineers, executives who don't get along, customer support and sales who don't speak -- these things all hit heavily on the face that a customer sees for the company. All of which can be reasons why "User Experience" as a group can't live low-down in any one part of a company, especially a big one.
More personally, I've started using R, an open-source competitor to MATLAB, and wondering about this stuff as I try to track down the open-source resources I need. I've been enjoying ramping up on R despite finding the documentation available and code quality of some libraries very hit-or-miss. MathWorks's doc team and their demos are one of their strengths. Regardless, R has a growing number of books and sites, and I've learned some simple concepts faster in R than I ever did for the same concepts in M-code. In many ways, I prefer the language to M, despite my belief that open-source usability is generally very poor [here we might have a discussion about usability of the language itself, for different tasks, versus that of GUIs or tools available for programming support, but I'm still thinking about the topic].
In short, R works; plus it's free, and it's powerful and extensible. (For just how free is free: compare about $4K for what I'd need for statistics and database access plus some reporting, with $0K, and that's pretty free.) I wonder how the code compares to to MATLAB's.
No comments :
Post a Comment