The Definition of Garbage
The views and opinions expressed here are my own and don’t necessarily represent positions, strategies, or opinions of Backstop Solutions Group.
Recently we released episode 3 of the Software Apprenticeship Podcast but had to pull it back for re-editing because of some problems with how developers talk to each other. Developers are not kind to ANY code. Even our own. Especially our own. Sitting next to a dev while he or she discusses the code they are working on can be a shocking experience. Words like “Crap,” “Junk”, “Garbage” and many worse are used often. A lot of this type of talk was on episode 3 and when someone at Backstop (who’s job it is to protect us from ourselves and comments taken out of context) heard it they asked us to edit the podcast to take out some of the more offensive comments. This is why episode 3 sometimes fades into music and then comes back mid-conversation. Sorry about that.
I don’t know where I first heard the definition of developer as “Whiny Optimist” but it is uncannily accurate. We developers are forever complaining about previously written code. Code is awful. Code is crap. Code is the worst spaghetti wrapped around horse manure we’ve ever seen.
And yet…
We couldn’t go on if we thought we’d have to live out our lives fighting the very thing we create. There is this optimism about future code. It will be bright and shiny. The next project to re-write the is going to make everything better. So much better… The code will be pristine and new features slide in like rum into coke. Ponies and rainbows are coming.
Also…
Every year I get better at what I do, so even code I thought wonderful 3 years ago can be “crap” to me today. I look back and see a developer who didn’t keep orthogonal concepts separate who coupled code that should not be coupled and I am sad. I regret my past inefficiencies and curse them.
But…
How bad is this code really? Backstop’s code is rigorously tested many times automatically before being poured over by humans. Any code change in my product gets tested first on my machine (by automated tests) then on another “Build Server” (which runs the tests I was supposed to run and a bunch more), then another series of “Regression Servers” will run some even longer regression tests that literally use the app as our customers do. If it passes all that then we’ll have our Quality Assurance people go over it again to make sure the machines haven’t missed anything. The last thing the Q.A. people do is write a new automated regression test to make sure this functionality doesn’t break in the future.
What the heck are we complaining about then? The software works! It helps many people make a lot of money, it makes the company money, and is a leader in the industry. We developers are, in some ways, a bunch of ungrateful jerks.
Let me see if I can explain why. Writing software that solves hard problems is hard. Duh. There are only so many people who can do it and we struggle through. Writing software that solves hard problems and can continue to accept new features easily is the HOLY GRAIL of software development. Rarely has it been done even though every company claims their code is the “best in the industry.” If you were to get your hands on the unedited version of episode 3 you would hear a lot of developers complain how we wish we had written code in the past that could be easily changed today. We might even call such code “garbage” but what does “garbage” really mean? In our app it has come to mean code that works, is well tested, but resists change more than we would like. We are whining about having to do more work. If only our past selves had properly separated the concerns more, if only there was more time for refactoring. But some day we will reach that shining castle on the hill. And there will be ponies and rainbows for all.
Recently we released episode 3 of the Software Apprenticeship Podcast but had to pull it back for re-editing because of some problems with how developers talk to each other. Developers are not kind to ANY code. Even our own. Especially our own. Sitting next to a dev while he or she discusses the code they are working on can be a shocking experience. Words like “Crap,” “Junk”, “Garbage” and many worse are used often. A lot of this type of talk was on episode 3 and when someone at Backstop (who’s job it is to protect us from ourselves and comments taken out of context) heard it they asked us to edit the podcast to take out some of the more offensive comments. This is why episode 3 sometimes fades into music and then comes back mid-conversation. Sorry about that.
I don’t know where I first heard the definition of developer as “Whiny Optimist” but it is uncannily accurate. We developers are forever complaining about previously written code. Code is awful. Code is crap. Code is the worst spaghetti wrapped around horse manure we’ve ever seen.
And yet…
We couldn’t go on if we thought we’d have to live out our lives fighting the very thing we create. There is this optimism about future code. It will be bright and shiny. The next project to re-write the
Also…
Every year I get better at what I do, so even code I thought wonderful 3 years ago can be “crap” to me today. I look back and see a developer who didn’t keep orthogonal concepts separate who coupled code that should not be coupled and I am sad. I regret my past inefficiencies and curse them.
But…
How bad is this code really? Backstop’s code is rigorously tested many times automatically before being poured over by humans. Any code change in my product gets tested first on my machine (by automated tests) then on another “Build Server” (which runs the tests I was supposed to run and a bunch more), then another series of “Regression Servers” will run some even longer regression tests that literally use the app as our customers do. If it passes all that then we’ll have our Quality Assurance people go over it again to make sure the machines haven’t missed anything. The last thing the Q.A. people do is write a new automated regression test to make sure this functionality doesn’t break in the future.
What the heck are we complaining about then? The software works! It helps many people make a lot of money, it makes the company money, and is a leader in the industry. We developers are, in some ways, a bunch of ungrateful jerks.
Let me see if I can explain why. Writing software that solves hard problems is hard. Duh. There are only so many people who can do it and we struggle through. Writing software that solves hard problems and can continue to accept new features easily is the HOLY GRAIL of software development. Rarely has it been done even though every company claims their code is the “best in the industry.” If you were to get your hands on the unedited version of episode 3 you would hear a lot of developers complain how we wish we had written code in the past that could be easily changed today. We might even call such code “garbage” but what does “garbage” really mean? In our app it has come to mean code that works, is well tested, but resists change more than we would like. We are whining about having to do more work. If only our past selves had properly separated the concerns more, if only there was more time for refactoring. But some day we will reach that shining castle on the hill. And there will be ponies and rainbows for all.
Comments