Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Interaction design for software engineering: a boost into the programming future
Knaus C. interactions15 (4):71-74,2008.Type:Article
Date Reviewed: Sep 17 2008

The desire to deliver remarkable solutions focuses increasingly on end users, and this is as it should be. They are the often-unknowing experts on what makes sense. Most of the end-user genius comes from listening to the spirit of their words, not to the words themselves. Truly user-designed solutions are often fraught with design-by-committee bloat, where a well-intentioned solution becomes a heavy answer to many narrow views. There is less progressive user experience investment in the tools software engineers use to create solutions. In this article, Knaus provides thoughtful review and insight, as he takes a futuristic look at how the programming landscape might change--there is still hope for visual programming.

Relative to the solutions built by software engineers, the tools they use to construct them are far more sedate. Functionality and automation win over pretty user experience and intuitive user design. While many development environments have sophisticated experiences, such as syntax autocomplete, round-trip unified modeling language (UML) modeling, and visual user interface assemblers, they lack the level of thoughtfulness that is associated with finely crafted technology counterparts, such as the iPod. This is less of a problem than it may seem, as most seasoned developers remember having no integrated development environment (IDE). For those who have used IDEs over the last decade, there have been many improvements. However, they are likely not cited as reasons for developing better solutions--faster, maybe; better or remarkable, no.

Knaus makes a great point that resonates with one of Booch’s articles on accidental architecture [1]: “IDEs ask developers to continuously make small and seemingly unimportant decisions, which has subtle, long-term, and often large consequences.” What developers don’t know hurts them and those who work with their code. There is no blame, however, because to Knaus’ point, there is little supporting the developer to be more futuristically aware and make better decisions. Recent grammar-checking style code-evaluation software certainly offers some promise, but here is what makes great programmers stand out: they build software that is less problematic than most, and they are fast enough to refactor and recode to evolve their work. As Knaus describes, the process of refactoring is reworking software code to better states of convention, often codified as design patterns.

Readers will learn that the challenge developers face is that many of the development models are not faithful representations of what computers actually do or mean. There is enough indirection and abstraction that many modern languages prohibit the need to learn lower-level approaches to resolve programming challenges. Yet, the intimacy level of a developer to his or her code remains high.

Knaus’ premise is that today’s programming concept models are arbitrary and are often expressed with metaphors that may be affective but ultimately unsupportive. There is no shortage of visual programming languages attempting to simplify the complexity of solution development [2]. Conceptually, the trend is that components can be built to articulate some level of capability, and then mashed up by knowledge workers [3]. However, the best results from high-order programming languages, especially those that are visual, are done by experienced developers. Therefore, while Knaus believes that visual programming will come to be through proper interaction design, it is also a point of disagreement.

Identify any visual programming language or any environment that is positioned to simplify the development process, and you will find that three elements hold true: first, a novice needs to understand programming; second, the system can support only a limited and often limiting set of capabilities; third, almost all of the good solutions require lots of talented programming knowledge. Today’s programmers could benefit from better development environments, and while visual development may accelerate their ability, they are simply not required. The tension between abstracting software development to enable simpler concepts that are more natural is that the process overly simplifies the complex nature of programming reality.

In the end, it is more important and effective to know how to build something and how something is built than to gain efficiencies in doing but not knowing. One could easily argue the notion that existing frameworks and service orientation simplify the programming landscape by encapsulating capability that no longer needs direct interaction, accelerating the efficiency enough so that providing visual development environments may never come to be. Regardless of your role and position, thoughtful interaction design and end-to-end user experience around development environments is sure to change the culture of programming. For those looking for inspiration on how interaction design influences visual programming or development environments in general, Knaus is your man.

Reviewer:  Brian D. Goodman Review #: CR136073 (0907-0664)
1) Booch, G The accidental architecture. IEEE Software 23, 3(2006), 9–11.
2) Cherbakov, L.; Bravery, A.; Goodman, B. D.; Pandya, A.; Baggett, J. Changing the corporate IT development model: tapping the power of grassroots computing. IBM Systems Journal 46, 4(2007), 743–762.
3) Wong, J.; Hong, J. Making mashups with marmite: towards end-user programming for the web. In Proceedings of the SIGCHI conference on Human factors in computing systems ACM Press, New York, NY, 2007, 1435–1444.
Bookmark and Share
  Reviewer Selected
 
 
Programming Environments (D.2.6 )
 
 
General (D.2.0 )
 
 
User Interfaces (H.5.2 )
 
Would you recommend this review?
yes
no
Other reviews under "Programming Environments": Date
A prototyping environment for differential equations
Boubez T., Froncioni A., Peskin R. ACM Transactions on Mathematical Software 18(1): 1-10, 1992. Type: Article
Mar 1 1993
PICT: an interactive graphical programming environment
Gilnert E., Tanimoto S. Computer 17(11): 7-25, 1984. Type: Article
Jul 1 1985
Towards monolingual programming environments
Heering J. (ed), Klint P. (ed) ACM Transactions on Programming Languages and Systems 7(2): 183-213, 1985. Type: Article
Nov 1 1985
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy