Hartvig 17 Sep 05

> Would you settle on a brush and then go look for a painter that could use it? Or would you rather find
> a good painter and then let him use the brushes he sees fit for the task

I see your point, but the metaphor doesn’t last; a painting is a static finished item, where software (or technology) isn’t.

Tomas Jogin 17 Sep 05

Hartvig: No metaphors last.

Within the scope of the development of the project, I think David’s analogy fits quite well. However, as Hartvig noted, software evolve.

Then it comes down to whether you want to deal with poor or average programmers, which are easy to find, or if you want to deal with good or excellent ones, which are harder to find. I, for one, wouldn’t ever want to constrain myself to only dealing with poor or average programmers.

Gil 17 Sep 05

Picking a platform is also important from a business standpoint. Looking to the future needs to be done not only from an innovative standpoint, but also from a practical one.

I think these decisions are best made by the entire team, not just business people or tech people, as there are other factors that need to be considered.

• Is this a proven technology?


• Are there any compatibility issues with existing systems?


• How difficult is it to find a replacement (or an additional team member) should something happen to the primary developer(s).

Jason 17 Sep 05

I agree to some extent, but there are some serious pitfalls with this strategy… As already noted, software changes, so you could have a great 1.0 version done with some unusual development tools and then lose the person(s) that wrote that version and have to start over or settle for a 2nd rate coder for 2.0.

There’s also the danger of getting someone who’s so passionate about the language/tools that they are more interested in the tools than the product.

Of course there’s the risk in picking a set of tools that becomes obsolete as well. There’s that danger with every toolset of course, but the more mainstream generally the lower chance the toolset is going to disappear.

Overall, I think if your product (or wallet) is great then most of these gotchas can be seriously mitigated, but I don’t think that’s true for all of us.

Anonymous Coward 17 Sep 05

Would you ever let the tech people come up with the business rules? Would you ever let them determine the margins, operating expense limits, or preferred debt to equity ratio? Then why let the business people come up with the tech rules? What makes business people qualified to make tech decisions? Tech folks devalue their existance if they delegate these decisions to other folks who are less qualified.

Jon 17 Sep 05

Deciding on a software platform IS a business decision.

Dan 17 Sep 05

While I agreed with it, doesn’t this conflict with you basically saying 37signals would have a hard time hiring a Windows-using developer?

Menno van Slooten 17 Sep 05

I wouldn’t decide in advance on the brush being used, but I would definitely decide about what type of painting I want. Is it an acrylic painting? Waterpaint? Oilpaint? I’d rather compare the brush to the developer’s software tools to get the job done (like text editor/IDE) than to the technology platform.

--Josh 17 Sep 05

The thought is nice, but I doubt that you guys would hire the best developer you ever came across if he would only use .NET - at least not to work on any of your current products. This seems like the kind of “rule” that needs to be put into context and qualified a lot to work. Then, as noted above, you have the issues with domain knowledge and marketability of the end product.

Pete Forde 17 Sep 05

I think David makes a great point. I’ve saved the permalink to this article for the next time I’m arguing with someone about this very thing.

To me, what he’s talking about is the tendancy of middle managers to attempt to micro-manage their techs in ways they shouldn’t. He’s not advocating that the shop switch to using Ada or emacs macros every time there is a new hire.

In my role I could very easily find myself defending the decision to use Rails against a sales driven push from the VP level down to use some expensive proprietary solution.

It also should be mentioned that “good” developers rarely only code on one language or platform, as part of what makes an elite coder is the realization that all languages are basically the same with slightly different syntax that can be picked up in a few weeks of applied effort.

Ryan 17 Sep 05

A mistake many companies make is picking a platform and then trying to fit all their applications into it. This often results in overly complex systems, early obsolescence, and long development timeframes.

A related issue is that often companies invest so much into a platform or software environment that they will not entertain any other options, no matter how much it costs to stick with the status quo.

Robert Hoekman Jr 17 Sep 05

