Current requirements engineering practices for gathering user input are characterized by a number of communication gaps between users and engineers which might lead to wrong requirements. The problem situations and context which underlie user input are either gathered back in time, or submitted with wrong a level of details. We think that making user input a first order concern of both software processes and software systems harbours many innovation opportunities. We propose and discuss a continuous and context-aware approach for communicating user input to engineering teams and other users, by a) instrumenting the problem domain, b) proactively recommending to share feedback and c) annotating graphical interfaces.

Software evolution draws its complexity from a variety of factors, including extensibility, maintainability, and the difficulty of changing a program's design. It is widely accepted that even well-designed object-oriented programs can become brittle as they evolve, because their design has to be fixed at some point, and the more their implementation has progressed, the more difficult it becomes to adjust object interfaces and relationships.

We assert that the complexity of software evolution can be reduced by relaxing strong encapsulation and information hiding, and introducing concepts such as continuous information flow. These principles are captured in harmony-oriented programming, a paradigm inspired by concepts of Asian philosophy, such as harmony, resonance, and fields of interactions. This paper illustrates the constructs of harmony-oriented programming and several studies aimed at showing that, in comparison with traditional object-oriented programming, harmony-oriented programming is a more suitable approach for dealing with software evolution effectively.

Traditional formal methods and modern agile methods are separated more by limitations of current technology than by fundamental intellectual differences. A mixed interpreter that executes mixed programs, comprising both declarative specification statements and regular imperative statements, might bridge the gap. This paper explores how such an interpreter might be used, showing by example how it might support a variety of development activities.

Design pattern density is a metric that measures how much of an object-oriented design can be understood and represented as instances of design patterns. Expert developers have long believed that a high design pattern density implies a high maturity of the design under inspection. This paper presents a quantifiable and observable definition of this metric. The metric is illustrated and qualitatively validated using four real-world case studies. We present several hypotheses of the metrics meaning and their implications, including the one about design maturity. We propose that the design pattern density of a maturing framework has a fixed point and we show that if software design patterns make learning frameworks easier, a frameworks design pattern density is a measure of how much easier it will become.