Skip to main content

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.

Comments

Popular posts from this blog

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …

When Is Software Done?

I have some very exciting news.  A piece of software I've been working on for over 2 years is released to the general public!  This is a little exciting if it were software I'd been working on for some big company.  It's very exciting because it's software I have been working on for my company.  That's right!  My company is ready to start selling software and start making money!

I'm not gonna use this blog post to talk about my company and what it does.  You can read about that in our press release.  Instead, I'm going to talk about the software industry and the concept of done.  Because, as with everything, it's more complicated than it seems.

Software is never really done
Actually that's a misnomer.  Software can really be done.  But done is sort of a quantum state--there and not there at the same time.  First and foremost, anyone can understand that software that works is complete.  If the software's purpose is to process a credit card, if th…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…