I Have This Great Idea for an App

by Chris Smith

The great thing about being a full-stack developer is having the ability to turn an idea for a software product into reality. As a consequence, however, you're likely to hear more than a few unsolicited product ideas. One place I worked, there was this business founder type who would regularly come over and say, "Guys, I have this great idea for an app!" It got to the point that as soon as he opened with that line, the developers would start laughing. In a good-natured way, of course.

Sadly, some developers I know have become so jaded with these idea people that they end up making disparaging comments like "learn to f—ing code." Now, I'm all for more programmers, and believe that everyone should give programming a try. But in my opinion, what is really needed is for the idea people to get better at marketing.

Marketing is Hard Work

While most of what needs to be done in the nascent stages of a startup is to find product-market fit, the naive idea person is convinced of success and can't wait to build the product.

A developer friend recently emailed me the following story:

At the cocktail hour I met a guy who is the biz guy for [blank]. While chatting with him he told me about an idea for an app he had developed with [blank], a sort of checklist app for [blank] to help them make sure everything is done, and which would also include things like [blank]. He was quoted $40,000 to do the job so the project was stalled for lack of funds. It seemed like the kind of nichey app that could do well and make some money, but maybe that was the cocktail talking…

When I read or hear something like this, I bristle at the part about being "stalled for lack of funds." Now, it could well turn out that the idea person has done everything possible short of actually building the product to validate his idea and build his customer base, but I doubt it. If so, he shouldn't be making a cocktail-party pitch without mentioning things like a sales funnel, how many prospects are visiting the landing page, how many have signed up for the email list, how many have submitted the fake purchase form, what's being done to get in touch with them, and how their feedback has influenced the idea.

Heck, even developers will do well to put marketing first, as Start Small, Stay Small author Rob Walling has argued for years, in articles such as Why You Should Start Marketing the Day You Start Coding. But if you're an idea person looking at giving up a sizeable amount of cash or equity in order to build your app? You'd be nuts not to validate your idea first with relatively inexpensive marketing.

Investor's Due Dilligence

"We invest in people rather than in ideas" is an aphorism of venture capitalists. As you consider investing your sweat in the idea of the bright-eyed, silver-tongued idea person who approaches you at a cocktail party or in the company lunchroom, you would do well to follow it. (Even if you are just starting out as a developer and looking for a way to get some real-world experience, your opportunity cost is very high. Getting involved with open source is probably a much better early investment.)

Now then, hopefully this isn't news to you, but partnering with someone who is all talk and no action is a terrible idea. So is partnering with someone who doesn't have a marketing mentality. This is what I call Steve Blank 101: Viewing a product idea as a hypothesis that needs to be tested as cheaply as possible in an iterative fashion. Build a test, run the test, look at the results, fiddle with the hypothesis if needed, and repeat, each time investing a little more. Non-programmers can do this very cheaply with tools like WordPress, so a lack of funds is no excuse. (For programmers, I recommend using a static-site generator such as Jekyll.)

Once you get into this Customer Development and Lean Startup stuff, you realize it takes a lot of work. Therefore, judge the idea person, not the idea. Don't partner with someone who indulges in the naive hope that his or her idea is ready for the world and just needs to be built. Ask for proof.

Don't Pick the Language You Like

by Chris Smith

TL;DR: If you're choosing a programming language simply based on its own merits, you may get the decision wrong. You must take into account the leverage offered by its community and ecosystem, both current and future.

I have a friend in the D.C. area who is learning to program. He began with a free online course in Python, and is now using Django to code his first personal project, a web application. The last time we talked, I suggested that at some point in the future, before he goes too far with Python, he should do some research comparing it to Ruby (including Rails), and possibly also JavaScript (including Node and Express.) One idea I gave him was to go to each of the local user groups (Python, Ruby, JavaScript), and ask if anyone could help him decide. After a couple weeks I received this update:

hey chris,

so i brought up the question ruby vs. python at a meetup the other day and it set off a 30 minute discussion! a lot of folks in the room programmed in both, some even learned ruby first, so it was a good group to ask. in the end though, the consensus was go with whichever you like, so i'll think i'll stick with python for now. the language makes a lot of sense to me and i've got some momentum so i'll stick with it for now.

