Image for post
Image for post

Patching Bad Design With More Bad Design Has Become the Software Standard

It never crosses anyone’s mind to return to what worked before.

Chris Fox
Chris Fox
Dec 5, 2020 · 4 min read

Introduction

But for every new problem there is a solution, and it makes things worse. Let me give a few examples.

Software Testing

But things went bad; developers came to resent being confronted with their mistakes, so the two groups merged. And the perennial disdain of developers for documents got in the way; few developers can write worth a damn, even fewer can write clearly and thoroughly, and in the end hardly anyone read the documents.

So along came test-driven development, a completely absurd idea even as conceived and of little use in practice, given that there is a crazy idea that developers should have primary responsibility, if not sole responsibility, for testing their own work. So they have the same blind spots in writing tests that they had in writing code.

But since writing some tests yields better results than writing no tests, people think the problem is solved. It isn’t. Unit testing is a lot of work and often overlooks all but the most ordinary cases. And since the tests are supposed to be written before coding (why?) they become obsolete within days, if not hours, of commencing to code.

And TDD is aflame with fanaticism, people who think that unit tests are more important than products, that documents are obsolete as horse-drawn carriages, and that only TDD is “true” programming.

But it never crosses anyone’s mind to return to what worked before.

Concentration and Productivity

Success at writing good software is directly linked to being able to maintain unbroken concentration, a condition we called Flow.

We wrote better code and a lot more of it, and with fewer bugs. But Flow is a fragile condition, easily broken and usually gone for the day. A meeting destroys it.

But managers coming from the business world resented developers’ expectation of having their own offices and not being mired in meetings, so recognition of the value of Flow disappeared. Productivity plummeted; code quality suffered; schedules slipped.

So then came more layers of procedure; methodologies that inevitably meant more and more meetings, which, being interruptions, just made things worse. Younger developers have likely never experienced this condition and having grown up with channel surfing, games, and nothing to encourage extended concentration may very well be incapable of ever attaining it

So instead of getting in the zone and writing solid code they have morning standups, sprints and their ceremonial meetings, layer on layer of procedure and distractions. It all sounds so very coool with new nomenclature (burndowns, retrospectives) but it adds nothing to productivity and for people who remember actually enjoying writing code the thrill is gone.

But it never crosses anyone’s mind to return to what worked before.

Package Versions

This should not happen. Not ever.

  1. New releases should not break old code, they should be backward-compatible with older. If this is not possible then the new and incompatible package should have another name. People who write breaking code should be in another line of work.
  2. Everyone working on a project, and every server environment, should be required to run the latest versions of all packages.

It’s hard to imagine anything simpler than this.

But no. Instead the new Dumb Idea is to include copies of every package in the container. This is not really objectionable; packages are not terabytes in size and time not spent tracking down new bugs is time saved. But a project using many containers should not have three or four versions of the same package.

In the Component Object Model (COM) objects were identified by unique identifiers, GUIDs, and any new version with a breaking change had a new GUID. This was easy, it worked perfectly, but COM has been supplanted by .NET and now we have too many “stacks” and too many people who want to scent-mark their work by writing something new, inattentive to such considerations as breaking changes.

This is a lot of extra work; Docker and Kubernetes are fledgling technologies that require vast amounts of extra preparation, mostly because of the absurdity of incompatible package versions.

But it never crosses anyone’s mind to return to what worked before.

The Startup

Medium's largest active publication, followed by +775K people. Follow to join our community.

Chris Fox

Written by

Chris Fox

American Software Developer living in Vietnam. Classical musician (guitar, woodwinds), weightlifter, multilingual, misanthrope • XY

The Startup

Medium's largest active publication, followed by +775K people. Follow to join our community.

Chris Fox

Written by

Chris Fox

American Software Developer living in Vietnam. Classical musician (guitar, woodwinds), weightlifter, multilingual, misanthrope • XY

The Startup

Medium's largest active publication, followed by +775K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store