Rescuing Code

Imagine you've experienced project heat death at least once. The term "heat death" comes from the second law of thermodynamics: entropy within a closed system increases over time without bound until the system collapses. In software, the entropy we experience most is in the design. Most of the code we add increases design entropy. Project heat death occurs when the design rots to the point where starting over is cheaper than continuing. Project heat death seems inevitable, yet when a large-scale project dies, people often stand around, surprised, asking "why us?" To do better next time, you need a sense of what problems to look for, and you need to start solving them before they spiral out of control. The author hopes this department helps in both regards.     

患者自助服务系统人机交互界面设计概述

患者自助服务系统通常是一系列用户可以自行操作并解决问题系统的总称,它可能包含了摆放在医院院内的自助机,用户手机上的小程序、公众号,甚至是在任何可能可以使用浏览器设备上所呈现的网页服务。自助服务系统以其便利、高效、减少人工降低成本等优势而在越来越多的地方得到广泛应用,但同时也由于用户认知上的差异及自助服务系统本身交互设计上的问题,很多时候并没有起到应有的作用,存在不会用、不好用、不想用等问题。为了更加高效地为患者提供服务,充分发挥自助服务所带来的优势,降低用户学习成本,提出了一种患者自助服务系统人机交互界面设计的概述,以实现所见即所得式的人机界面交互。     

Explaining Your Design

Have you ever tried to explain some aspect of your design and not known where to start? Perhaps you had to present how you solved a problem or justify your chosen design among several alternatives, and you weren't sure how to highlight key design aspects critical in achieving a certain requirement. Design decisions with widespread impact or design nuances that might confuse new team members can benefit from good definitions and narrative explanations. When fellow designers repeatedly ask, "why did you do it that way?" It's good to have an effective presentation that explains the tricky parts of your design without losing people in the details     

Up-front Design

There can be significant benefits in thinking through a design until you get it "right enough" before launching into a major development effort. For such up-front design to be effective, you must develop a design rhythm that balances thinking, learning, and doing.     

Who ya gonna call! You're on your own [software usability design]

The issue here is not whether discount techniques should be used; they are inevitable. The issue is, in trying to do the best job you can with the ridiculously limited resources provided you, what should you do? How confident should you be in the techniques you are using? A bad design may come back and bite you. When you choose a technique to use in a hurry, you are placing your professional reputation and perhaps your job on the line. You deserve to know four things about any technique that you apply. The hit rate: How many real problems will this technique uncover? The false-alarm rate: How many (and what sorts) of things will it falsely identify as problems (that may not exist, but are costly and time consuming to “fix”)? What does it miss? What types of problems (and how many) does this technique not discover? The correct rejections: How confident are you in your discount technique's ability to flag problems? Discount techniques are not a substitute for the potent combination of analytic and empirical methodologies that usability professionals can bring to bear in designing and evaluating an interface     

Design Strategy

Software designers and managers can find it challenging to agree on the "sweet spots" of their system that warrant their best design efforts. Most projects are short on time, budget, and resources. How can you stay ahead of the design curve, and where should you focus your design energies to gain the most leverage? The essence of strategy is that you must set limits on what you're trying to accomplish.     

Usability Testing: A Journey, Not a Destination

Usability testing for interfaces can fit into a design project in several ways. The author looks at how good testing techniques can make projects run better and faster, and produce an improved result. The primary point is that there's no incompatibility between usability testing and a rational product process. We can think of usability testing as simply another aspect of quality assurance, and can fold it into the product process in much the same way as software quality assurance (QA). By having usability people involved from the beginning, big problems get found earlier, and small problems get found in time. The fear of losing control of a project to a usability person who finds a last-minute interface design problem is therefore a red herring. You can indeed find usability problems that might affect project completion late in the development process, just like you can find system architecture problems. But the way to keep this from happening is to test your system and your ideas during each stage of development, gathering the kind of information you need at each of those stages. That's why usability testing is a journey, not a destination     

Before clarity [software design]

Most software developers become preoccupied with the question of what makes good design at some point in their careers, usually after witnessing the effects of bad design first hand. At that point, we start to reflect. We go through a stage where we feel we know what good design is but can't really define it. Then we learn various design principles and rules of thumb that make it easier to judge what constitutes good design. But when these principles and rules conflict, we have to make trade-offs and decide what's most important in each situation. The blanket rule of thumb: Keep design as clear as possible. Regardless of the trade-offs, the most important thing was clarity. If a system uses a straightforward coding style - the classes and methods are well named and small enough to be clearly understood, and the system isn't littered with snarls of obscure code - then you can do just about anything. You can change the system with impunity, write tests for it, make adjustments, and add features, all with relative ease. So "clear design is good design" seemed like a reasonable rule of thumb because so much of what makes code impossible to maintain comes down to a lack of clarity. If you can understand your system, you can change it effectively.     

Designing Extensible Classes

This paper discusses about the design of extensible classes. Designers seek design rules that guarantee well-formed class hierarchies, appropriate interfaces, and easily extensible classes. Unfortunately, the detailed design of extensible class hierarchies is filled with nuanced reasoning. Building clean abstractions with clearly defined extension points is satisfying, but the best design choice isn't always obvious. How much access should you give a subclass to a class's inner workings? How much freedom should you give a subclass designer to "bend" inherited behaviors to make a new abstraction fit in or to extend an existing one? These decisions involve nuanced reasoning. The contract between a class and its subclasses requires thoughtful design, experimentation, and careful specification.     

Probability and agents

To make sense of the information that agents gather from the Web, they need to reason about it. If the information is precise and correct, they can use engines such as theorem provers to reason logically and derive correct conclusions. Unfortunately, the information is often imprecise and uncertain, which means they will need a probabilistic approach. More than 150 years ago, George Boole presented the logic that bears his name. There is concern that classical logic is not sufficient to model how people do or should reason. Adopting a probabilistic approach in constructing software agents and multiagent systems simplifies some thorny problems and exposes some difficult issues that you might overlook if you used purely logical approaches or (worse!) let procedural matters monopolize design concerns. Assessing the quality of the information received from another agent is a major problem in an agent system. The authors describe Bayesian networks and illustrate how you can use them for information quality assessment     

Literate programming simplified

Literate programming tools let you arrange the parts of a program in any order and extract documentation and code from the same source file. The author argues that language-dependence and feature complexity have hampered acceptance of these tools, then offers a simpler alternative     

从使用者的角度浅析婴儿车设计

在婴儿车的设计中,设计者很少从使用者的角度去分析与研究婴儿车在设计中应注意的问题。针对这一现象,文章通过从如下两个方面,一是从婴儿角度浅析婴儿车的设计,二是从成人的角度浅析婴儿车的设计,阐述如何站在使用者的角度去注意婴儿车的设计问题,旨在为今后的婴儿车设计提供更好地参考,使婴儿车在设计上更加地合理化和人性化。     

Science is in the eye of the beholder

The way you view science limits the things that you can do "scientifically". Fortunately "science" is not a single thing but an evolving concept of how to cope with the world, and this flexible attitude towards science can be useful. The rigid view gives strict guidance on how to proceed "scientifically", while the more flexible approach allows for a greater range of response on your part. This paper gives some of the various views of what science is, in the hope that it will liberate you from being too strict without at the same time losing the useful guidance that "science" often provides.     

Near misses: Murphy's law is wrong [design engineering]

It has been said that you learn more from your mistakes than from your successes. Best of all is when you can learn from someone else's mistakes. So this article looks at three test cases. (1) What did engineers and computer scientists learn about product development when the Space Shuttle Challenger exploded? (2) What did you resolve to do better after the Hubble Space Telescope error? (3) What did you learn from the Mars Climate Orbiter error? In all three of these cases, there is plenty of learning to be had for anyone doing design in any field. Murphy's law ("If anything can go wrong, it will go wrong") is clearly incorrect. When the Challenger exploded, the problem was quickly traced to the O-rings in the solid rocket boosters because those O-rings were already under suspicion due to charring and hot-gas "blow-by" in half of the previous 25 Shuttle missions. Murphy's law implies those earlier flights should have blown up, but the lesson embedded in those near misses went unheeded. NASA says there were even hints during the Mars Climate Orbiter flight that something was wrong. Perkin Elmer ignored several indications that something was wrong with Hubble's main mirror. Near misses are nature's way of telling us that something's wrong and we'd better fix it fast. If we ignore them, that's when Murphy comes calling     