This reminded me of some advice I received when I was in his shoes, just starting out. I had asked a senior developer how to decide between C++ and Java, and she told me that apart from Java's garbage collection, they were pretty much the same. Both had classes with which you could do object-oriented programming. She seemed dismissive of my question. As we talked further, she seemed to suggest that it was the programmer's skill that was the decisive factor, rather than the choice of language, which was merely a tool.

Thus, some prevailing wisdom: It's general programming ability that counts. A good programmer will be successful in any language. The choice of language should be appropriate to the task at hand, but otherwise can be made based on taste.


A year later, I was in my first job as a Java developer at a company that was mostly using C++. The VP of Engineering asked me and one of the C++ developers to each code a logging solution. There were a lot of features to code from scratch, such as saving the log output to a database, so he gave us each 5 weeks to do the job. I searched online for a few minutes and found log4j, an open-source library that had almost all of the requested features. I had to customize it to add a logging level that the VP of Engineering wanted, but I was done in about 5 hours.

Expecting to be treated as a hero, I went to the VP of Engineering with the news. His reaction was "alright, that sounds like it will work," and without missing a beat he found me something else to work on. After seeing a lot of this type of indifference over the years, my conclusion is that programmers and programming organizations feel good about using their skills, and they regard the stuff they build as assets. They don't get the same satisfaction and pride of ownership from integrating third-party solutions. I think the VP of Engineering was a bit disappointed to discover that logging in Java was not an opportunity to add to our company's stock of intellectual property.

A few weeks later, the C++ developer was still working hard on his solution. Although no one else seemed to care, my win with log4j sold me on the importance of leveraging third-party software. I mean, 5 hours instead of 5 weeks! I suddenly saw programming as a globally cooperative undertaking, with software compatibility as the most important factor.

Within the limited scope of individual or even team work, the idea that you should choose a language or other platform because you like it best seems reasonable. But again, think about the difference between 5 hours and 5 weeks. That's just one very small example. At every level of the stack, communities of developers work together to create ecosystems. Every platform choice you make–operating system, database, language, framework, library–is throwing in your lot with the present and future community and its output. It's vital to get each decision right, and to quickly reverse the ones you get wrong.

Platform vs Community

Typically, the language or other platform that you like best is the one that you feel helps you get more done in less time. What you appreciate is the inherent leverage that it offers. Therefore, the capabilities of the platform itself are definitely part of the equation: Your total leverage is the leverage you get from the platform plus the leverage you get from the community and ecosystem. All benefit depends on being able to apply the leverage to your problem space. In some situations, especially a novel problem space, a large amount of community leverage can be irrelevant, since it just doesn't fit. One of my favorite examples is Paul Graham's Beating the Averages, the story of using Lisp as a secret weapon in the early days of the Web.

Our hypothesis was that if we wrote our software in Lisp, we'd be able to get features done faster than our competitors, and also to do things in our software that they couldn't do. And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. That was what we hoped would happen, anyway.

What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours.

Paul's competition used languages such as C++, Perl, and Java that they perceived as offering more ecosystem leverage than Lisp, but because the problem space was relatively new, there wasn't enough applicable leverage to really help. Today, going it alone with Lisp for a mainstream CRUD web application would be a different story. In a competitive environment, it would be suicidal.


Since technology never sits still, playing the game successfully means divining the future. Many platforms are guided by a small group or even a single individual. I once made the decision to ditch a new but popular framework when I learned its BDFL had accepted employment that I correctly judged would turn out to be a distraction.

Some rare individuals manage to create the future. It seemed like one year Ruby was mostly useful as a console in which I could calculate how much money I was making as a Java consultant, and the next year I saw the project I was working on getting crushed by a competitor who was using Ruby on Rails. When that project failed, I myself switched to Rails. David Heinemeier Hansson created Rails because he liked Ruby better than PHP or Java, despite the enormous ecosystem leverage offered by these dominant platforms. Unlike Paul Graham with Lisp, Hansson's evangelism resulted in the creation of an immense ecosystem. As Victor Hugo said, "one does not withstand the invasion of ideas." Creating a new ecosystem will not often succeed, but it can, if you invent the right platform, or are correct in your assessment of an under-appreciated platform.


