"Please keep the scientists and engineers out of programming; they're damaged goods" by David Heinemeier Hansson

Authors

Writeup by Tyler Hicks-Wright and Diana Thai

About the Speaker

"David Heinemeier Hansson (born 1979 in Copenhagen) is a Danish programmer and the creator of the popular Ruby on Rails web development framework and the Instiki wikis. He is also a partner at the web-based software development firm 37signals."

Source: Wikipedia: David Heinemeier Hansson

Disclaimer

This is not rocket surgery -- this talk is not intended for mission or life critical systems

Air traffic control systems are often used as examples of what people should be doing. But they are not a good example, because no one writes air traffic control systems, almost all software is much smaller, much lighter weight, and failure is much more acceptable. Air traffic control systems are simply a dragon.

Most of this talk is based on his experiences with web-based collaboration and productivity tools. If a mistake is made, no one will die.

Problems with Scientists and Engineers in Programming

As a programmer, DHH has trouble relating to computer scientists and software engineers, to the point where he sometimes gets offended by being called a "software engineer".

Computer scientists and software engineers incorporate a lot of process into their work. They are very methodical. In the case of Computer Science, it comes in the form of research papers and theoretical results. For software engineers, it is requirements specifications and design documents.

But this is problematic. Good software is not reproducible. It is not scientific. It is not even predictable.

CS focuses on performance; how many CPU cycles does this cost? But often, optimizing is completely unnecessary. What should be much more important is how the code will look to the next developer, and how the program will look to the user.

Today's programs have not yet caught up with research, but researchers keep pushing forward. More work needs to be done on using what we have now. Computer Science researchers got us where we are today. Now the challenge is to use the tools available to us now to improve our software.

Creating software is often compared to other engineering fields such as bridge building. But there is a logical flaw here. Half a bridge is equivalent to no bridge at all. when you build a whole bridge in software, you build a bridge that is half as good as half of a bridge. It's better to build an excellent half-bridge.

"Half a excellent program is better than a full half-assed program."

Value of Happiness for Productivity

High morale is one of the best productivity boosters. Unfortunately, computer scientists and software engineers are not very well equipped for dealing with feelings - feelings are hard to measure. Agile methods focus more on making programmers feel happy and adding more flavor, rather than on mere science and optimization.

Software engineers and software developers are usually split on these issues. For example, software engineers like statically typed, "monolithic" languages, like Java and C#. Good software developers, on the other hand, care more about how they feel when they program, and so they choose dynamic languages like Ruby and Python. The comparison is similar to the comparison between corporate executives and entrepreneurs.

Another example: blogging. Blogging did not come out of Computer Science. It came from someone making a small change to the way web development worked, so it became more approachable and accessible. Scientists do not come up with these paradigm shifts.

Role Models

Macho roles lead to hero thinking. Heroes take on science projects that have no definite end, and therefore infinite work. Heroes work the long hours, but never seem to finish anything. They tend to become hermits, and eventually burn out. Good software is about finding ways to move stones with your mind, not with your back. The more good insights you have and the less effort you put in, the better. For a hero, every day is a crisis, which is a very stressful way to live life.

Instead of being a hero, students should strive to be like these role models:

1. Underachievers

Do less than you are capable of doing. Set smaller goals. Get something 80% complete using only 20% of the effort. The 100% solution is often too much. You can do 5 times as many things at 80%. Derive pleasure from getting more with less effort.

2. Cheaters

If you do 5% of the work and fake the rest, often it will still work. A great example of this is implementing the dots in Base Camp that show how much a document has changed. Instead of implementing a complicated algorithm to do the job, they took a shortcut and just counted the difference in bytes instead. That solution was much faster to implement, and is just as useful because of the way people edit documents and perceive document changes. Instead, they made a crystal look like a diamond. Another example cited was users’ not seeing their uploaded logos because the browser was caching. Instead of figuring out how to make the browsers stop caching, they just placed a message on the webpage to force reload their browsers. The result was favorable as any other result: customers were happy and no more complaints about this problem was sent.

3. Quitters

If you are working on something, and your brain decides that it is not enjoying the problem, DHH says you should “quit”! Procrastination is a good indicator that you should quit. He said, "I don't like hard problems and would never try a hard problem." "Just" and "only" are poison words that people use to get you to think that fixing an existing feature or adding a new feature is much easier than it really is. Don't fall into the sunk-cost fallacy either. If, half way through a project, you find out that it's not worth doing, don't stick with it because of the time you've already invested. That time is gone, but there's no use wasting more time on a doomed project.

Questions and Answers

Dynamically typed languages are not harder to maintain. They tend to be shorter, which makes them easier to understand and maintain.

Java tends to require 2 to 10 times as much code as ruby for the same application.

Sometimes, statically typed languages are necessary for speeding up bottlenecks. If that's the case, rewrite the bottleneck in a static language and leave the rest dynamic. One example is when they found a bottleneck and had a programmer write that part in C.

If you want to convince your company to use a dynamic language, pick a pain point and re-implement it in that language as an example of how good they can be.

The idea of software architects is BS. There is no way to architect a system without getting your hands into it and actually doing some of the implementation. This is why off-shoring has had so many problems.

Ruby and Python are an even match, they just satisfy two different personalities.

HTTP is an "awesome" protocol, because it is a very easy way to tie separate applications together.