Handling Design Criticism

Design reviews are an essential part of any design process. However, taking the criticism that comes from such reviews can be hard. The word criticism even has a slightly negative connotation in our culture. But design criticism is invaluable, and effectively giving and receiving it are skills that every software designer needs to master. It can be difficult to filter out constructive arguments from the noise or to discern the reasoning behind offhand remarks. Knowing what tactic to take when someone criticizes your design can keep your creative design flowing and help you improve your ideas. This article gives a summary of some kinds of design criticism you might receive and how you might react     

WIT: Weka interface translator

Advancement in technology turns the big world into one small village. Regardless of what country you are living in, what language you are speaking or understanding, you should be able to benefit from the accumulated knowledge available on the Internet. Unfortunately, this is not the case with English being the de facto language of most programming languages, services, tools and web content. Many users are blocked from using these tools and services because they do not speak or understand English. Multilingual software evolved as a solution to this dilemma. In this paper, we describe the design and implementation of a user-friendly toolkit named Weka interface translator (WIT). It is dedicated to internationalize Weka, which is a collection of machine learning algorithms for data mining tasks widely used by many researchers around the world. WIT is a collaboration project between the Arabic natural language processing team from the University of Jordan and Weka’s development team from the University of Waikato. Its main goal is to facilitate the translation process of Weka’s interfaces into multi-languages. WIT is downloadable through SourceForge.net and is officially listed on Weka’s wiki spaces among its related projects. To experiment with WIT, we present Arabic as a pilot test among many languages that could benefit from this project.     

域间路由策略的协同管理问题

互联网由多个自治域互联组成,自治域之间按照各自的域间路由策略交换路由信息和转发流量。由于管理自治域的ISP各自为政,独立配置和管理自己的路由策略,缺少协同机制,容易引起路由震荡、热土豆路由、异常路由等问题。本文提倡采用协同的方式管理域间路由策略,通过列举一些典型的域间路由策略问题,提出一套域间路由策略的多方协同控制与管理体系,并重点讨论了协同管理的基础性问题--安全比较协议。该协议可以被应用在互联网域间路由策略的管理中,对于分布式故障检测、分布式网络性能能测量等相关应用,也具有较好的参考价值。     

The specification of “specification”

The notion of specification plays a key role in the developing science of computing. It is typically considered to be the keystone in the software development process. However, there is no single, generally agreed meaning of specification that bears close scrutiny. Instead there is a variety of different, although partially interlocking and overlapping interpretations of the term.We catalogue this varietal profusion and attempt to lay bare both the sources and consequences of each major alternative. We attempt to present the full range of possibilities, and the biases inherent in each style of interpretation.We believe that there is a pressing need for clarification of the meaning of specification (and several other important terms), especially in view of the fact that so many practitioners and theoreticians assume, erroneously, that a clear meaning already exists (even though they might disagree as to what it is). In particular, we feel that a more general awareness of the difficulties that currently attach to this key concept may go some way towards bridging (if not actually healing) the rift that currently exists between the engineering and scientific aspects of computing.The most deadly thing in software is the concept ... that you are going to specify what you are going to do, and then do it. And that this is where most of our troubles come from. Ross, Garmisch.What happens is that specifications of software are regarded as functional specifications ... It is my belief that anybody who is responsible for the implementation of a piece of software ... must specify the design, the form. Sharp, Rome.No matter how precisely you try to specify a system, once you have built it you find it isn't exactly what is wanted. Oestreicher, Rome.... the admission of shortcomings is the primary condition for improvement. Dijkstra, Garmisch.     

Using patterns to create component documentation

Good documentation facilitates communication between a component's creator and its users, providing insight into design intent, use cases and potential problems. Patterns can provide guidance on documentation content, structure and presentation. Four examples are presented that show you how     

Online monitoring: security or social control?

Imagine your big brother habitually following you around "for your own good" and snooping into everything that you, a mature adult, choose to do. Now imagine discovering that he couldn't do so if you wore blue socks rather than brown. Wouldn't you switch to blue socks as a matter of principle? Online monitoring today presents a similar situation. You can indeed modify your online conduct to preserve your privacy almost as easily as you can change socks.