The construction parable

I talk a lot about testing on this site. Part of that’s because I don’t know what I’m doing all the time, and part of it’s because I’m an egotistical developer and getting things right is important to me. The problem here is that tests aren’t what I want. They’re an attempt at a solution to a bigger problem. So this post is about that much bigger problem.

Metrics suck

Let me start by pointing out that there are 0 good metrics in this industry. If you built some tool that does metrics, you might not like hearing it, but it’s completely true. Part of it is our fault, and part of it is a general lack of education. Here’s how this works in another industry where we build things.

The construction parable

Say you hire a construction contractor to build your home. You’re a savvy buyer and you shop around, so you get a really good deal. Along the way you notice that buying the most expensive contractor costs 3 times as much as you’re paying and you wonder how he gets any business at all. The contractor comes in and works on your house for a while. As is expected with the lowest bidder, there are some delays, but you don’t stress about it. Even with the extra hours you’re still getting a good deal. You drop by the site of your new home to check on progress and you realize that he underestimated. There’s not even a frame up yet. You theorize that this is going to take much longer than even his current estimate. It’s going to end up costing more than the next lowest bidder now. Time to shop around again.

So you take another look at the highest bidder. What’s he doing different? Does he never have a project run over budget? He is a dick. He tells you that you have to pay him just to come out and take a look at the project. He won’t even give you a vague estimate. You pay for him to come out. The way you see it, you’ll need to know what your current guy is falling behind on anyway, so maybe you can use this information to negotiate more effectively. His jaw drops when he takes a look at the property. “I’ve never seen that before” he says smiling as he looks at you unfinished building. He finishes looking around and comes over to you and says “We’re going to have to start over. It’ll cost you extra because I have to tear all this down.”

What?! This guy has spent 5 minutes here and he’s telling you that all the money you spent was wasted and that he is going to raise his already absurdly high price. “Why?” you ask, perturbed by his non-chalant nature. He pulls a tool out of his belt. You know this tool. It’s a level. Everybody knows how to use a level. This guy’s not that smart. You know that you just look at the bubble and get it between the lines. He walks over to the half-finished building and places the level down on the concrete. “Your foundation’s not level.” He says, motioning to the tool. You bend over and squint. He’s right. He’s going to have to pull out big equipment to tear up this concrete and replace it. You begrudgingly grab your checkbook and work your way onto his already overbooked schedule.

That’s not how it works in software development

In our industry, it’s very very different. Here’s how that goes. If you’re the guy who knows good software when you work with it, it’s not easily identifiable after a five minute walkthrough. It takes months sometimes. Then, when you can identify it, it’s hard to describe simply to your employer. You can’t show them on a tool they understand, like a level. There is no simple way to show people that you need to rebuild things from scratch. Given that, your employer’s not likely to grab his or her checkbook.

It’s worse than that though. Because there’s no simple explanation, there’s not an easy way for an employer to identify the best hire from the worst. This means you’re not able to charge 3x more even if you’re a 10x developer. It doesn’t stop at pay though. You can’t even convince the guy that you need to tear it down and start over. After all, that’ll take longer and cost more money. So instead you’re doomed to a job where try to prop up a broken frame with toothpicks while users constantly demand better/faster/newer features.

Sadly, it doesn’t stop there either. Because there’s no simple way to show your employer good code from bad, there’s also no simple way to show your employer good programmers from bad ones. You can find yourself in a room arguing with someone who never writes good code, on a topic where he/she is completely wrong and still have your employer side with him/her. This further perpetuates the problem above, because now he may be the higher paid contract to purchase and people will take his word over yours, even if you’re right!

The downside here is that, with something like construction, if you work for one place and do a crappy enough job, they take away your certification and no one will hire you. In development, if you do a crappy job (for very high pay at the moment because of the ridiculous demand) you can still go to the next place and try again.

But this is our fault

I said it might be our fault. It is. We don’t explain things to people. Programmers are notoriously short on patience. I can remember my first time being told what a shell was, trying to log on to an existing one that someone linked me to and asking “what is this, I’m lost” only to be kick-banned with little more than an “lol”. But patience isn’t our only weakness.

We’re also liars. With the patience we lack, comes our human desire for childish pranks. There are probably some of you out there that have convinced your boss that you spent the last month working on “the flux capacitor” just to see if he’d buy it. Heck, it’s so prevalant that those sort of pranks are now put on TV.

And people are imperfect. Some programmers have taken that pranking a step further and chosen to go the less “harmless” route. They use lies like that to justify spending too much time on a project. A 16 year old kid can lie to a 45 year old man’s face because the programming knowledge is so specific and compartmentalized. It’s impossible for us to determine any of this without a decent tool.

It’s a lack of education

The truth is, it could all be solved if everyone everywhere was given a basic understanding of programming. They need to be able to use the basic tools, much like we can all use a level. It’s not something that will happen quickly or come easily, but it is a simple way to fix this problem. It’s also largely due to a culture problem. Learning about computers, even as prevalent as they are, is still seen as nerdy and uncool. If we want people to understand things, then they have to be included, and they have to be a part of the club–which also means the club needs to be less lame.

How can we fix it?

To be honest, I don’t know the answer as to how to fix this. I know that what we need is easier to use tools that people are educated in how to use. I don’t know what that is, but I’m going to keep looking.

• The maker movement is going a long way toward expanding education about electronics and software, but it also results in more low quality products and low quality developers.
• The FCC is trying to fix it by regulating the things you can do with your own electronics
• There are now companies offering to certify your code, but how do we know what the quality of their certification ability is? Half the time, their real goal is to sell us their team of developers instead of our own anyway.

So lots of people are trying new things. My company is going to attempt to offer option 3. I’m a maker myself, doing option 1, which sort of precludes me from wanting option 2… So everyone’s trying to fix it. Now we just need to actually solve the problem. Ideas? Comment below.