What Makes the History of Software Hard

History of commitments constrains choice. Narrow incentives and opportunities motivate choice.—Rob Kling and Walt Scacchi1We never have a clean slate. Whatever new we do must make it possible for people to make a transition from old tools and ideas to new.—Bjarne Stroustrup2Creating software for work in the world has meant translating into computational models the knowledge and practices of the people who have been doing that work without computers. What people know and do reflects their particular historical experience, which also shapes decisions about what can be automated and how. Software thus involves many histories and a variety of sources to be read in new ways.     

The power of process [software processes]

Some people in the software development community think “process” is a four letter word. They think software processes are rigid, restrictive, and inefficient. They hold that the best way to run a project is to hire the best people you can, give them all the resources they ask for, and turn them loose to do what they do best. Sure, they say, there will be some amount of unproductive work is (also known as “thrashing”). After all, developers will make mistakes. But they will also be able to quickly and efficiently correct these mistakes at a cost that is less overall than the cost of processes. This point of view has intuitive appeal. At the beginning of a project, a focus on process certainly does take time away from productive work. If that trend were to continue throughout the project, it wouldn't make sense to spend much time on process. Software industry experience, however, has found that for projects that don't pay attention to establishing effective processes early are forced to slap them together late, when slapping them together takes more time and does less good. The article points out the problems caused by inattention to process, explains what happens when a project thrashes, and discusses the use of process versus creativity     

Towards useful and usable interaction design tools: CanonSketch

Despite all the effort dedicated to bringing better User-Centered Design (UCD) tools to market, current studies show that the industry is still dominated by tools that do not support the activities and workstyles of designers. Also, there is a growing need for interaction design tools aimed at software engineers, a problem related to bringing usability into the software engineering processes.

We propose a new workstyle model that can be effectively used to envision, design and evaluate a new generation of innovative interaction and software design tools, aimed at integrating usability and software engineering.

We illustrate the effectiveness of our model by describing a new tool, called CanonSketch, that was built in order to support UCD in terms of the dimensions in our workstyle model. We also describe an evaluation study aimed at contrasting paper prototyping with our tool as well as the level of workstyle support.     

Are we developers liars or just fools [software managers]

Things were good in the old days. Very few people understood software, so those of us who were cognoscenti could get away with murder. We could explain away cost and schedule overruns by blaming “complexity.” Performance problems were the fault of emerging technology and if management or customers got angry, what could they do? Although nearly everything that defined “the old days” has changed, the author argues that many of the old foibles remain. According to the author, software managers and the people who work for them risk being viewed as liars or fools, a perception that can only harm the software community     

Web-based business process reengineering

Software reengineering is not a widely accepted practice, but its methods and tools are critical to the success of business process reengineering (BPR). Reengineering software starts with an understanding of the existing system and an identification of those components that support the new business processes “as-is” and those that may have to be changed. Software reengineering would become widely used if the technology was more automated, more accessible and less complicated. Transformational reengineering encompasses available techniques for reverse engineering, reengineering and reuse, as well as the new medium of the World Wide Web (WWW). Using the WWW, the “as-is” and “to-be” designs can be made available for viewing and distribution. The author provides insight into the future of BPR and software reengineering using the WWW     

Frequently begged questions and how to answer them [software]

Typical empirical questions about software and the software business include “How productive are programming teams?”, “What are the industry norms?”, “What are the best practices?”, and “How should I measure the productivity of a programming team?” These, and others like them, are frequently asked questions. I always answer these questions with a question. “What are you trying to decide?” People almost always ask empirical questions because they need to make decisions. These decisions are important, involving risk to human life and health, affecting economic and societal well-being, and determining the equitable and productive use of scarce resources. The questioners seem to feel-because the questions are so frequently asked and the answers so often provided-that the answers must be widely known, but in looking at the answers, I observe the same pattern repeatedly. Answers that seemed well-known and widely supported turn out to be only widely proliferated. They are based on one or two sources, which often prove thin and unreliable. They are “transparency facts”, copied from presentation to presentation. When confronted with such questions, the questioners have no time to research the answers, so they grab whatever answers are at hand. Thus, many frequently asked questions about software are more truly frequently begged questions     

Ultralarge Systems: Redefining Software Engineering?

The harbingers of ultralarge systems are indeed emerging, although their elements seem contradictory to the "ultralarge" concept. ULS design will have to move beyond computer science and electrical and electronics engineering-based methodologies to include building blocks from seven major research areas: human interaction; computational emergence; design; computational engineering; adaptive system infrastructure; adaptable and predictable system quality; and policy, acquisition, and management. We need to integrate these more novel approaches with the tools and techniques of traditional software engineering, especially with regard to formal methods and to dealing with predictability and uncertainty in high-integrity software systems. Our view is not so much that we are 'redefining' software engineering but rather that we're looking to extend established software engineering tools and techniques in novel and useful ways.     