Nowadays, I code my personal projects in JavaScript. To be honest, I think Ruby is a nicer language. But as a platform, JavaScript occupies an incredibly strategic position, being natively available on browsers, as well as on servers and desktops with Node.js. Most importanly, the leverage on offer from the ecosystem is so vast as to defy measure. The issue becomes one of too many solutions. How to choose among the dozen or so packages on npm for each and every problem? Again, don't pick the one you like!

Do Your Homework on Open Source

by Chris Smith

Just as "No man is an island", no software developer works in isolation from operating systems, programming languages, databases, frameworks, and libraries. Almost as a rule, the best of these third-party solutions are open-source software. This is an apparent paradox, since the open-source world, based mostly on volunteer, unpaid effort, has the characteristic of being chaotic, disorganized, and crazy. Keeping on top of new developments in open source is a big job, and should be seen as a legitimate one.

Choose wisely

Martin Fowler, who has done a great job documenting software vocabulary, explains architecture as "things that people perceive as hard to change." Nearly every software project involves dependencies that quickly reach architecture status. Replacing a project's language or application framework with a better one usually means starting over again from scratch, and this can even be true of databases and libraries. Even a small software project will typically have dozens of dependencies, making it quite hard to pick durable winners.

Architectural decisions are extremely important to get right, all the more so because of the incredible leverage contributed by open-source projects. For most programmers it is hard to admit that our own contributions to our software projects are just droplets on top of an ocean of value was created by others. The effect of leverage is enormous. Forego leverage and competitors who exploit it will crush you, no matter how hard you work.

Time for research

If you're a typical programmer, you probably feel most productive when you're writing and shipping code. What would you think if I told you that you should spend a third of your time researching open source? Does that sound crazy? Horribly unproductive?

Think back to how much time you spent learning the platforms and libraries that you now use to create software. Add to that the time that you spent evaluating alternatives to the solutions you picked (or should have spent evaluating alternatives, in order to responsibly steer the massive learning investment that would follow.) Then imagine the millions of programmer-hours that are invested each year in open source, the new leverage available from these contributions, and the resulting depreciation of your own capabilities relative to the state of the art.

Because software has near-zero marginal cost, the pace of innovation is insane and unrelenting. The world of open source never sleeps. However, obsolescence is observable only in fits and starts. You may ride a winning platform for years without noticing a drop in your pay rate or opportunities, then suddenly wake up to realize that the world has moved on without you. As a profession, software development has few barriers to entry. You don't need a degree, you don't need to purchase expensive equipment, you don't need to pay for instruction, and with open source, you don't need to pay license fees. You just need to sit down and learn how to use all this free stuff. But this same lack of barriers means that you can never relax. You're running on a hamster wheel and you can never stop. My term for programmers who take a prolonged break from active learning is going EOL (End of Life), as in "it looks like he's going EOL with Java."

You might imagine that you can invest a minimal amount of time in scanning for obsolescence and keeping track of new developments, then rapidly adopt new technology when needed. "Let the early adopters bleed," you say to yourself, "I'll jump over when a clear winner emerges." This approach works well enough for incremental change, although doing a decent job of it takes more than a minimal amount of time. The trouble occurs when you fail to recognize a major power shift until the cost of making the switch is very large–perhaps too large for someone with bills to pay, in which case the result is going EOL. This is a personal version of the peril encountered by companies that Clayton Christensen describes in The Innovator's Dilemma, a book that I consider a must-read for understanding and managing your own technology career. The ultimate problem is that we are unable to detect big shifts until some time after they actually happen. Please read Nassim Taleb's The Black Swan if you need convincing about the impossibility of reliably predicting impactful events. The only reliable solution is to make the sure, steady investment in researching new technology that is characteristic of an early adopter.


The comparative advantage of leverage from open-source technology in software development is decisive, but transient. It is my impression that the average half-life of open-source technology is about four years, but that's just a guess. It would be fascinating thing to try to measure quantitatively, although an such attempt is likely to be futile. In the absence of really knowing how long we can expect our learning investments to last, a wise approach is to keep up a steady, ongoing investment over time. Never stop researching open source. Commit a third of your work time to it. The alternative may be a prematurely shortened career.