Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Software Prototyping using Scripting Languages  and Two language Approach

News Real Insights into Architecture Come Only From Actual Programming Recommended Links  Scripting Languages  Software Life Cycle Models KISS Principle
Literate Programming Unix Component Model   Featuritis Humor Etc

Software prototyping, refers to the activity of creating "disposable", threw-away version of  software applications to test the key ideas of the architecture .

A prototype typically simulates only a key aspects of the system, avoiding bells and whistles and as such can use different, higher level implementation language then the final product. It also can be a virtual machine, not a software implementation in traditional sense (see below).

As Wikipedia article states

Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development and debate since its proposal in the early 1970s.[6]

The monolithic "waterfall" approach to software development has been dubbed the "Slaying the (software) Dragon" technique, since it assumes that the software designer and developer is a single hero who has to slay the entire dragon alone. Prototyping can help in avoiding the great expense and difficulty of changing an almost finished software product due to changes in specification or understanding of the problem (and understanding of the problem often comes too late in the "prototype-less" development of software).

The process of prototyping involves the following steps

  1. Identify key requirements
    Determine key requirements including the input and output information desired. Details, such as security, can typically be ignored.
  2. Develop the Initial Prototype
    The initial prototype is developed that includes only key parts of the system. The customers, including end-users, can provide some (limited) provide feedback on what is right and what is wrong in the specifications and implementations. Often at this point specification radically changes.
  3. Review of architectural solutions
    Typically the initial approach to architecture is sub-optimal and during the implementation of the first version better ideas surface. That's why it is of paramount important that architects were part of the prototype implementation team and "feel the heat" of selected approaches to system design.
  4. Revise and Enhance the Prototype
    Using the feedback both the specifications  can be made more realistic, often some requirements can be simplified or eliminated.  Negotiation what is within the scope of the project are very important part of getting high quality system in time and within budget.
  5. Rewrite part of all prototype creating production version of software.

Approaches to prototyping

There are several appaches to prototyping. Among them there are two more or less realistic:

 

Throwaway prototyping

Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.[7]

The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.

Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.

…it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models. [8]

Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a GUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality.

Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of storyboards, animatics or drawings. These are non-functional implementations but show how the system will look.

SUMMARY:-In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are:

  1. Write preliminary requirements
  2. Design the prototype
  3. User experiences/uses the prototype, specifies new requirements
  4. Repeat if necessary
  5. Write the final requirements
  6. Develop the real products

Evolutionary prototyping

The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built.

When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.

"…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."[5]

This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase.

For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changes…we often try to define a system using our most familiar frame of reference---where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.[9]

Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.

"It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version…The user may decide that a 'flawed' system is better than no system at all."[7]

In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.

To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.[10]

Role of scripting languages in prototyping

Scripting language are ideal for software prototyping. Included among these benefits is the ability to address rapidly changing software requirements. In addition, the efficiency gained from user-centered design, which consists of constant user feedback impacting the software design, has received significant attention recently [Landauer95]. Fast compile-debug-test cycles, and high programming flexibility make dynamically typed languages such as Perl, Python, PHP  and Tcl  ideal for the rapid creation of prototypes both on compoment and system levels

Ousterhout was the first to argue that a two language approach is both feasible and practical for software development [Ousterhout97] and created the scripting language (TCL) that has a transparent interface with C and can be extended using C modules. Python also provide consistent interface to C to allow developers to move performance critical methods and procedures into C without modification of the calling code.

Supporting prototyping requires a language which can support transformation of components previously written in cscritping langue into low level statically typed compiled language (C or C++) and vise versa. Currently, few scripting languages allow for this type of flexibility.

If developers choose to use a statically typed language (for example Java) they often encounter problems in the early prototyping and development phases.

These limitations often make it difficult to use statically typed languages for rapid prototyping of all or part of an application.

