A Process Model for Design

I think that the chapter, “The Internet and It’s Users” by Charlie Edwards provides a valuable approach to Digital Humanities by considering the degree and quality of “user” engagement. The notion of a user in partnership with a coder/builder to create/design an object/system/application is crucial in the success of any digital project. However, when Edwards asks, “If we were to propose a design for DH, then, where might we look for a model?” she seems to suggest that there is one design that may apply to the entire panorama of DH projects. It only takes a quick glance at the sample projects on the CUNY Digital Humanities Resource Guide to realize that these projects all have different goals and therefore require different designs.

What does Edwards mean, then, by referring to a single a model of DH design? Perhaps what she wants is a template or a model for the process of design. She suggests elsewhere in the piece that the Open Source community offers a template for how that process should work. She emphasizes, rightly, that users have to feel that their voices have been heard in order to invest in what the builders are creating. The open source community of volunteer user/developers does a good job of fostering that environment.

However, perhaps paradoxically, corporate software development offers another worthwhile template or at least a vision of what is required for builders and users to work together productively. This vision is hard won over many years in the corporate world with thousands of projects (both successes and failures). Successful corporate software design has a number of crucial elements. First, corporations expect that business units specialize both via their expertise and through the work that they are asked to produce. In this light, the Marketing Department consists of individuals highly trained and experienced in marketing. They are not expected to know anything about programming or databases, which remain the purview of the IT department. A successful project requires a high degree of collaboration between the two groups, with a mutual respect for their diverse expertise. Most importantly, though, if the ultimate corporate users of the system are not given (or do not take) “ownership” of the final result, the project will likely fail. After all, it is the users who have defined the business problem that needs to be solved. Since they own the problem, they must also own the solution. Further, they must convey to the coders the day-to-day context in which the software will be used so that the design reflects all of the required use cases that might occur.

I think this corporate model could work in the Digital Humanities world. Like the Marketing Department, not every Humanities scholar wants to learn how to code. They would rather remain devoted to their research. However, if scholars abdicate the building of tools to the few members of their profession who do want to play with bits and bytes, they risk being left behind. Humanists can still participate in the Digital Humanities, in fact, by forming partnerships with coders (who may not be humanists at all) in the same way that corporate marketers partner with their IT departments. By recognizing the possibility that digital tools can enhance their academic work, Humanities scholars would provide the leadership necessary to instantiate a DH design process that gives them exactly what they want.

4 thoughts on “A Process Model for Design

  1. Evan Misshula

    I think that the number of non-coding humanists who will be able to find coders to partner with will diminish over time. Coding, like mathematics requires significant time and effort. Can you imagine a physicist saying, “I am interested in thinking about how the planets move, but I can’t be bothered to learn the math.”

    You don’t have to be the best at it. No new contributor to an FOSS project is that projects best coder. Not wanting to learn says that you don’t think it is important and you are trying to get help from people that love it so much, they do it for free. That said, digital humanists have a great deal to offer. What makes open source special is that there is massive collaboration. The Linux Kernel changes 7x an hour 24x7x365. The coin of the realm is the “pull request.” Respond to a problem with a patch that creates a solution and you will become part of the code base. Or add a feature that you need for a new type of analysis, likely you will achieve the same result.

    If you open an issue and demand a new feature or “bug fix” you are at someone else’s mercy and you will wait a long time.

  2. Mary Catherine Kinniburgh

    Stephen,

    Particularly since the academic world continues to take on more features of the corporate world, your instinct to look towards corporate models for the division of labor seems very appropriate. In fact, it’s almost foreshadowing, in the sense that as more disciplines require digital literacy, academics who have the means to afford to outsource digital labor will increasingly do so–to graduate students, independent contractors, and beyond.

    The question of service appeared often in this week’s readings, particularly by female digital humanists, and it’s well-recognized that structures in academia promote research, as opposed to service, in hiring as well as the tenure process. Even in the corporate world, IT is often viewed as a service arm to the “real” work of a business–the marketing, the sales. How do we ensure that collaboration actually exists–particularly in cases of power differentials, such as the graduate student performing digital work for a professor who does not necessarily have to cite or reference this ghosted labor–rather than service? Is there a structural need to re-evaluate the often-gendered distinction between service and research work in academic departments?

    When you cite professors “who would rather remain devoted to their research” instead of learn how to code, I also began to wonder: isn’t learning to code part of the research process itself? After all, it is an identical process to learning a research language, or as Evan points out, the fundamental skills of your discipline.

    It seems that questions of service, research, and the systems which privilege the latter over the former are essential to understanding DH; I look forward to more discussion!

  3. Yitian Liao

    What I’m thinking is how could a non-coding DH scholar survive in DH area where the topic eventually touches down with coding or SC knowledge. I’m not saying a DH scholar has to learn how to code but at least he must have some basic knowledge about it even though there can be a partnership with professional coding experts. Since in the partnership the DH scholar has to fully present his idea and needs for the coding, somehow if there is a misunderstanding, the research process may take longer than they would expect. And this misunderstanding can be caused by different background, such as academic or culture. Sometimes, hard-core science people do think differently compare to social science people.
    “if scholars abdicate the building of tools to the few members of their profession who do want to play with bits and bytes, they risk being left behind.” I think it is so true.
    And I don’t know if it is too much to ask, I know some people working as IT guy for financial institutions, and one of their training subjects is to learn basic financial knowledge. Perhaps in order to build an efficient academic partnership, ideally the IT partner should also acknowledge some of the DH scholar’s project?

  4. Stephen Real

    In my view the skill and knowledge required to be a humanities scholar are so totally different than those required write code, that you will rarely find an individual who can both. Even if a person were to become expert in both arenas, are there enough hours in the day to work on both?

    The challenge for this model to work in the communication of the problem domain from the humanities scholar to the coder, who, of course, will be much more effective if he/she is well versed in the same problem domain.

Comments are closed.