If you have a room full of capable developers, what can be done to encourage those developers to become excited and enthusiastic about software and software development?
No gimmicks, but a genuine move to create an environment where people want to work in software, not just because the company is a good company to work for overall.
what can be done to encourage those developers to become excited and enthusiastic about software and software development?
Nothing.
A passion for software development comes from within, and cannot be created from zero. Feeding an existing passion is easy- resources, training, and a visible appreciation for that passion from management are all it takes.
The only exception may be to lead by example. If you're excited, others may follow.
UPDATE: As has been said in other answers, it's much better to hire well up front. I'd pass over ten good programmers who just want a paycheck for one good programmer who codes in his/her spare time for fun.
ANOTHER UPDATE: This answer has been jumping around with up/downvotes, so let me clarify. The OP's wording specifically asks how to make an existing team excited "about software development". It is my contention that if they are not already interested in their chosen professions, there is not much an employer can do to engender an interest. A disinterested, unmotivated team will make a mess of the most fascinating project. By contrast, a motivated team of professionals that like their jobs can make the best darned calculator program out there, and enjoy every minute of it.
Having an interesting, challenging and profitable problem to solve, where all developers have a stake in the results. If not, you have a room full of developers sticking around as long as the pay checks clear.
How about giving them a financial stake in the outcome of their software project(s)? For example, corporate profit sharing.
That being said, passionate developers are the kind of people who go home and write software in their spare time.
Going to a software development conference with good, inspirational speakers can make a huge difference.
I've yet to meet a capable developer who is not already excited about making great software. The trick is to stay out of their way and not destroy the natural enthusiasm.
The Joel Test is a good start.
You don't.
You either have people in the team that love learning and always want to push themselves to be better, or you don't have those people in your team. Of course reality is, you'd have a mixed bag.
Just employ people who are enthusiastic (it's easy to tell), and don't employ the ones who see programming/developing software as 'just' a job.
It's impossible IMO to turn complete non-enthusiasts into passionate programmers. There is no silver bullet.
I have to agree a little bit with the comment made by Pascal, but I'm not going to start off that way.
Overall, it has been proven that one of the best ways to give developers an environment that allows them to like their work is to give them freedom. However, your looking at a different route here, you are trying to find "passionate" developers.
To be 100% honest there is not a direct connection to "capable" and "passionate". There are hundreds of developers out there that are capable of being programmers, and mighty good ones at that. But many of them do not have any desire to become passionate developers.
To create a team of passionate developers, you really have to start with the recruitment process and HIRE passionate developers, not try to "create" them.
I am inclinced to say nothing like others have, and i must agree that a real passion for it is not something you can create, it either exists or it does not however there are things you can do.
Scoring high on Joel's test is a great start,
Sheild your developers from all the politics to the best of your ability. Let them what they do best, develop software. Nothing kills a productive team like having to squabble in inner-office politics.
This well-known conversation says it best:
Peter Gibbons: Bob, I have eight different bosses right now.
Bob Slydell: I beg your pardon?
Peter Gibbons: Eight bosses.
Bob Slydell: Eight?
Peter Gibbons: Eight, Bob. So that means that when I make a mistake, I have eight different people coming by to tell me about it. That's my only real motivation is not to be hassled, that and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
money, money, money... and don't say that money doesn't matter if the project is exciting or boring routine.
I think the biggest thing is the company has to value what the developers can do for the company. If the company is run by cheapskates who just see your developers as an expense they can't wait to be rid of then you are doomed. The developers' team needs to be viewed by management as a strategic asset that makes them money now and will make them more money in the future.
Also good communication in the company is vital. The developers have to be able to find out what it is the company needs them to do. Autocratic top-down bureaucracy and mushroom management can wreck morale and make it impossible for developers to add value, regardless of what level of enthusiasm they brought to the job. The software your team builds will be only as good as the communication in the company--I think that is what Conway's Law is about.
So that is a big challenge, in many cases an impossible one, because senior management will have their own ideas about priorities and communication and good luck influencing them. But the alternative is guerrilla development, where you're fighting an endless battle against your own company.
For me, the things that keep me motivated are:
Fire all the PHBs and hire smart managers who maximise the chances that the software will actually be finished and work right.
In my opinion, the absolute, #1, most essential thing that motivates developers to be enhusiastic about their work is a sense of ownership over their product. All the team-building excercises, reading groups, etc. are good but ultimately ineffective if the developers don't have a sense of ownership.
Here's a quick, off the cuff list of things that are important, in my mind, to ensuring this is the case:
Hire the Right People
During the interview process ask questions that let you see their passionate about the craft.
Some examples, Do they:
Once you have good people stay out of their way. Have the right amount of process, don't force unnecessary standardization, listen to issues, be honest about reasons things are happening.
Although I agree that it is not easy (or even possible) to create passion about programming, I think it is possible to keep passionate developers enthusiastic about their work. Even the most passionate programmer developer can become disillusioned if placed in a stagnant work environment.
So what can be done?
I have found working in an organisation that has embraced agile development has many of the correct qualities for building enthusiastic teams.
Read "Dynamics of Software Development" by Jim McCarthy. Seriously, nearly the entire book deals with this and related issues.
Just to be precise, is the question "I have a team of developers, and I want to make those specific developers enthusiastic about software development", or simply "I want a team of enthusiastic software developers"? In the latter case, simply don't hire people who aren't enthusiastic.
In the former case, you're pretty much screwed. It's hard to change someone's personality so much that they start to care about something they didn't really take an interest in before. Of course it can be done, but let's face it. How many here have been unable to convince their better half that programming is interesting? For that matter, how many people have failed to adopt their girlfriend's enthusiasm for shopping, or shoes? ;)
Convincing people to share your interest and enthusiasm for something is hard work.
Unless you're willing to set aside a few years of your life for getting into the head of each individual developer, getting to know them and what makes them tick, and gradually push and prod them towards taking an interest in something that they previously simply considered a job, you're probably better off letting them go and hiring people who are motivated to begin with.
In Weinbergesqe fashion:
You've asked the wrong question. The right question is "What are the things that managers do that dispirit developers and reduce moral?" Then don't tolerate those things in your environment.
And oh by the way, you should already know the answer to that question. If you don't find another job.
A management team that knows computers and can hold their own in a technical conversation is a very helpful feature. Don't try to sell passionate developers on hype, tends and buzzwords.
Give them interesting problems.
Give them the means to solve those problems.
Minimize the amount of crap they have to deal with that isn't directly related to solving those problems.
Reward them for successfully solving those problems. Don't underestimate the value of a sincere pat on the back from the guy who signs your paychecks.
Give them a stake in the larger venture -- beyond the next paycheck.
And when they suggest a new problem they think is worth solving, listen.
If they're fundamentally unenthusiastic about software development, there's nothing you can do.
If they're enthusiastic, that's great, and you need to avoid squelching that. There are some excellent recommendations elsewhere in these answers.
If they used to be enthusiastic, and have had that beaten out of them, you are likely to get good results by giving them reasonable challenges, shielding them from bad management, and in general treating them like valuable and respected people.
If you have a room full of capable developers, what can be done to encourage those developers to become excited and enthusiastic about software and software development
The correct question is actually "What can be done to encourage those developers to become excited and enthusiastic about software and software development in our company".
It's quite simple actually. The answer has never been a secret. It's just nobody listens to it.
Very simply elements:
Let those enthusiastic developers work among other passionate people. Remove those who don't care from the team. Otherwise they will act like diseased cells proliferating apathy and depression to the other team members.
Aspire to develop a quality and professional product
Establish a professional and effective process
Trust and respect people. Value their knowledge. Respect their opinions. Actually, it's part of a bigger strategy: let your developers be able to make a difference and let them see they can really influence and change things.
Let them grow professionally and let them see this growth is appreciated and needed by you
Now what doesn't help at all.
Pay them badly. Developers are also humans (for the most part) and they also have their bills to pay.
Reject their initiatives, proposals and improvement suggestions. Tell them each time they come up with something that their attempt to introduce change make them a foreign und unwelcome element in the company.
Have low quality product and have no interest to make it better. Hacks, copy/paste code, accumulating technical debts, things falling apart after each release, that does not motivate developers.
Have badly run development and chaotic process. Tasks, projects and small decisions taking a new vector every few days will finally remove desire to be involved from anybody. Failing schedules because of unpredicted work load and feature set, they all go down the road. It will suffice to run out of coffee some day for some of them to start moving elsewhere.
Have a boring and uninteresting social environment. Developers having nobody to talk to to share their interests will finally feel dull. Not everyone is interested in taxes, football and kindergarten issues as the only topics on social gatherings.
Dan Pink notes 3 things that motivate people if there is creativity required in a job. RSA Animate - Drive: The surprising truth about what motivates us is a 10 minute video about these but here are the 3 things:
Autonomy - Give the team control over the schedule and empower them to own their work.
Mastery - How well are they developing their craft of building excellent software.
Purpose - Why are they making this software? What massive benefit will it have?
A few other sources on this stuff: