Software Development; Software Methodologies; Computer Science


The worse-is-better approach to software development was created in response to the Massachusetts Institute of Technology (MIT) approach. It is based on the idea that the quality of a software solution does not improve with added functionality (better), but that a simpler solution (worse) might be more practical and usable. Worse-is-better designs take less time and effort to create and implement. They are also more adaptable to changing requirements.



According to Gabriel, four characteristics define the worse-is-better approach: simplicity, correctness, consistency, and completeness. Simplicity is the primary factor. A worse-is-better design must have simple implementations and interfaces. However, this is imperative for the implementation. In contrast, in the MIT approach, simplicity is more important for the interface.

Correctness is the extent to which a solution meets the user's requirements and system specifications and lacks defects. A worse-is-better design should be “correct in all obser vable aspects.” Simplicity remains more desirable than correctness, however. When following the MIT approach, a design must be “correct in all observable aspects” and incorrectness is unacceptable.

Consistency is the extent to which a solution contains no internal conflicts. A worse-is-better design must be reasonably consistent, but consistency may be sacrificed if needed. The preferred approach is to simplify the design by removing parts that introduce complexity or inconsistency. In contrast, in the MIT approach, a design must be consistent, and consistency and correctness are equally essential.

Completeness is the extent to which all requirements have been implemented and verified. A worse-is-better design must meet as many requirements as practical, including “all reasonably expected use cases.” However, completeness can be sacrificed in favor of correctness and consistency, and must be sacrificed to preserve simplicity. The difference when following the MIT approach is that simplicity cannot “overly reduce completeness.”


The worse-is-better approach does not necessarily result in a design that is more or less complete, correct, and consistent than software designed using other methodologies. The design does, however, take less time and effort to create and implement and is more adaptable. Because solutions developed using a worse-is-better approach are implemented with faster, they offer the “first-mover advantage.” This is the idea that the first occupant of a certain market segment can gain greater market share or profits. After allowing a solution to gain acceptance and market share in an incomplete but useful state, revisions can be deployed until the solution reaches a high level of completeness. Gathering user input is critical to prioritizing the development of new features to meet their needs.

This can be preferable to the approach taken when following the MIT approach. When a solution is not deployed until it is complete, there is a chance that the need that the solution was designed to fill will already have been met by a competing solution. This would result in lost time, effort, and potential profit for the organization.

The worse-is-better approach may not be preferable to the MIT approach in all cases. For example, if the project requirements can be clearly and completely defined at the outset and are unlikely to change during the software life cycle, then a linear MIT approach may produce a better design.


An Internet start-up is developing the design for a new social media application (app). The concept offers a unique, innovative approach to connecting businesses with their potential customers through social media. Worse-is-better would be a good approach to follow while designing this solution for the several reasons.

Perhaps the main factor in this case is the need to release the app into the market in the least amount of time. Social media and marketing apps are a highly competitive marketplace, with many companies releasing new apps on frequent basis. If a competitor releases an app with similar functionality, it may be impossible for the design to penetrate the market even if the design is superior to the competing app in completeness and correctness. As the company is a start-up with no other lines of business or source of revenue, this could result in the company's failure. The worse-is-better approach is also suitable in this case because app users expect to wait for improved functionality to be delivered in product updates. Thus, the incompleteness of the solution would not hinder its adoption.


—Maura Valentino, MSLIS

Bell, Michael. Incremental Software Architecture: A Method for Saving Failing IT Implementations. John Wiley & Sons, 2016.

Gabriel, Richard P. “Lisp: Good News, Bad News, How to Win Big.” AI Expert, vol. 6, no. 6, 1991, pp. 30–39.

Goldman, Ron, and Richard P. Gabriel. Innovation Happens Elsewhere: Open Source as Business Strategy. Morgan Kaufmann Publishers, 2005.

Jayaswal, Bijay K., and Peter C. Patton. Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software. Pearson Education, 2006.

MacLennan, Bruce J. Principles of Programming Languages: Design, Evaluation, and Implementation. 3rd ed., Oxford UP, 1999.

Wysocki, Robert K. Effective Project Management: Traditional, Agile, Extreme. 7th ed., John Wiley & Sons, 2014.