The slippery path to productivity improvement

Productivity tools simply aren't delivering increased productivity even when a project is managed “by the book”. It is demonstrated that there may be more systemic, albeit counterintuitive, causes for the “productivity paradox”. Specifically, the productivity potential of software engineering tools may be squandered not because organizations fail to institute the necessary managerial practices but because the software development environment is a complex social system that causes such practices to have unintended consequences. To support this view, the author uses a system dynamics microworld of the software development process to simulate the long term productivity trend in a a hypothetical project environment managed “by-the-book”. The microworld lets the project team examine possible causes one by one through controlled experimentation and hence allows them to discern true causal relationships in a failed project. The results indicate productivity erosion was unintentionally accelerated by perfectly “good” planning and control practices     

Principles versus patterns

Early in the history of programming, brilliant people realized that every good software system has some desirable properties: It should be extensible; parts of it should be modifiable without major impact on other parts; and so on. Because of the Feigenbaum Bottleneck, it is very hard to describe precise, step-by-step instructions to build systems with such properties. It is easier to articulate the desirable properties in the form of design principles. Over the years, the wealth of knowledge accumulated as design principles has reached a critical mass. Entire books are now dedicated to the subject. Still, despite this body of knowledge, design remains difficult. A major problem is that principles are ambiguous and not very constructive. In more recent times, design patterns have emerged as a valid alternative to the principles-driven approach. If principles represent the “say-what” approach to design, patterns are the “show-how” way     

Software design methods: life belt or leg iron?

