programming for non-programmers
Users want to express their desires to a computer and have the computer fulfill their wishes on demand. We frequently see this desire manifested as software "requirements" for configurability or customization without the need for programming. Users view programming as a highly technical, error prone, and cumbersome chore that should be left to professional software developers.
Users would like developers to produce software that is capable of intelligently adapting its structure and behavior to the needs of the day, as the environment and the business requirements change. Users believe they should be able to inform the software of these requirements through intuitive visual techniques. Click on a tool and fill in some information. Drag and drop some icons across the screen. New computations, new algorithms, and new ways of doing business should be configurable with a few clicks by users, who know nearly nothing about how a computer executes instructions, the nature of such instructions, and how such instructions come into existence.
What users do not realize is that the act of expressing themselves through clicks and gestures to produce instructions for the computer is itself an act of programming. The complexity involved in formulating those instructions is proportional to the degree of intelligence intrinsic to the computation. The breadth of requirements that can be satisfied by those instructions is a function of how much can be expressed by the user. Narrow coverage of requirements implies an inflexible system that targets a niche problem domain. Broad coverage of requirements implies a general purpose system.
General purpose programming languages have traditionally been expressed as text. Like all languages, programming languages have a vocabulary, words formed from a character set, and a grammar, which governs how to organize those words in meaningful ways. Textual programming languages allow humans to express themselves concisely in a form that is both precise enough for a computer to comprehend and similar enough to natural language (e.g., English) to be intuitive. General purpose programming languages have naturally evolved from primitive instructions close to the machine (e.g., assembly language) to abstractions that correspond to natural language. Text is a highly efficient and flexible method of communicating ideas. An alternative technique using graphical images may be applicable for expressing ideas that can be tangibly visualized, but images are wholly inappropriate for non-visual ideas. An image may be able to convey a thousand words, but to have control over exactly what words to formulate would not be easy by using visual techniques.
We can expect that programming languages will continue to advance to become more intuitive to humans and more efficient at expressing complex instructions to machines. We can also expect that graphical techniques will continue to evolve to make programming easier to both professional programmers and users, who don't want to program. What we must accept is the fact that instructing a machine is programming, regardless of whether it is expressed as text or using visual techniques.
ridiculous marketecture notation
The following is an open letter to the
OMG.
Date: Fri, 17 Mar 2006 01:59:42 -0500
From: Ben Eng
To: info@omg.org
Subject: non-technical visual notation for UML (Ridiculous Marketecture Notation)
Message-ID: <20060317065942.ga4298@jetpen.com>
Will the OMG be defining a standard for a visual notation appropriate
for non-technical presentations (Ridiculous Marketecture Notation),
which can be used to present models of software architectures
according to a UML profile?
Examples:
http://www.mysql.com/common/images/PSEA_diagram.jpg
http://labs.jboss.com/portal/jbossas/images/appInstrumentation.gif
http://www.omg.org/gettingstarted/Images/oma.gif
http://www.omg.org/images/logos/diagram-client_to_request_to_object_implementation.gif
http://technology.wildlifecenter.org/images/WCV_net.jpg
Note that ad hoc notations for presenting software architecture
diagrams for marketing purposes continue to abound and proliferate,
because they are more intuitive to non-technical audiences (and in
many cases even to UML-savvy software professionals). There ought to
be a way for UML diagrams to be presented in a more visually appealing
way so that ad hoc notations can be avoided.
Software requires UML diagrams that are intuitively consumable by
non-technical audiences for the same reasons that architectural
blueprints for building construction are intuitively consumable by
home developers and home owners, who contract them. UML diagrams that
are only consumable by those who produce the diagrams and implement
the software are only addressing half the stakeholders. The other half
include those people, who are the source of the requirements and the
users of the software.
vorlons and shadows
Babylon 5 is a story about two differing philosophies. The Vorlons promote a life of order, stability, and peace. The Shadows promote a life of chaos, destabilization, and conflict. There is a similar philosophical difference in software development.
Hubris of Prescience
Most commercial software projects lean towards a philosophy of order, stability, and peace. Optimism leads to anticipating stable requirements, which would allow for a stable design. This outlook influences management and developers to behave in a particular way. We gain an expectation for requirements and design to be orderly, stable, and for a peaceful progression of events to ensue. Successful methods and techniques are expected to continue to be viable. The products of past investments into research are expected to be retain their value with the passage of time. Knowledge of the present incubates a confidence in being able to anticipate future needs. This confidence is reinforced by the belief that momentum has longevity. This belief is correct, but not in the way that we would hope for a healthy technology business.
The technology market relies upon continuous innovation. Innovation is about disruptive change. A strategy based on incremental improvement bets on a steady pace of change, where one's own product is the market leader. Trailing competitors are constantly seeking to impose revolutionary change upon the market to overtake the market leader. If one is not in the lead, then it makes sense to disrupt the market to put oneself in an advantageous position. New markets are created, where old ones are destroyed. Competitive innovation radically alters requirements, thereby invalidating entrenched designs. Disruptive change accelerates demand for technology through obsolescence.
The lure for the market to adopt innovative products is efficiency gain. Gains in efficiency increase productivity or reduce costs - or both. A methodology promoting the entrenchment of a status quo is unable to adapt to an environment of unrelenting disruptive change. In technology, the status quo is precisely what must be destroyed in order to sustain a healthy market. A strategy of maintaining an entrenched design is a strategy of certain failure in the technology market.
Creativity and Renewal
While a life of order, stability, and peace breeds comfort, it also leads to stagnation and complacency. Creative individuals will recognize, where the status quo is not good enough. A culture that institutionalizes the status quo cripples creativity, ensuring a disadvantage in relation to the competition, who seeks disruptive change.
Innovation is nurtured by an entrepreneurial spirit. There are several factors that are required to facilitate creative thinking: freedom, motivation, inspiration, and courage. Creativity needs a culture that promotes creative ideas by nurturing independent thinking, not obedience to instructions delivered by management or designated "thought leaders"; individuals will be willing to think if they are entrusted to do so. Motivation comes from achievable goals, incentives, and the rewards of a job well done. Inspiration comes from the growth and enjoyment of working with peers, who demonstrate competencies, which become a source of knowledge. Finally, courage is provided by the willingness to incur risk to achieve the rewards that come from unconventional thought; people who are confident enough in their ability to attempt great things should be encouraged to do so, because overcoming technical problems is daunting enough without the burden of an unsupportive culture.
The key characteristic of a technology business that is prepared for innovation is agility. It must be adaptable quickly to change. It must embrace disruptive change, and use change to its advantage, rather than being resistant or vulnerable to it. This includes a high degree of tolerance for risk, because change is inherently risky, and the more disruptive the greater the risk (and potentially the reward). Innovation opens opportunities, but a business must be able to pounce on an opportunity to benefit.
Until Moore's Law no longer holds, we can expect innovative growth to continue. Technology innovation and obsolescence is the dominant trend. A technology business that does not institutionalize a culture that embraces disruptive change will not be a business for long.
sabotaging JDO's market momentum
Posted in response to
JDO 2.0 Public Review Ballot by Robin Roos on TheServerSide.com:
The absence of technical objections to JDO 2.0 and the recurring theme of confusion with JSR 220 persistence indicates that the purpose of the votes against JDO 2.0 are to prevent JDO 2.0 implementations (which many JDO vendors are already making preview releases available) from gaining market momentum before JSR 220 persistence implementations appear for the first time.
Their fear is not "market confusion". It is market certainty that proven JDO 2.0 implementations will reach the market and achieve broad success (market share) long before JSR 220 persistence reaches the market, thereby relegating JSR 220 persistence to irrelevance. They know that successful adoption of a technology will make it virtually impossible to displace with an alternative that arrives late, even if it exhibits some modest degree of superiority. The technology with dominant market share will also not remain stagnant, and its vendors would quickly incorporate improvements according to demand.
There is a large community of developers with both money and expertise to invest in adopting a prolific persistence technology. It is a ubiquitous problem for many applications. There is fear that JDO 2.0 will be adequate to the needs of many, rendering the promise of JSR 220 persistence irrelevant, if JDO 2.0 is widely adopted quickly. The only confusion that would ensue is the consequent irrelevance of JSR 220 persistence to the market.
Therefore, I would suggest that if the Java Community Process is acting against the interests of the community that it proports to serve by sabotaging a technology that the community demands, the JDO vendors should release their products according to the latest available draft without the endorsement of the JCP Executive Committee. The market can vote with their hearts, minds, and dollars; the politically motivated votes in favor of JSR 220 persistence would merely become a hollow victory for the opponents of JDO 2.0.
a better software business model
In my previous blog,
innovation as the enemy of maturity, I describe some organizational and technical patterns that can help to empower innovation, as a software development firm grows. Removing internal impediments to innovation does not alleviate the commercial impediments.
Commercial off the shelf (COTS) software aims to provide generalized capabilities, in order to be attractive to a broad market. Enterprise applications are sensitive to business processes and business policies, which are highly specialized to each organization. One size does not fit all organizations. Each deployment will have its own idiosyncrasies. Some will demand features that are not generally useful to others. Others will demand customizations that are exclusive, not made available to the general market. The former pollutes an application, so that each deployment utilizes a shrinking subset of the features, while having to endure the growing footprint of unwanted baggage. The latter burdens the software with the growing complexity of a diverse set of customizations. Both are symptoms of a chronic bloat.
COTS software is normally structured so that there is a license fee to purchase an application for a particular use, followed by a recurring annual maintenance fee for support and bug fixes. The customizations often associated with enterprise software incur additional fees for professional services. This business model influences the software in the following ways.
- New features are constrained by the software vendor's release schedule, which is usually on a 6-18 month cycle;
- Feature prioritization is weighted by the general market demand;
- Development is limited by the resources provided by the vendor; and
- Design decisions are dictated by the software vendor.
The COTS software business is modeled to maximize the software vendor's revenue by seeking out the highest value subset of generalized features that are widely in demand by the greatest number of customers. By attempting to satisfy a few needs for all customers, no single customer can be wholly satisfied. Usually a generalized solution to a problem with many specialized variations can only partially solve the problem for any particular circumstance.
Enterprise software requires a business model that can adequately satisfy the demand for specialized solutions to specialized problems, while leveraging generalized solutions to generalized problems. A customer with a need for features to be developed according to a schedule should be able to fund and resource that development without being constrained by a single source and the lack of design authority.
Customers can be better served by a business model, where an annual fee is paid for a subscription to the software source code, development infrastructure, customer support, and community resources. The market for innovative designs expands to include contributors, who are much more familiar with the problem space (the user community). Competition helps to seek out the best solution, and it benefits the whole community. Each customer selectively builds the application to include only the desired features with their specialized extensions and customizations on their own schedule. Enterprise customers tend to contract professional services to implement extensions and customizations. This community source model empowers consultants, and attracts systems integrators and channel partners to improve sales instead of compete. A subscription based community source model is good for customers and good for the software vendor.
