People keep saying, "I've got this great idea for an app. I've got this great idea for a framework." But these statements remain only ideas. Those people spend months writing down ideas about the software but never actually writing the software itself. Kevlin Henney says the moment you start forming your idea, you'll discover a million things about it you never would have thought of. Stop wasting time imagining what your product might be and start realizing it.

The principal bottleneck is that we don't know exactly what we want to develop or how we're going to go about developing it. If you ask anyone, they'll say they know exactly what they want to create, and exactly how it's going to be built, and exactly how customers are going to use it. Kevlin says these assurances would be great—if any of them ever ended up being remotely true. We think we know what we want, so the challenge isn't in the actual programming. It's in learning along the way.

Here's where Kevlin gets into the title of his keynote: He says software may be more likely to succeed if it were developed with minimal invention, in effect a restrained form of originality. This isn't related to the "good enough" theory of software development, in which if a product is good enough, you just ship it. Your product should still be fast, small, and solid and have the complete requirements to function well, but it's better to be underfeatured and understated. Test your product and be sure it's the complete package, but nothing more. The more fluff you have and the more features weighing your product down, the less likely it is to work well.

When you think about it, many UX requests are superfluous. The biggest win you can have is that your app works the way it's supposed to and is fast. It may not be pretty, but if you press an icon and it takes you where you should go in a matter of milliseconds, that's a great success.

Kevlin brought up the case of the failure of Toyota's software in its Corolla car, when brakes were pressed and the car did not slow down. After much scrutiny given to the code base, recent news cited the fundamental flaw being the complexity of the code. In other words, you couldn't have reasonably been sure the software would work because it was so convoluted. In this case, simplicity would be better—fewer things to go wrong, and it gives you an easier time to figure out and fix it if something does go wrong.

Code should be small. The less there is of it, the more comfortable you'll be with changing or discarding what doesn't work, and the less time (and cost) that will take.

Here are the characteristics of a "worse is better" approach to software design, as per Kevlin's slides:

• The design is simple in implementation. The interface should be simple, but anything adequate will do. 
• The design covers only necessary situations. Compeleteness can be sacrified in favor of any other quality.
• The design is correct in all observable aspects.
• The design is consistent as far as it goes. Consistency is less of a problem because you always choose the smallest scope for the first implementation.

The same is true for programming languages. People often have created extensions for C, and they're largely unsuccessful. Sometimes, improving on a functional existing system isn't worth the time and effort that would be expended.

The challenges are mostly within our own minds. We have these ideas that things can always be made better and that things must always be beautiful. It may be less glamorous, but adequate, practical code is actually the most useful.