On the other hand, if developers choose to use a single dynamically typed language they often encounter problems in the latter phases of development when performance, scalability, and maintainability become critical issues. They often encounter performance problems when writing computationally intensive code and tend to  spend an unordinary amount of time optimizing code. They may also suffer scalability problems related to CPU and memory usage typical for scripting languages. The detection of all coding errors is delayed until the actual line of code containing the error is executed  meaning that complex tests must be written in order to check the validity of code. Despite the benefits of a scripting languages, these limitations increase the cost of maintaining a large codebase. 

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Mar 20, 2013] PROTOTYPING

    1. TYPES OF PROTOTYPE
      1. LOW-FIDELITY versus HIGH-FIDELITY
        1. LOW-FIDELITY
          A set of drawings (e.g., storyboard) that provide a static,
          non-computerized, non-working mock-up of user interface for
          the planned system
        2. HIGH-FIDELITY
          A set of screens that provide a dynamic, computerized,
          working model of the planned system
      2. EXPLORATORY versus EXPERIMENTAL versus OPERATIONAL
        1. EXPLORATORY
          A throw-away prototype used to clarify project goals, to
          identify requirements, to examine alternative designs, or to
          investigate a large and complex system
        2. EXPERIMENTAL
          A prototype used to validate system specifications
        3. OPERATIONAL
          An iterative prototype that is progressively refined until
          it becomes the final system
      3. HORIZONTAL versus VERTICAL
        1. HORIZONTAL
          A prototype that models many features but with little detail
          • a horizontal slice of a system's structure chart from the
            top down to a specific depth
          • most useful in the early stages of design
          • purpose is to test the overall interaction metaphor, so
            includes common functions that the user is expected to
            perform frequently
        2. VERTICAL
          A prototype that models few features but with much detail
          • a vertical slice of a system's structure chart from top
            to bottom
          • most useful in the later stages of design
          • purpose is to test details of the design
        3. DIAGONAL
          A prototype that is horizontal down to a particular level,
          then vertical below that point
      4. GLOBAL versus LOCAL
        1. GLOBAL
          A prototype of the entire system
          • an expanded horizontal prototype that models a greater
            number of features and covers multiple levels of the
            system's structure chart
          • useful throughout the design process
        2. LOCAL
          A prototype of a single usability-critical system component
          • a vertical prototype that is focused on one feature
          • useful at some specific stage of the design process
    2. DIMENSIONS OF PROTOTYPING
      1. EXECUTABILITY
        Will the prototype be runnable and, if so, what does that mean?
        1. CHAUFFEURED PROTOTYPE
          "runnable" in the VERY LOOSE SENSE that the prototype allows
          a walkthrough to be performed
        2. ANIMATION PROTOTYPE
          runnable in the LOOSE SENSE that it is executes frame by
          frame in "slide show" mode on a computer
        3. TURING PROTOTYPE
          "runnable" in the sense that it executes in "slide show"
          mode BUT allows a third party, hidden from view, to pick the
          next slide based on user input (also called "Wizard of Oz"
          prototyping)
        4. INTERACTIVE PROTOTYPE
          runnable in the STRICT SENSE that it executes on the
          computer AND responds to user input in real time
        5. FUNCTIONAL PROTOTYPE
          runnable in the VERY STRICT SENSE that it executes on the
          computer, responds to live input, and performs some of the
          expected computations
      2. MATURATION
        Will the prototype be improved by stages and, if so, will it
        eventually grow into the final product?
      3. REPRESENTATION
        What level of fidelity will the prototype achieve?
      4. SCOPE
        Will the prototype be limited to specific areas of
        functionality?
    3. CHARACTERISTICS OF A GOOD NON-DISPOSABLE PROTOTYPE
      1. EXECUTABILITY
        Works sufficiently well with live user input to permit
        usability testing
      2. MATURATION
        Can evolve, given sufficient refinement, into the final product
      3. REPRESENTATION
        Has the "look and feel" and performance characteristics of the
        planned system
      4. SCOPE
        As a minimum, simulates the 20% of the functions that customers
        will use 80% of the time
  1. EVALUATION OF PROTOTYPING
    1. BENEFITS AND RISKS OF PROTOTYPING
      1. ADVANTAGES (BENEFITS)
        1. NUMBER 1 BENEFIT
          Prototypes may be easily changed or even discarded.
        2. NUMBER 2 BENEFIT
          Prototyping may improve communication between and among
          developers and customers
        3. NUMBER 3 BENEFIT
          Users may be more satisfied with systems developed using
          prototyping.
        4. A prototype may provide the proof of concept necessary to
          attract funding.
        5. A prototype may serve as a marketing tool.
        6. A prototype may serve as the basis for operational
          specifications.
        7. Early visibility of the prototype may help management assess
          progress.
        8. Exploratory prototyping allows productive work to proceed
          despite initial uncertainties.
        9. Prototypes may demonstrate progress at an early stage of
          development.
        10. Prototypes may provide early training for future users of
          the system.
        11. Prototyping may prevent unpleasant surprises by calling
          attention to incomplete or inconsistent requirements, or to
          missing functionality.
        12. Prototyping may produce some useful deliverables even if the
          project runs out of time or money.
        13. Prototyping may reduce misunderstandings between and among
          developers and customers.
        14. Prototyping may reduce redesign costs if problems are
          detected early when they are cheap to fix.
        15. Prototyping may reduce the time required for testing if
          problems are detected early when they are cheap to fix.
        16. Prototyping may require less effort (43% less, according to
          Boehm, Gray & Seewaldt, 1984) than conventional development.
        17. Prototyping may result in a 50-50 partnership between users
          and developers where both experience "ownership".
        18. Prototyping may result in a product that is a better fit for
          the customer's requirements.
        19. Prototyping may save on initial maintenance costs because,
          in effect, customers are doing "acceptance testing" all
          along the way.
        20. Prototyping may strengthen requirements specifications.
        21. Systems produced through prototyping may be judged easier to
          learn and easier to use.
        22. The horizontal prototyping method works nicely as a
          complement to structured analysis.
        23. The prototyping environment less vested in a particular
          design, hence more open to change and innovation.
        24. Use of prototypes may flush out change requests earlier,
          when they are cheaper to process.
        25. Users may understand prototypes better than paper
          specifications.
        26. Using prototyping during development may reduce the amount
          of code that is finally written (by 60%, according to Boehm,
          Gray & Seewaldt, 1984).
      2. PITFALLS (RISKS)
        1. NUMBER 1 RISK
          Prototpying may encourage an excess of change requests.
        2. NUMBER 2 RISK
          Working prototypes may lead management and customers to
          believe that the final product is almost ready for delivery.
        3. NUMBER 3 RISK
          The excellent (or disappointing) performance characteristics
          of prototypes may mislead the customer.
        4. Customers may not be prepared to provide the level or
          frequency of feedback required for iterative prototyping.
        5. Customers may not be willing to participate in the iteration
          cycle over the long haul
        6. Developers may have difficulty writing the back-end code
          needed to support the slick front-end interface designed
          with the prototyping tool.
        7. Due to time and market constraints, system specifications
          may be frozen before the prototyping process has reached a
          definitive stage.
        8. During prototyping, the only "design specification" is the
          prototype itself, which may allow uncontrolled change.
        9. Early prototypes may be of low fidelity, dismissed as toys.
        10. Hi-fidelity prototypes may be mistaken for a real product.
        11. Important system characteristics (e.g., performance,
          security, robustness and reliability) may have been ignored
          during prototype development.
        12. It may be impossible to prototype mission- or
          safety-critical system functions.
        13. Iterative prototyping may be difficult for management to
          plan and schedule.
        14. Prototypes may become over-evolved, straining to incorporate
          secondary functionality even though that will take
          disproportionately more development time.
        15. Prototypes may embody simplifications and other
          inaccuracies.
        16. Prototypes may oversell the product.
        17. Prototypes of complex systems may themselves be rather
          complex.
        18. Prototyping is an adaptive process that may not exhibit
          well-defined phases.
        19. Prototyping may continue too long because there may be no
          well-defined completion criterion.
        20. Prototyping may force developers to change design
          philosophies (e.g., switch to a bottom-up or an event-driven
          model).
        21. Prototyping may provide little room for testing
          NON-functional system requirements.
        22. Prototyping may stall if members of the team do not have
          enough decision-making authority.
        23. Prototyping, because it may be less controlled than
          conventional development methods, may lead to a reduction in
          programmer discipline.
        24. Specifications that emerge during later prototyping may
          reduce the structural integrity of the partially designed
          system (e.g., increase coupling between modules).
        25. The context of use for a prototype may be very different
          from the context of use for the final system.
        26. There is no guarantee that the positions of developers and
          customers will converge during the iteration cycle.
    2. WHEN PROTOTYPING WORKS AND WHEN IT DOESN'T
      1. PROTOTYPING IS MORE LIKELY TO SUCCEED WHEN ...
        1. used as a means to achieve early usability testing
        2. used to compare alternative designs (the "dueling
          prototypes" technique)
        3. used to create a "living" specification
        4. used to escape from the rigid serial pattern imposed by the
          traditional software development life cycle
        5. used to evaluate a proposed interface
        6. used to explore the effect of change requests
        7. used to expose new or unexpected requirements
        8. used to identify market requirements
        9. used to involve users in the design process
        10. used to model a system that has a significant user interface
          component
        11. used to model a system that is relatively large and complex
        12. used to provide a common basis for good communication
          between developers and customers
        13. used to stimulate customer input during requirements
          gathering
        14. used within a rapid prototyping tool
      2. PROTOTYPING IS MORE LIKELY TO FAIL WHEN ...
        1. no clear terminating criterion has been established to end
          the iterative development cycle
        2. the expectations of customers are allowed go grow beyond
          reasonable bounds
        3. the functionality of an operational prototype does not scale
          up to the functionality required of the final system
        4. the opinions of developers and customers diverge during the
          iterative phase
        5. the project is too small to justify prototyping
        6. the prototype is mistaken for the promised product
        7. used to model systems that present no external interface
          (e.g., embedded systems)
        8. used to gauge the future performance of the planned system
        9. used to market software that does not exist

Software Tech News 2-1 Importance of Software Prototyping

Modern software development demands the use of Rapid Application Prototyping. Professor Luqi at the Naval Postgraduate School coined the term "Computer Aided Prototyping" to describe this work. Her leadership showed its effectiveness in gaining understanding of the requirements, reducing the complexity of the problem and providing an early validation of the system design. For every dollar invested in prototyping, one can expect a $1.40 return within the life cycle of the system development.

Dr. Barry Boehm's experiments showed that prototyping reduces program size and programmer effort by 40%. It is the technology that is the foundation for his Spiral development method. Prototyping is being used successfully to gain an early understanding of system requirements, to simplify software designs, to evaluate user interfaces and to test complex algorithms. It is a best-in-class software approach.

Fully 30 to 40% of system requirements will change without prototyping. Rapid Application Prototyping provides a look at the dynamic states of the system before we build it, whereas most other software engineering focuses on the source code. The special problems of reliability, throughput and response time as well as system features are addressed in the best prototypes. A new field of study, Software Dynamics, will emerge once Rapid Application Prototyping is widely practiced. It will focus on quantitative analysis of how software performs under various loads and include a set of design constraints that will make it possible for us to build components that can be hooked together without exhaustive coverage testing.

Software is hard because it has a weak theoretical foundation. Most of the theory that does exist focuses on the static behavior of the software, analysis of the source listing. There is little theory on its dynamic behavior, how it performs under load. To avoid serious network problems software systems are over-engineered with plenty of bandwidth for two or three times the expected load. Without analysis of the dynamic behavior, application designers have no idea of the resources they will need once their software is operational. Software has the awful propensity to fail with no warning. Even after we find and fix a bug, how do we restore the software to a known state, one where we have tested its operation? For most systems, this is impossible except with lots of custom design that is itself error-prone. Software prototyping has proven its mettle in helping designers avoid these problems in their production systems.

Much has been written about the best way to develop software applications. But there is no "best way." Both prototyping and requirements are necessary. The tried and true process of synthesis and analysis is used to solve Software Engineering problems. Bottom-up is synthesis. Top-down is analysis. Bottom-up is prototyping. Top-down is developing requirements. Prototyping is the best way to encourage synthesis. Prototyping also eases communication with the customer and with the designer. Formal written requirements are needed to establish a clear definition of the job, to control changes and to communicate the system capabilities between the customer and the developer.

So where does this leave us?

Start with an English language written statement of a problem and broadly outline its solution. Now build a prototype for the elements where you need insight. Analyze the prototype using computer aided prototyping technology and synthesize a new solution either by refining the prototype or building a new one. Once you and the customer agree on the workings of the prototype, write requirements that include features, performance goals, product costs, product quality, development costs and schedule estimates.

What do I mean by prototype?

Prototyping is the use of approximately 30% of the ultimate staff to build one or two working versions of various aspects of a system. It is not production code but it may eventually become pre-production code or it may be completely discarded. In the prototyping effort, we are not concerned with the maintainability of the code nor are we concerned with formally documenting it. Code resulting from prototyping is often used to train the programmers. Only after we have written specifications resulting from the experience with the prototype should we start the formal development process. If we are fortunate enough that some of the code that was developed for the prototypes can be carried forward, that's great, if not, there is no loss.

A prototype produces "running" software and the production development produces "working" software.

Recent project experience has led to the widespread acceptance of the concept that early prototyping is fundamental to the success of operations supporting software products.

The reasons why prototyping is fundamental include:
  1. The prototype provides a vehicle for systems engineers to better understand the environment and the requirements problem being addressed.
  2. A prototype is a demonstration of what's actually feasible with existing technology, and where the technical weak spots still exist.
  3. A prototype is an efficient mechanism for the transfer of design intent from system engineer to the developer.
  4. A prototype lets the developer meet earlier schedules for the production version.
  5. A prototype allows for early customer interaction.
  6. A prototype demonstrates to the customers what is functionally feasible and stretches their imagination, leading to more creative inputs and a more forward-looking system.
  7. The prototype provides an analysis test bed and a vehicle to validate and evolve system requirements.

    About the Author

    Mr. Bernstein is president of the Center of National Software Studies and is a recognized expert in Software Technology. He provides consulting through his firm Have Laptop - Will Travel and is the Executive Technologist with Network Programs, Inc. building software systems for managing telephone services.

    Mr. Bernstein was an Executive Director of AT&T Bell Laboratories where he worked for 35 years.

    [email protected]

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Presentations

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019