Although wikipedia offers its own wonderfully-accurate definition, over-engineering really boils down to making a product more complex than required. To help understand how over-engineering has infected software development, let's take a brief look at what's been the most-heralded development form since the mid-'80s, object-oriented programming, or OOP.
As the profession of software engineering evolves and matures, new programming paradigms emerge, often in response to real or perceived deficiencies in existing models. Thus, functional programming eventually gave way to OOP.
OOP is a truly marvelous system that maps naturally to a majority of real-world situations. Its uses span business software, games, simulations, and some scientific applications. When employed appropriately, OOP can reduce the potential for defects; simplify maintenance, expansion, and other modifications; and generally make code more intuitive. There are many projects we'd absolutely dread tackling without the benefit of OOP.
Sadly, the degree to which OOP revolutionized software engineering — alongside a legion of academics with little or no real-world development experience — caused a quasi-religious atmosphere to envelop OOP to the point of absolute, blind obedience. In fact, we've seen so much of this tunnel-visioned misapplication that we long-ago came to believe it our professional obligation to evangelize the forgotten (or perhaps more accurately, purposely discredited and buried) "legacy" paradigms that sometimes lead to more economical and effective design and construction of software.
In far too many situations, these otherwise-worthy OOP teachings are misappropriated and grossly overextended, resulting in some combination of bloated, convoluted, unnecessarily abstract, maddening-to-debug, sluggish, and/or generally confusing code. Ironically, OOP-abuse can produce some of the exact problems OOP was designed to address — including reusability, modularity, maintainability, and readability. Thus, over-engineering with OOP actually inflates costs and stretches timelines without producing appreciable benefits to the client.
Of course, this phenomenon isn't limited to OOP, or even just to programming paradigms. This one-size-fits-all fantasy has crept into most facets of softare creation. Take data-dsesign, for example: To the most radicalized, denormalized tables and simple CSVs no longer have a place even on low-resource, highly-isolated platforms.
Of course, that's not how we think at Blade Technologies. Although well-versed in OOP and modern "best practices," we are careful to avoid over-architecting and over-implementing: Old-school, high-performance, cost-effective, modular, functional programming is still sometimes the best practice.
Sometimes, older technologies are displaced not due to inadequacy, but simply because they're no longer shiny. However, after three decades in this business, we've learned that — just as in fashion — whatever is old eventually becomes new again. Thus, the same desktop app development that was eulogized in the mid-aughts is now more prolific than anytime in the last decade; lightweight data-interchange formats like JSON and CSV have retaken territory from XML; and yes, functional programming seems to be making a long-overdue comeback.
Don't misunderstand: We're not saying we don't employ deeply-layered, highly-abstract object models when substantial system extensions are anticipated. We do. We also perform exhaustive unit, integration, end-to-end, and regression testing against code running in fault-tolerant environments. We'd also insist on triple-modular redundancy where human life was at stake, and would probably recommend the use of ADA (in which we are experienced). We believe in these things, but we do what makes sense, when it makes sense.
We simply select the path best-suited for the task at hand, even when that means leveraging different paradigms within distinct components of the same project. We do what's best for you, not what makes us feel most holy and enlightened.
E X H I B I T A
A simple example of our "never over-engineer" philosophy can be found in this very website, which was originally created in 2004 from a template we wrote in 1996. CSS support in browsers was both incomplete and unstandardized, so our template instead used the best-practice of the time, which was to nest HTML tables for the purpose of achieving at least semi-precise content-layout. (This technique is today very much maligned, but we're hardly alone in its use: Amazon, Wal-Mart, and Craig's List are still formatted via nested tables, so it's not as if that method isn't up-to-task.)
On the other hand, were we building a frequently-updated real estate clearinghouse intended to seduce visitors into making the largest purchase of their lives, rest-assured we'd leverage a content-management system and fill the screen with sexy 360-degree virtual tours and video pitches from smiling, energetic realtors. But we're not: We're promoting speedy, cost-effective, efficiently-engineered coding solutions, and a lightning-fast, information-rich, low-distraction website fits that objective.
Once again, one size does not fit all. Imagine what we'd create if we were selling, oh, say . . .