Overengineering
Overengineering, or over-engineering,[1] is the act of designing a product or providing a solution to a problem that is complicated in a way that provides no value or could have been designed to be simpler.[2] As a design philosophy, it is a violation of the minimalist ethos of "less is more" or "worse is better", as well as the related KISS principle.
It is generally criticized in terms of value engineering as wasteful of resources such as materials, time and money. NASA listed excessive features as one of the top 10 risks of failure for development projects,[3] and Mercedes-Benz developed and removed 600 non-essential features from their cars due to malfunctions, lack of usability and customer complaints.[4]
Characteristics
[edit]Overengineering is often identified with design choices that increase safety, add functionality, or overcome a perceived design flaw that most users would not notice or would accept. It can be hard to avoid when safety or performance is critical (e.g. in aerospace vehicles and luxury road vehicles), or when extremely broad functionality is required (e.g. diagnostic and medical tools, power users of products). Overengineering often occurs in high-end products and specialized markets. A product may be overbuilt – with performance far in excess of expected normal operation such as a city car with top speed of 300 km/h, or a home video recorder with a lifespan of 100 years. Such products may be more expensive, bulkier, and heavier than necessary. A product may be overcomplicated – with functions that are not necessary, and reduce the usability of the product by overwhelming users which is sometimes called feature fatigue.[5][6]
Sometimes overengineering occurs over time in the form of feature creep. Overengineering can decrease the productivity of a development team because even though the team produces product, the value realized might be less than if the team was producing only what the user needs and wants. Overengineering can consist of premature optimization, potentially to the detriment of the project due to diminishing returns on time and effort invested in the design process.
Cultural references
[edit]A story about very precise engineering is given in the 1858 story The Deacon's Masterpiece or, the Wonderful "One-hoss Shay": A Logical Story by Oliver Wendell Holmes Sr., which tells of a carriage (one-horse shay)
That was built in such a logical way
It ran a hundred years to a day,
And then,
...
went to pieces all at once, --
All at once, and nothing first, --
Just as bubbles do when they burst.
Because it had been engineered so that no single piece failed first – no piece was over-engineered relative to the others, and they thus all collapsed at the same time. A similar quote by Ferdinand Porsche claimed "the perfect race car crosses the finish line in first place and immediately falls into pieces."[7]
Examples
[edit]German Second World War weapons, like the famous Tiger I tank or Panther tank, have been listed as examples of over-engineering,[8] in comparison to their Soviet rivals such as the T-34. German arms allegedly used expensive materials and excessively labour intensive production processes, limiting production and making them hard to repair when they broke down in the field. Another example is Juicero, a wi-fi "smart" juicing press with an initial market price of $699.[9] After its release, Bloomberg News published a story that showed that the juice packs could be squeezed by hand faster than the press, and that hand-squeezing produced juice that was near-indistinguishable in quality and quantity from the output of the machine, which cost $400 even after a price reduction.[10]
In 2024, former technical director and chair of Network Rail High Speed Andrew McNaughton stated to the Transport Committee that HS2 was overengineered in respect of bridge foundations and masts.[11]
See also
[edit]- Technical debt
- Feature creep
- You aren't gonna need it
- Planned obsolescence
- skyTran
- Useless machine
- Writing in space
- Design by committee
References
[edit]- ^ Gowing, Margaret. Britain and atomic energy 1939-1945. https://openlibrary.org/books/OL14918996M/Britain_and_atomic_energy_1939-1945.
- ^ WorkNik. Definition of Overengineer. https://www.wordnik.com/words/overengineer.
- ^ Landis, Linda; Waligora, Sharon; Mcgarry, Frank; Pajerski, Rose; Stark, Mike; Johnson, Kevin Orlin; Cover, Donna (1992-06-01). "Recommended approach to software development, revision 3".
{{cite journal}}
: Cite journal requires|journal=
(help) - ^ Rust, Roland T.; Thompson, Debora Viana; Hamilton, Rebecca (2006-02-01). "Defeating Feature Fatigue". Harvard Business Review. ISSN 0017-8012. Retrieved 2023-01-22.
- ^ Marzi, Giacomo (2022-04-01). "On the nature, origins and outcomes of Over Featuring in the new product development process". Journal of Engineering and Technology Management. 64: 101685. doi:10.1016/j.jengtecman.2022.101685. hdl:11368/3019176. ISSN 0923-4748.
- ^ Thompson, Debora Viana; Hamilton, Rebecca W.; Rust, Roland T. (November 2005). "Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing". Journal of Marketing Research. 42 (4): 431–442. doi:10.1509/jmkr.2005.42.4.431. ISSN 0022-2437. S2CID 18386203.
- ^ "The best quotes and sayings from Ferdinand Porsche | Ferdinand Porsche Erlebniswelten fahr(T)raum Mattsee". 2018-03-21. Retrieved 2024-05-02.
- ^ Tucker-Jones 2012, p. 7.
- ^ Shontell, Alyson; Carson, Biz (2017-04-20). "What it's like to use the $400 juicer that people are freaking out about". Business Insider. Retrieved 2017-04-21.
- ^ "Silicon Valley's $400 Juicer May Be Feeling the Squeeze". Bloomberg.com. 2017-04-19. Retrieved 2017-04-21.
- ^ Johnson, Thomas (9 November 2023). "HS2 designer blames frequent cost rises on 'overengineering' of project". New Civil Engineer.
External links
[edit]- "Code Simplicity ", Code Simplicity: The Science of Software Development Book, O'Reilly Media, Max Kanat-Alexander, March 2012
- "Stop Over-Engineering!", Software Development magazine, Joshua Kerievsky, April 2002
- "Overengineering: How much is too much?", EDN magazine, Paul Rako, January 2008