Interesting analogy, but a paintbrush doesn’t map as perfectly to a software platform as you suggest. You know as well as anyone that most developers prefer certain languages and platforms over others, and it’s not always because one is better than the other. Even if you are, as you should be, more passionate about the project than the tools, you will still lean towards the tools you like best. You like Ruby on Rails best, for example, and you’re using it on project after project.

What is more likely effective is to choose a really knowledgable generalist or project manager who can make the platform decision with a bit more objectively than a developer, and let that person start finding the best developers for the project.

Daniel Lakier 17 Sep 05

Good programmers can work in different languages, and pick up new ones quickly - syntax is not such a big deal.

HOWEVER, rarely do we do systems that are not part of a larger picture, and you do need to pick tools that the client can maintain, that interact with our systems, and that keep the client’s infrastructure as straight forward as possible.

If every system in a client’s organization used different tools, it would be … bad.

Caio Chassot 17 Sep 05

Pete Forde: part of what makes an elite coder is the realization that languages vary in power, and while syntax can be picked up in a few weeks of applied effort, different languages yield different possibilities and different programs.

cf. Paul Graham’s “Succintness is Power” and “Beating the Averages” (and other of his language design related articles)

Not Dave 17 Sep 05

Sometimes I hate computers and technology.

It comes down to the million dollar NASA pen vs the Russian Pencil. So many times we solve problems with computer technology because we can, not because we should.

Anonymous Coward 17 Sep 05

More often than not, languages and related tools represent infrastructure. Would it be absurd to look for building contractors that specialize in steel frame houses?

The things that are more like your paintbrush are IDE’s and command line tools. When I see job posts requesting Dreamweaver experience, then I shake my head, knowing that there are plenty of people who hand code great (X)HTML+CSS without relying on Dreamweaver.

SH 17 Sep 05

I would have agreed with this opinion 5 or 6 years ago.

Alas I have lost interest in IT as it moves from artistic innovation, to factory assembly line production.

Actually it has to. The old way was bad. The new way is good. Seriously.

Developing systems is not an art. It is a science. This means that you take best practices and design patterns (cookie cutters), you utilize the proven tools and technologies, and then you hire competent technicians to churn out the necessary code. In this regard, you cannot afford to have “artists”, you need reliable “engineers”. So these are two completely different realms.

Craftsman days? Long gone. They have to. Business cannot afford to have un-tangible works of art :). They need measurable proven (cookie cutters) to get economical results.

So for these days…it is better not to hire any craftsmen, they will ruin the system…better get the platform first, and then hire programmers who know how to work it :)

Software development now, is like McDonalds. You don’t go out looking for the best chef who will introduce her own flair. Instead, you invest in building a predictable system and platform, and just keep plugging in competent “operators”…

Claus 17 Sep 05

But in the end the poor business guy has to write SOMETHING in the ad announcing a job opening, and what are his options except to ask for some skill? “Truly gifted developer wanted, no platform required”? Not likely to pull in any smart people.

- I can fully agree that, given sufficient argument, he might choose to go with the opinion of the talent instead of his own, but starting nowhere is just not doable.
The real upshot of your hunch on this might be something else: If you have a “business people vs software people” division in your company, you’re sunk.

Lee 17 Sep 05

To SH-
You believe that most software development should be done like a McDonald’s assembly line? This attitude explains why most software sucks. You can’t take a bunch of average or incompetent people, plug them into a standardized factory process, and expect top qualityresults.

Daniel Lakier 17 Sep 05

Software sucks for 2 reasons:

1) People build software that does not do what is needed
2) People develop software without any process or plan. Just expecting brilliant people to produce brilliant code. Not going to happen. If you base your project’s sucess on individual performers you are asking for failure.

Anonymous Coward 17 Sep 05

People develop software without any process or plan. Just expecting brilliant people to produce brilliant code. Not going to happen. If you base your project�s sucess on individual performers you are asking for failure.

That must be why so much of the software developed by process-heavy no-individual-rockstar consultancies is crap. It’s too complex and people rarely enjoy using it. Who’s thrilled to go to work today and use their “internal systems” build by one of the huge faceless consultancy firms? Not I!

I’ll take software build by a small group of highly creative people. There’s enough red tape and inefficiency in the workplace, I don’t need some fancy, overpriced, process-heavy consultancy bringing their additional baggage to my problem.

SH 17 Sep 05

To Lee-

Personally I miss the old innovative “more art then science” days. However, I believe that once enough solutions have been developed for existing domains - then best practices and design patterns make it a very simple process to build another type of what has already been built. After a while it makes sense to repeat tried and tested ways to getting things built.

IT is there to support business. Business comes first. So this means that if the “shop” already has processes, tools, and expertise..they are going to choose the platform that works for them. They certainly will not allow for rogue developers each choosing what to develop on (support nightmare).

Frankly, business systems are pretty boring in general. How much innovation and artistry does a typical business system really need?

Yes, I think that for the generic run of the mill systems, businesses are right to take average developers and plug them into standardized factory processes. In this case, the process is high quality, that if followed properly, even average developers can create stellar results.

Now, I think that there are areas where innovation and radical approaches are required (read: not your typical business system, after all - how many times must we re-invent the wheel?). In those areas, you need the remaining craftsmen (and craftswomen) jumping in and blazing the path forward.

Daniel Lakier 17 Sep 05

I don’t know. Anonymous’s comment that consultancies produce software that is crappy and not fun to use, is probably partially true, though the crappy part is probably due to using bad consultancies, more than anything else. Certainly large systems are rarely fun to use (who wants to spend money on that?)

But you cannot build them without a process and by relying on supestar programmers - they are too big, too interconnected, and too complicated. Not possible.

At the same time, you probably can’t use that approach to develop fun, innovating exciting software, like Basecamp and such. Both have their place, but the second you are relying on superstar programmers, and avoiding processes, you will not be able to build large complex systems. Too many screens, too many boring functions, too many complex functions, too much variety in business rules. Big systems are just different, too many interfaces. They have their own challenges that make them interesting, but I am sure they would not appeal to many of the readers of this blog.

// rhjr 17 Sep 05

At the same time, you probably can�t use that approach to develop fun, innovating exciting software, like Basecamp and such. Both have their place, but the second you are relying on superstar programmers

The last person I’d ever rely on to build fun, innovative, exciting software is a superstar programmer. That person might be on the team, but the guys with UX know-how would be the guys I’d rely on, and the superstar programmer would never write a line of code until the UX guys showed him what to build. In a lot of cases, particularly with web apps, you don’t even need a superstar programmer. You need a clear and concise idea, and then you need to build the simplest thing you can to satisfy the idea. If your app stays stripped down to its absolute necessities, as it should, you don’t need a superstar programmer. Simplicity is simple to build.

I’ve seen way too many applications built by superstars that are completely unusable. Superstars know they’re superstars, and they’ll code themselves into a corner on a daily basis to keep proving it.

The guys at 37signals call themselves “user-experience experts”, not programmers.

Charles Jolley 18 Sep 05

This is a good point. However, I think you can also use the reverse to help you find great talent. Certain technologies attract really bright engineers; I think Ruby on Rails falls into this category. When you go looking for someone to help you build your product, you can go looking among the community of developers working with these productive technologies to find some really top notch talent.

Of course, this does not apply to everything. Since Java, .net, etc is taught in so many places, you will find a lot more mediocre developers along with the really talented ones in those communities so this approach is not as effective.

Jesper R�nn-Jensen 18 Sep 05

> Would you settle on a brush and then go look for a painter that could use it?
>Or would you rather find a good painter and then let him use the brushes
>he sees fit for the task

David, I really love your arguments! Thanks for the splendid example.

Wesley Walser 18 Sep 05

For a decent programmer learning the ropes on a new language shouldn’t be too hard, and all of that learning could be done during the part of programming where most tasks are meinial anyways.

Anonymous Coward 18 Sep 05

You guys are missing the point. David is talking about passion. You want your people to work with tools of passion so they build products of passion. Sure, any good programmer can learn any language, but this isn’t about learning, it’s about believing. When you are passionate about what you do, and you use tools you are passionate about, you can’t help but build better products. Isn’t that the goal in the end? Better products?

David Heinemeier Hansson 19 Sep 05

Innovation, fun, and creativity is not bounded to commercial applications like Basecamp. Remember, Basecamp started as an internal tool! In many ways, its the incarnation of the boring business tool.

But too many shops have taken the approach that SH seems to think is great. Software is an assembly line, programmers are interchangable, and we need to pick the biggest platform from the baddest vendor. Hogwash.

Great applications are created by people with passion that cares. A sure way to undermine the interest to care is through corporate standards that mandate one-size-fits-all from high above.

It gets even worse when you reverse the cause and effect as in:

I think that for the generic run of the mill systems, businesses are right to take average developers and plug them into standardized factory processes.

Ever stopped to wonder if the systems became generic and run-of-the-mill because they were developed by average cogs in a machine? The best of brains can be made the dullest of wit in a system like that. And the most “average” of brains can archive the greatest of things in an environment that encourages passion.

The single most important factor in determining a programmer’s productivity is motivation. Passion drives motivation like nothing else. Thus, to optimize productivity, you should optimize for passion.

Greg 19 Sep 05

Anonymous wrote: “Would you ever let the tech people come up with the business rules? Would you ever let them determine the margins, operating expense limits, or preferred debt to equity ratio? Then why let the business people come up with the tech rules? What makes business people qualified to make tech decisions?”

Tech decisions ARE business decisions, nimrod.

Alexandre Simard 19 Sep 05

Man, this place is under attack from corporate drones! The 37s folks must be hitting on some serious nerves…

Here is my take on the subject. DHH is mostly right, but there is an important point which has been forgotten here. Software solves problems. Programmers are problem solvers. The best programmers solve the hardest problems. But the toughest thing to do from a management perspective, and the most important factor in programmer productivity, is to garner sufficient interest from a good programmer for *your* problem, which is most likely not hard or challenging enough.

When I say “interest”, I don’t just mean “willingness to work”, I mean genuine interest for your business domain and problems. The best way to get good software is to have developpers eat their own dog food. And for them to do it with conviction, too.

Brad 19 Sep 05

DHH (and/or JF)-

Where do you see the role of mentoring in business? Not just speaking to the masses, but investing time in a person so that your passion can bear fruit in other people.

David Heinemeier Hansson 19 Sep 05

Mentoring is great, but the passion has to be there already. I wouldn’t waste my breath with someone just looking for a paycheck. That’s why participation in open source software is such a great filter.

Kenneth Miller 19 Sep 05

I think DHH has a point with regards to passion. Passion matters. Regardless of the position you are filling you want people with a fire in their belly, and a spark in their eye. But passion, as do most traits, comes in many forms; some to be captured, some to be harnessed, and some to avoided.

Personally, I would never hire a programmer who�s passion is centered around the tools they use. In my experience I have found such people to be rather exclusionist and a bit close minded…especially when they created the tools…you know the developer who has xyz cat’s meow library he created and refuses to use anything else. This type of passion is an invitation only island, and when the boat traveling to newer-better tool land comes by you can bet nobody will even consider getting on. Such passion may work well for a very small team, but when is the last time you saw 3 excellent developers who are passionate about different tools get together and do anything but orate ala slashdot. Having been the Sr. developer with such coders on my team I can tell you this is less than constructive�or enjoyable.

Not all software is the same. A device driver is not a web app. A game is not a database. But all software is art. And all software is science. Software is architecture. Just as different buildings require different materials different software requires different tools.

Great architects are passionate about ideas, concepts, visions, and realization. These are the people you want. I think DHH has it a little backwards: Developers will always have preferences when it comes to the tools the use, but the great ones can sculpt with clay just as they can sculpt with stone or steel.

And the truly great ones will burn and smile while doing it.

Dean 19 Sep 05

“To attract the best, you need people working with tools of passion.”

