Concept Meets Code: 10 Tips for Dealing With Developers

I’ve seen it too many times: starry-eyed would-be Internet entrepreneur meets real developer, dream in hand. This is culture clash. More often than not, it ends up with wasted time, wasted money and dashed dreams. Concept meets computer code.

In 30+ years in the software business I’ve been a developer, a dreamer, a consultant to the dreamers and an employer to the developers. So maybe I can help. With thanks to several contributors (below), here are 10 tips for the dreamer side of the equation:

1. Software is usually a compromise between the dream scenario, on the one hand, and what’s actually do-able in software. Think of whatever your favorite productivity software, or app and how, as you learn to work with it, you learn to accept its way of doing things instead of your way. Everybody hates their accounting software, right? But you make do because it’s easier than balancing your checkbook with a pencil and a calculator. Real development takes compromising what’s ideal for what’s actually possible.
2. You have to listen. Developers think and talk in code (double meaning intended.) Most of the time, as you explain to them what you want, they’re trying to translate between what you imagine and what software code will actually let them do. They are not necessarily articulate, tactful, or very good at explaining. You have to shut up and listen. Catch the clues. Don’t think they’re not understanding you. They probably are, and they’re jumping ahead of you to what they can implement in code.
3. Understand critical relationship factors. Figure out whether your developer is a partner or just a vendor. It’s really hard to succeed in software, especially at the early stages, without brainstorming, collaboration and excitement about ideas. If you want a developer to just shut up and write code you’re probably doomed from the start. Please re-read points 1 and 2 above.
4. Who owns the product? You can’t get around this sticking point. The road to startup success is littered with the carcasses of failure caused by disputes over ownership of ideas, ownership of code and points in between. You have to talk about it. Painful, maybe; awkward, maybe, but establish with your developer that you own the work, or that it’s shared. My suggestion: own the work, but listen, collaborate, own it legally and technically (because you’re the one writing checks) but not emotionally or creatively.
5. Pay for results, not hours. I learned that the hard way, and from both sides of the table. Don’t pay too much in advance. Set milestones together. Pay for achievements. Programmer hours are more volatile than Midwestern summer weather. They’re like airplane seats, where one passenger pays 20 times what it cost the passenger across the aisle.
6. Identify which developer personality is which. Developers are often multiple people, like schizophrenics. They want security, steady income, power, big entrepreneurial jackpots, ownership, and days off without worrying about anything. They’re geniuses in good moments and pains in the royal ass in bad moments. Which makes them a lot like the rest of us. Try to figure out which personality is which, so you can let the genius soar at the right times, and avoid the pains. Careful with egos. It’s really stupid to shut down creativity with discipline.
7. Know your developer. Check references before hiring. Call some past relationships. We all work with the assumption that programmers are super smart and eclectic, but some pseudo-programmers are smart as scammers. Ideas get stolen and it’s not illegal. Watch the movie Social Network and realize that the law supports the Mark Zuckerberg character in that script. The twins might have thought of it, but he did it. And keep in mind that most developers are good at some things, but not all things. Some focus on interface, some on system back end and so on.
8. Design an early check-in point into the project. Never contract a whole project from the start. Instead, find a quick first step that can also be an abandonment point. It’s like in a personal relationship, meeting new people, you want to get a cup of coffee first, before jumping into bed together.
9. Get the key points in writing. No, I don’t mean some big fat contract, or expensive legal work; but have your developer sign a short letter — in English, not legalese — that establishes who owns what, when the money changes hands and what you’re agreeing to.
10. Remember the dragons. One of my favorite programmers compared software development to Columbus setting out from the Canary Islands sailing west:
    

    He hoped he’d end up on the coast of India, but I bet he still feared falling off the end of the Earth into the mouths of the dragons. Software development is like that. You think you’re going to reach land, but you might not.

    And good luck. Enjoy the journey. And may you reach the other shore.

(Note: I posted this on Huffington Post this morning; I’m reposting it here becuse  this is my main blog.)

(image: istockphoto.com)