Do software design methods have a future? The issue I explore in this article is concerned with the problems that the use of design methods can present. It can be expressed as a question: “Will the adoption of a design method help the software development process (the `life belt' role), or is there significant risk that its use will lead to suboptimum solutions (the `leg iron' role)?” (I use “method” to mean “a way of doing something”, rather than using the more pretentious-sounding “methodology”, which more correctly means “study of methods”). To address, but not necessarily answer, this question, I first consider what designing involves in a wider context, and then compare this with what we do, and finally consider what this might imply for the future     

The politics of requirements management

There are all sorts of requirements management, engineering, and specification methods out there. Most if not all were created by people who like precision, diagnosticity, and rigor-and who care about the software design and development process to the relative neglect of other, more organizational processes. Requirements management is a political process, not a technical one. Programmers need good user and software requirements specifications to write “good” code. And many contracting officers need to see requirements documentation before they'll pay invoices. But requirements management's real importance lies in its other functions: to control expectations, to focus or diffuse blame for the inevitable, and to provide air cover for the otherwise well-meaning but naive programming teams that actually think they're satisfying user requirements. Let's step back a moment and ask some fundamental questions about where software projects come from. Some are obviously well bred: users (end users and business partners) discover some real problems that can be solved by modifying a computer program somewhere. Others come from strategic decisions about a company's line of business. But most come from preferences, from intuition about value, from the stores of pet projects we all carry around with us, or from programmers' lists of changes they'd like to make but weren't initially funded to implement. The author opines that requirements data is highly perishable, often inaccurate, and frequently manipulated to serve all-but-invisible political agendas. In short, most projects could not pass a purposeful requirements analysis test to save their life     

Managing for Innovation: The Two Faces of Tension in Creative Climates

Part of managing for innovation is creating the appropriate climate so that people can share and build upon each other's ideas and suggestions. Yet, there are increasing pressures and potential unproductive levels of tension within organizations. This article points out the distinction between two forms of tension that appear within the research on organizational climates for creativity as well as the conflict management literature. The Debate dimension is described as reflecting a more productive idea tension and the Conflict dimension suggests a more non‐productive personal tension. A series of studies, across multiple levels of analysis, are summarized and a new study is reported in order to highlight the finding that relatively higher levels of Debate, and lower levels of Conflict are more conducive to organizational creativity and innovation. A practical model for the constructive use of differences is shared, along with a few strategies for reducing the negative tension associated with Conflict and increasing the positive aspects associated with Debate.     

The evitability of software patents

Responding to Kenneth Nichols' article in Computer (“The Age of Software Patents”, April 1999, pp. 25-31), the author disputes the two claims: “software patents are neither inherently good nor bad” and “software patents are here to stay.” The author thinks software patents are not impersonal technology, but rather a part of an intellectual patent system that is a social artifact. Because all social artifacts are fair game for judgments, software patents fall into that category. Not only does the author think it reasonable that an interested party examine the ethics and morality of any branch of the legal system (of which software patents and copyrights are a part), but he feels professionals in relevant areas have a social duty to do so. After exploring several arguments for software patents and copyrights, the author settles on the evitability of software patents, though he points out this does not ensure they will be avoided. However, he thinks there are good arguments for avoiding software patents for other more practical and just forms of monopoly for software     

Virtual worlds,augmented reality,blended reality

The internet could be considered just another collection of digital tools, but it has had a more profound impact on how we live, work and play than most people would have predicted. The internet makes everywhere local. For the exchange of ideas and data, it does not matter where you are on the planet. For an industrialized society, or for one forming to emulate existing ones, this creates an interesting situation. If people can work and communicate at any distance the current organization of corporations, cities and even countries changes. However, the legacy set of tools available to communicate at distance miss many of the vital elements we use as humans. Telephones, email and web pages filter out much of who we are. It is very easy, therefore, to dismiss any new technology as more of the same and to stick with the legacy tools. We lose the notion of space, location, size, physical presence and nonverbal communication in the “traditional” internet tools. This tension between what we currently do and what we need to do acts as a flashpoint that causes new inventions to emerge.The internet helps spread these inventions, and acts as the expression of them. These evolutionary steps in our communication are not restricted to the keyboard and screen, so not only challenge our organizations they also challenge our ideas of what the norm is for computing. Looking at the components of some already exciting technologies and combining them with a changing society becoming well versed in freedom the internet can offer, leads us to a very close future, etc. One with a blended reality where digital and physical mixes in combinations that suit us as people. The future is already here we just have to join it.     

软件集成开发环境的技术债务管理研究

软件技术债务是运用经济学中“债务”的概念来描述软件开发中因项目短期利益而实施的技术折中。但从长期来看,技术债务会影响软件的质量、成本和开发效率,因此有必要对其进行有效管理。现有的技术债务管理工具数量少且存在各种局限性,难以实现有效的管理。主流的软件集成开发环境功能强大且应用广泛,可以为技术债务管理服务。以具有代表性的集成开发环境Visual Studio 2015企业版为研究对象,通过C#实例发现其管理4类与代码直接相关的技术债务的能力,并将其与4种专门的技术债务管理工具进行对比,为开发团队的日常实践提供技术债务管理支持。结果表明,Visual Studio能够提供更好的技术债务管理功能,并能应用多种方法对项目中存在的各类技术债务进行不同程度的管理。     

Einsatz der Informationsmodellierung bei der Einführung betrieblicher Standardsoftware

Information models are an established instrument to handle the complexity of information systems. In addition to software development and business process management the implementation of packaged software is one of the major application domains of information models. This contribution investigates through an explorative study, how information models are currently used in the context of packaged software implementation. Object of investigation is the implementation of billing software within utility companies. The study indicates that most companies of the sample applied information models within their implementation projects. Process and data models are more common than other models. However, only a minor part of the companies used dedicated modeling tools for the development and management of the models. The major application domain of information models was the configuration of the software, whereas model based software selection was from subordinate interest. The majority of companies who have applied information models will do this in future projects again     

A systematic review on multi-device inclusive environments

The challenge of designing universal access to knowledge demands considerations on multi-device interaction. A systematic review of inclusive environments built from multiple devices was conducted based on studies published during the period of 2002–2013. The search strategy combined manual and automatic searches from which 8889 studies were identified; 34 studies were found proposing software tools for building multi-device inclusive environments (0.38 % of the original sample). Thus, this study analyzes the ways academic and industrial communities have developed tools for building inclusive environments. The main findings of this review are: (1) an urgent need for the recognition of accessibility as an important non-functional requirement; (2) a need for taking into account the social conditions of users, such as illiteracy and people living in underserved communities; and (3) the identification of new research questions in the context of multi-device inclusive environments.     

基于敏捷软件过程的债权管理系统开发

敏捷方法是一种面临迅速变化的需求快速开发软件的新开发方法,这种方法以快捷、轻便的思维方式,迅速解决了一些传统软件开发企业的生产效率问题,得到了迅速的推广。介绍了敏捷软件过程与极限编程的主要内容,并以一个债权管理系统的开发为例,展示了其实际应用过程。     

Using metrics to evaluate software system maintainability

Software metrics have been much criticized in the last few years, sometimes justly but more often unjustly, because critics misunderstand the intent behind the technology. Software complexity metrics, for example, rarely measure the “inherent complexity” embedded in software systems, but they do a very good job of comparing the relative complexity of one portion of a system with another. In essence, they are good modeling tools. Whether they are also good measuring tools depends on how consistently and appropriately they are applied     

Do we ever really scale down? [Software management]

The argument that scaling down project engineering practices is just as difficult as scaling them up is, in polite terms, specious. The practice of building software has always involved an initial effort to decompose the task into manageable chunks-and from there, we always scale up. The difference between engineering large and small projects focuses on the issues of coordination and communication between the manageable chunks and the people working on them. Practices at the “chunk” level reflect a combination of the organization's culture and the project manager's personal preferences. In other words, we start by decomposing the problem and then build the management structure necessary to bring the various pieces together. We start small and scale up, so where does “scaling down” enter the picture? This issue is largely of concern only to those who value the purity of their methodologies above the practical needs of producing software