Bad Architecture, architectural antipatterns
Last Saturday I visited JS Kharkiv conference. Among all presentations I'd like to distinguish the one on software architecture anti-patterns. I'll simply mention all which spokesperson (Dima Maleev) described:
1) God Object (class, usually enormous one, where developers put each and every method and constant, usually utilities, which are hard to decide where else to place them to)
2) Warm Bodies (it's rather company's structure anti-pattern. It's when company decides to give part of its processes to people who are not tightly involved into company's business processes and thus are way less interested in success of the company. In a software development industry you can think of outstaffing companies as of implementation of Warm Bodies anti-pattern)
3) Reinventing the wheel (I think it's clear)
4) Vendor-lock (using services and tools provided by only one vendor)
5) Cover your assets (technicians which are good in one tool tend to insist on using of that only tool, saying what other tools cannot do, comparing to tool technicians are good at, rather than saying what they can do)
6) Stovepipe system (system, whose functionality is not understandable by developers at most use-cases)
7) Design by Committee (spokesperson stated that there should be a few, not many, persons responsible for architectural decisions, not a collective mind should take such decisions)
And this is a picture to the first presentation by Eugene Obrezkov on google chrome v8 js-engine:
1) God Object (class, usually enormous one, where developers put each and every method and constant, usually utilities, which are hard to decide where else to place them to)
2) Warm Bodies (it's rather company's structure anti-pattern. It's when company decides to give part of its processes to people who are not tightly involved into company's business processes and thus are way less interested in success of the company. In a software development industry you can think of outstaffing companies as of implementation of Warm Bodies anti-pattern)
3) Reinventing the wheel (I think it's clear)
4) Vendor-lock (using services and tools provided by only one vendor)
5) Cover your assets (technicians which are good in one tool tend to insist on using of that only tool, saying what other tools cannot do, comparing to tool technicians are good at, rather than saying what they can do)
6) Stovepipe system (system, whose functionality is not understandable by developers at most use-cases)
7) Design by Committee (spokesperson stated that there should be a few, not many, persons responsible for architectural decisions, not a collective mind should take such decisions)
And this is a picture to the first presentation by Eugene Obrezkov on google chrome v8 js-engine: