The Potemkin village and the art of deception

Potemkin village is "something that appears elaborate and impressive but in actual fact lacks substance". The software analogies for the Potemkin village are ripe for exploration. Software antipatterns address problem-solution pairs in which the typical solution is more harmful than the problem it solves. In essence, an antipattern presents an identifiable problem, the accompanying harmful effects of the typical solution, and a more appropriate solution called a refactoring. In this sense, the software version of a Potemkin village is an antipattern: Problem: deliver software with an impressive interface quickly. Solution: employ a ready-made architecture that provides an impressive interface quickly; spend as little time as possible on the back-end processing. Refactoring: do it right the first time. The author doesn\´t want to make the case too strongly that the building of Potemkin villages is a deliberate strategy of fraud that companies perpetrate. Is a weak piece of software covered by an elaborate GUI a deliberate fraud or simply poor design? You must assume the latter in the absence of proof. When faced with a Potemkin village or an emperor\´s new clothes situation, you must expose it immediately. Doing so is not easy when a high-quality GUI masks the shortcomings. You can, however, detect the situation through design reviews, and code inspections, reviews, or walkthroughs. Therefore, managers who oversee software projects (and customers who buy software) should require these reviews. Testing can sometimes uncover the situation, but it might be too late at this point. Test-driven design, on the other hand, can help avoid a Potemkin village.