A few times in the days before open source was such a popular idea, I had the opportunity to use what developers created before it, hobbyist software. These were programs distributed on floppy disks with hand-printed labels, ostensibly to be used to accomplish some task the author knew something about how to accomplish. They all looked mostly alike. The idea of a “wizard” with multiple steps and paths hadn’t completely caught on, so the interface, such as it was, tended to be a big screen with a number of fields. If you failed to fill out the fields using the correct format, or in the correct combination, you would click a difficult-to-locate button and nothing would happen.

As engineers, we’ve generally accepted that this is not an interface and we are not doing our jobs if we present such a thing to our end users. But, as engineers, we continue to create and expect the use of such tools in our own work.

As engineers, I think we’re susceptible to the worry that if we aren’t controlling all aspects of the process by which we do our work, we’re merely secretaries. I think this is why we insist on so many needlessly complicated tools and processes. Task management systems that look like spreadsheets, choked with fields we must fill out that rarely provide any value a more intelligent interface couldn’t infer. Installation processes for project we may or may not want to actually use that require days of configuration, troubleshooting, and lurking in IRC waiting for answers to our questions.

We aren’t supposed to complain about these things, because these things make our work seem difficult. And indeed, these things make our work difficult. In any other context besides poorly-concealed job security, we would call engineering that makes a task more difficult what it is: shitty engineering.

As we, as an industry, attempt to widen our reach and make our work appeal to the people we’d previously shut out, we have to reexamine this ideal. I’ve personally decided against getting involved with open source projects because of onerous bug tracking systems or overly complicated installation processes. And folks, I have a degree in this shit, I have training in how to do exactly these onerous things, I have the benefit of having been around long enough to see how these onerous things evolved. I can use them, but only if someone has made the decision to pay me to do all that data entry/lurking in IRC. I’m certainly not going to spend my free time screwing around with them, and the notion that someone new to the field should is so arrogant it borders on hostility.

We need more engineers and more productive engineers. We don’t need to send people on quests through the dark woods of our issue tracker to have them prove their worth. We need to get them running the project locally, finding tasks to do, and fixing issues as quickly as we can. We know lots and lots at this point about how to do good engineering: intelligent, predictive, and, ultimately, easy for the end user. At some point we’re going to have to drop the fantasy that putting up with bad engineering is evidence of a good engineer.

This thought was written by Garann Means and first published on Monday, 16 June 2014.