It sounded great until this point. To me, it’s not “tools of passion”, it’s just passion.

I wouldn’t hire a painter that used only one type of brush no matter how passionate he is about that brush. A passionate painter can and does use any brush.

Passionate and smart developers should be able to use any tool as well. And there are valid business reasons to choose one tool over another.

If you are starting from first priciples fine, use whatever you tool you want. But most businesses have already invested real money in their infrastructure. You don’t throw it away because your developers are interested in the latest thing. There’s always a new latest thing.

Kenneth Miller 19 Sep 05

“That�s why participation in open source software is such a great filter.”

Contributing to open source software projects is an excellent way to give back to the community, meet other talented developers, and further fuel the fire of one’s passion for software development. Passion is a strange beast that is fed only when consumed.

And I think that contributing to and participating in open source software speaks for itself on the resume.

“I wouldn�t waste my breath with someone just looking for a paycheck.”

And I agree that motivating easy paycheck seekers with their twisted senses of entitlement is a bit like motivating a rock to bleed red.

But there are plenty of passionate developers who do not contribute to open source projects. Passion breeds focus, and focus consumes time. Can you discount a developer who has been focused on creating great projects just because the source code for those projects is not freely available to the public? Would you discount the architect because the she is not prepared to give away her work? Again, don’t get me wrong. I use open source software daily and greatly (greatly!) appreciate the developers around the world that have made my life so much easier. And I try to contribute the best I can with the time that I have. But I have always had trouble with the way that developers of open source look down so smugly upon the more “pedestrian” developers who are involved only in capitalist endeavors. I think that non-judgmental, Radical Inclusion is the best way to facilitate wide-spread Participation. There are incredibly passionate, talented people who have not been taught to be naturally altruistic. Filtering these people in our workplaces and in our social circles will never further open source as a movement or as a community.

Ahhh, Open Source: Communism has never had so much religion and ego.

Sorry, I obviously don�t have a blog of my own ;)

Brad 19 Sep 05

I don’t quite agree with the comparison.

You wouldn’t settle on a brush and then go looking for a painter, but you can’t compare the brush to the technology.

The brush is the keyboard or the monitor.

You would (or may) choose the kind of paint (ie, acrylic, oil) or even the style of painting (impressionist, cubist, realism, art deco) and then find a painter passionate about those styles.

I know it’s just an analogy, but still…

There are valid arguments on both ends of this one. The smaller your company and/or the less established the existing technology (within your current workspace), the more freedom there will be for finding the right person, regardless of technology. However, if you have established your operations around (for example) Java, it would be silly to hire a passionate non-Java programmer and then ask them to work in any technology that they are passionate about.

If 37S is willing to stay small, you can maintain your high passion:programming or genius:productivity ratio. But if you are going to grow, you will soon run out of genius and have to hire happy people like me who show eagerness and willingness but may not have a focused passion.

I also think corporate culture has a lot to do with evoking passion and productivity and an eagerness to deliver excellence. That’s where the mentoring question came from. I think that the Genius has the responsibility to pass on their genius and their passion not just to the hordes but to an individual or two.

Robert Brook 20 Sep 05

I don’t think most business people see themselves as choosing a development platform. It just is. There’s no discussion. At best, it’s inherited from a sort of corporate history.

Any suggestion that another development platform might even exist, let alone might be preferable, is often seen as unsupportable.

Staying Here is preferable to Going There, it seems.

GoClick 20 Sep 05

Seldom is it that artists have to work together on the same painting, generaly you’re adding more artists to an ongoing project and when you have 10 artists working in 10 different styles with 10 different sets of paints and brushes the final piece will look like a piece of junk

alex 29 Sep 05

Bah.

It’s about support and access to easily replaced parts. Why program a corporate product with some obscure paintbrush, when it’ll cost twice as much to staff a support team because theres no one to code for it?

It’s just a business extension to the standards argument. If company x standardizes on, say, java, it’s a lot easier to manage going forward.

but uh.. yeah.. get real… or something.