Gulliver, as the system, washes ashore to be tamed by the custodians.
Warning, this is a an article by a software geek for said geeks. Rapid boredom will probably ensue even for the target audience. Most of us at one time or another have worked on a Big Ball of Mud. For a less seasoned hacker the first tour or two of such a haphazard system may go unnoticed due to a number of circumstances the least of which being naivety. But, over time, the imprints of sloppy, duct tape, spaghetti code jungles come to be recognizable. By no means complete a few standout examples from my career:
- Code is not stored in an SCM.
- Bug fires rage 24/7 consuming all resources perpetually.
- Poor code abounds with total disregard for any standards (e.g., wheel is reinvented regularly, 10 screen shot methods, classes with 100′s of members, etc.).
- Duplicate data and functionality throughout including “clone” systems.
- Management, via ignorance, insists things are basal or worse are in complete denial.
Once one can identify a subset of ailments it’s tempting to run from these helter-skelter systems in haste. Knowledge arms us not to repeat them – maybe. Yet Foote and Yoder make clear in BBOM many profitable such systems exist. Profitability aside the fact is they abound! Having designed, developed, and maintained such systems myself the temptation is to disparage. What is it about these hastily crafted boomtown’s that irk us? Is it the simple fact that the architects and custodians are all to comfortable with a level of expediency we are uncomfortable with?
I am poorly equipped to answer from my limited exposure. Both BBOMs I worked on were absolutely driven by a perceived fleeting window of business opportunity. Design marathons, repositories, code standards, pair coding, QC, test harnesses, continuous integration, etc. where all pushed aside in the rush to launch. Once there and stably afloat i.e., profitable, did the realization often slowly set in that the system was ineptly fashioned. Once built management forever demands hastily cobbled features to increase ROI almost always at the cost of sane design – the “structure” worsens. Of course, as engineers we fight to avert such quagmires whether through evangelization and/or example. However, we all have to eat – to deny human nature is foolhardy.
An inverse universe exists where architecture, means and process are king. Laugh if you will but it’s well known that Microsoft runs one of the most process driven engineering shops the world over. For them sheer scale dictates a process rooted approach. However, for the average web business outlet day to day operation is about finding the middle ground between launch mentality and design nirvana.
So, whose world order should prevail in software engineering? The one that works.