This weekend, WordPress Lead Developer Andrew Nacin shared a link to a short, but interesting article from the CEO of Slack.

Though the article, in its entirety, is worth a read, one of the biggest points made in the article (and in the associated tweet) is:

I feel that what we have right now is just a giant piece of shit. Like, it’s just terrible and we should be humiliated that we offer this to the public. Not everyone finds that motivational, though.

For anyone who has worked in software for long enough to release something to be public (be it 100 users or 100,000 users), this statement is kinda validating isn’t it?

That is, for the majority of the programmers that I know (including myself) both online and offline, I rarely hear any of them talk about how proud they are of the entire architecture of their application. Sure, some talk about parts they are proud of, but more often than not, it’s more about the general problems they have with the current state of the entire system.

The interesting bit is that for those who care about what we’re doing, we try to read books, blogs, articles and discuss topics that go into building quality software. And software, in this sense, isn’t limited to a desktop application – this can be a mobile app, a web application, a web site, a WordPress theme, or even a small JavaScript application that runs in the context of a larger site.

Regardless, it’s easier to talk about how things should be rather than writing things how they should be. Good thing we have that whole refactoring bit, right?

But that’s beside the point of what I’m actually getting at. Instead, the point I’m trying to make is that I think open source software often times is far more harshly criticized than its closed source counterpart.

And why shouldn’t it be?

The Inherent Nature of Open Source Criticism

I mean, the code is out in the, ahem, open for display. Of course it’s going to be open to more scrutiny than closed source software. It affords it. But sometimes I think that closed source gets a pass on having a level quality that it may not actually have simply because we have no way to judge the organization of the code base.

If someone working on the software tells us that it’s well-organized, then that’s what we have to go on. Of course, some programs that are poorly written can show their internals based on the their performance, but I’d like to think that that’s the exception – not the rule.

Here’s the thing: For everyone who has ever worked on code of any type, the odds that you’ve looked back at said in in three, six, twelve, or more months and wondered:

Why did I even write it this way?

Or said:

I can’t believe I did it like this!

Knows that common feeling. So why should we be surprised when we see work done by other people that are likely in the same place we’ve been?

To that end, is it any wonder that we look at other people’s code and pass the same sort of judgment? That is, if we’re harsh on our own code, how much harsher are we going to be on others’ code?

A Lot of Assumptions

And since software architecture isn’t a completely objective thing, if there is an alternative way of doing something or a better way or organize part of the system especially as it relates to something we’ve read about in a book or an article, aren’t we likely to say “That’s not bad, but if I were to do it, then I’d do it using [x, y, or z].”

But would you really? How would you know that?

That’s assuming that you have all of the same information at hand the original programmer had, that you were operating under the same constraints, that you had the same perspective on the overall project, and that you’d arrive at a different conclusion.

Maybe you would. Maybe not. But it’s presumptuous to assume the former.

It’s About Continuous Improvement

This is why having good, open, and honest conversations about the code that we write matters any why harsh critics who’ve little to add but exactly that don’t contribute anything productive to a discussion.

The next time that you end up looking at someone else’s codebase and feel the need to trash it, first try to take into account the position that they were in when working on it, ask yourself some similar questions, and try to understand the why behind the method.

After that, then open an issue or comment talking about the rationale behind why something is organized the way that it is and provide some potential options for ways to improve it.

But let’s try to ease up on the continuous criticism just for the sake of criticism that we offer on other people’s work when ours is subjected to the same regardless of its open or closed nature.

Look at it this way: Right now, a lot of people – and I mean a lot – people love Slack. Based on its popularity and how it works, no one would guess there’s any kind of crap compiled into the binary. We’d assume the opposite, most likely.

But when the CEO outs the code base (and that’s awesome) and we all still continue to use Slack and trust it with much of our work.

So if the CEO of a company like Slack is willing to share his take on their code base, and open source programmers are willing to showcase their work for the world to see all the while they’re profiting from the work despite its lack of quality in some areas, wouldn’t it be more helpful for us to work on talking about potential improvements (and even providing them) rather than talking about their inherent problems (and doing nothing about it)?