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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
(My thanks to Anthony Richardson (@webfugitive on Twitter), Brian Cole of Innovative Sports Strategies and others who helped me collect these thoughts on twitter and via email.)
(Image: istockphoto.com)
Follow Tim Berry on Twitter:
www.twitter.com/Timberry
The idea is mine - i am not sure how much tech is involved - because i dont know much about technology, and i am staring into the face of a guy who wants 50% of my company to take ownersship of programming and says he will take the product live.
can someone suggest something here? whats the typical equity share of the founders?
Small and Medium Businesses (SMB's) can suffer a great waste of resources (time and money) trying to manage a developer. Seek out a firm who just manages tech projects, and let them handle the developers. One neck to choke, and you can yell at them in english.
I guess thta is better than him telling you that you need a new ECM.
Software engineering is not bound by physical constraints as much as other engineering sciences.
( I might add that I believe the Engineering part of software took a giant step backwards when web development came along)
Usually if "it's not doable in software just means you have lazy developer or maybe worst: a developer that is in over his head.
You want to know how Anonymous hacks so many site. It's a feature not a bug. #1 cyber security problem BAD CODE.
My 2© cents – gatoMalo_at_uscyberlabs_dot_com
http://USCyberLabs.com/blog/
For someone who wants to work with developers, please try your best to put together all your wants and wishes before you start talking to the programmer. Then, in a group, come up with as close to a final product as possible, even if it means splitting it into smaller pieces and taking one piece at a time. It will minimize the heartburn and anger on everyone's part.
My favorite is the make me a hot dog with mustard. So they baked mustard seed into the bun. Hot dog was uneatable.
The single most important point of these books comes straight from Judge Wopner of "The People's Court," viz: "Get It In Writing."
The second most important point is, in effect, "specification." If you wanted an addition to be made on your house and someone showed up with boards and saws and hammers and nails, then asked you, "by the way, is this what you want?" ... you'd run that fellow off with a stick (or worse), now, wouldn't you? Everything, from houses to streets to the signs that are placed next to them, is entirely ruled by specification and established procedure.
The final point is: project management. Software is a big undertaking that involves design, implementation, testing, documentation, and many other things that can all fall through the cracks. Yet, even though the task-lists are different from other big projects, in all other respects it's just a big project.
Holz's books were not "computer" specific, but they very certainly apply.
You touch on two issues: relationship and capability.
Relationship: first meeting with a prospective developer, execute a mutual non-disclosure agreement (MNDA). Both parties should know what that is and why it's a first step, and both parties should know at least the basics of intellectual property (IP) law, particularly the concept of work for hire and when it does and doesn't apply.
Capability: what's possible in software depends on the developer, but not just the developer. If you have to ask someone if a developer is up to a job, you're not up to it yourself, period. If you don't know enough by yourself to be able to judge whether software is doable, then it's probably not if you're in charge.
Software is not magic. If you think it is, find something else to do. If your developer thinks it is - and the dragon metaphor suggests as much - you have a big problem.
I see headlines for news stories that start with "Why" when they should start with "How." If you'd write such a headline, then you should stay as far away from software development and developers as you possibly can; you just don't get it.
Successful software projects are invariably those for which the person in charge understands both "why" and "how." They may not be able to do it all alone, but anything less makes for bad relationships and all the rest.
Except I'd change it to "Software is [usually] not magic". I agree that the vast majority of software projects are straight forward enough that there shouldn't be any magic involved. If you are building an accounting package or stringing together web forms, then there really shouldn't be mystery.
That's not the case if you are building voice/facial recognition software or applying neural networks to find something in data that only a human brain could see before. There be dragons out there, but not on well traveled terrain.
Also, the fact that the NDA is common sense, is the very reason it's on a bullet list of things to do.