Favourite Development Environment. He/She would definitely perform better.

Less Back-N-Forth Switching/Dragging. I mean task switching, for example, If a task is assigned to a developer and he commenced on that. Now don't think to drag him to much between the tasks. It requires time to come in to the context.

Nap After Lunch. Believe me, it really boosts performance of a developer.

Peer Code Reviews. The result would be quality code, which would directly improve performance when it comes to bug fix or change or add a feature kind of stuff.

Transparent Communication. It would help everyone in a team to discuss problems they are facing.

Daily Short Meetings. It would give everyone an idea that where we are.

posted November 6, 2007

Programmers need time to get "in the zone", a state of mind that allows them to concentrate on the problem at hand in the same way an artist becomes oblivious to outside distractions while drawing or painting.

When the phone rings or any kind of interruption occurs, they lose focus and will have to spend considerable time getting back in the zone.

Since you're looking for things to buy, get them phones that can be turned off, headphones and a subscription to Rhapsody.

Also, you might want to read Peopleware, by Tom DeMarco and Timothy Lister. This will give you some insight as to how to make your developers happier, thus more productive.

Links:

• http://www.amazon.com/Peopleware-Productive-Projects-Tom-DeMarco/dp/0932633...

posted November 6, 2007

The recipe is pretty simple for the most part:
- give your developers private offices (see links below)
- empower them and encourage them to take ownership
- give them the tools they need to do the job well
- keep the path ahead of them clear

Clearly, the only things that can really be bought are the tools and the office space. The rest largely fall into the arena of good leadership / management.

Links:

• http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html
• http://www.joelonsoftware.com/articles/BionicOffice.html
• http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html

posted November 6, 2007

Give them motivation. I second the opinion that empowering developers is key here. There are things that are mundane and boring (and they have to be dealt with), but there always are opportunities to make a difference and grow as well. Don't take this away by handing off entire product direction to BizDev/Marketing and reducing developers to coders.

posted November 6, 2007

Developer performance can be improved dramatically a number of ways depending on the needs of your developers and your shop.

1) Equipment - if they lack good equipment and tools, then you're in need of them. If you're going to get them good equipment this should not be limited to a development machine, a lap top or "documentation/email" machine and a good build machine but also the correct software tools for what they are doing.

2) A good work process. This includes having a PM who knows their job to create solid specs and requirements gathering, a good test team who can know how to test the code to get the best out of it, and lastly a good fluid and agile development methodology if it's needed. Developers should not be expected to have to write the specs, locate the bugs, and drag requirements out of the customer. Let them do what they do well - which is develop, and let them focus and concentrate on that. A good team to support and a solid work process and procedures should never be overlooked.

3) Beat them when they're bad. Reward them when they're good. And always, always, always - give them the truth and respect in all things. Developers are people. Often very creative, often susceptible to all the same failings as everyone else. They can be vain, egomaniacal, too engineering driven, and incapable of seeing "the big picture". They can also be insightful, driven to achieve, focused and your best bet at locating things you'd never have seen without their help. The long and short of it is they're people. Treat them with the same honesty, dignity and respect you'd want given to yourself and you'll do fine.

Performance is not achieved half so much through easy solutions like "better PCs" or "more tools" or things you can buy as it is a willingness for a team to pull together as a team and drive for a goal.

If your concern is to improve developer performance - then I'd say you're aiming at the wrong target. The real question should be how can you improve performance period. Not just for developers but across your organization. You hit on some elements - bug tracking and source control, neither of which should be on the shoulders of the developer.

A good bug tracking system - is meaningless without the process and procedures of good SDLC techniques and methods. So you'll need a good system of bug tracking and triage, a good system of design and development planing and program management, project management, a solid test team - and most importantly people who know how to use all these tools.

I've seen great developers who worked on what amounted to antiques and a while board in a dingy lit corner, and I've seen people with all the equipment and tools in the world who had awesome bennies, cool offices and who couldn't turn out a line of code if you set them on fire.

If you want efficiency and performance - fine but that comes from an over all business process. In fact, I'll go so far as to say the area generally with the best performance - is the dev team in most shops. Where performance can generally be improved the most is in the planning and design phases of projects where poor requirements gathering and documentation leads to endless wasted meetings.

posted November 6, 2007

Jeff Atwood has summarized it in a nice post titled "The Programmer's Bill of Rights". This come in addition to the famous "Joel's Test". Combining information from these two essays, then doing all what you can to actually implement their suggestions should neatly improve your team's performances.

Links:

• http://www.codinghorror.com/blog/archives/000666.html
• http://www.joelonsoftware.com/printerFriendly/articles/fog0000000043.html

posted November 7, 2007

"Monotasking", working full-time on one thing at a time. Cost: zero. Benefit: huge.

Jerry Weinberg suggests a rule of thumb for the cost of programmer multitasking. If you work on one thing at a time (all your tasks relate to a single project), you have a baseline productivity - 100% by definition. Working on two projects, 40% of your productive time is spent on each, 20% is overhead. Three projects, 20% for each and 40% of overhead. Four projects, you're down to 10% productive time per project. At five and beyond, you're lucky to get anything done at all.

posted November 7, 2007

An office with a door that closes.

posted November 7, 2007

Wherever you are, get a professional writer on your team who has worked with developers and can take over the documentation. When a developer leaves, you want the next person to step right in and start going without a lot of babysitting--the more you have written down, the better. When it's time to create a user manual for the product, you want your developers to be developing, not writing. When your client gets the product, you don't want them to distract developers by demanding personal help--that's why you want a clear, accurate user manual written by a professional writer. When it's time to market the product, you don't want your developers tied up explaining what it is they developed. And all along the process, you want someone who actually likes to communicate in writing on your team because people tend to "forget" the results of a meeting if everything is oral. You can contract with a writer for the length of a project so you don't have to hire someone permanently.

posted November 7, 2007

As you can see there are some common threads in the answers so far. Basically you need to keep them happy. This can come with better equipment, training, tools, etc. Also, letting the developers have research and development time goes a long way. Let them play around with new technologies a little each week serves two purposes. One, it makes them happy, and two, they find better and faster ways to do things. One of the worse things you can do is load them up with so much work they can't ever learn anything new.

Another thread here is they need to work without being distracted. This can happen in a variety of ways but one way I've found is to have good project management and team management to avoid shoulder tapping and to be a buffer from the many daily interruptions. It takes developers 30-45 minutes to pick back up where they left off if they are deep into a difficult problem and get interrupted.

posted November 7, 2007

As a developer what increases my productivity is:
-Multiple monitors
-Good Keyboard
-Good Chair
-Work from home
-Working with the IDE I'm more familiar with
-Not being involved issues that are not related with the project
-Salary: I hate to ask for a rise, I rather change the company. When I'm not happy with the salary I think more on that than on the job that I have to do.

posted November 7, 2007

Software development performance is actually a topic unto itself. I define performance for software developers as the ability to solve problems that they are given in a time that is appropriate to the problem.

1. Hardware (5-10%)- Actually hardware in my opinion has minimal impact on developer performance in that one high-end PC does not have much impact on someone that is not that productive to begin with. I would say that they top performers in a group should have the best development hardware, but sadly this usually is not the case.

2. Training (5-8%): Developer training on a specific set of tools or technology can greatly improve productivity in some, and will not help with others. You should evaluate who would benefit from training and who would not. Developers like to go to training, and it can be a valuable tool to wring performance out of individuals.

3. Process (2-5%)- Bug Tracking, etc. can help, but it can also create problems if done in a small team. Create a paper process first, then see if you actually need bug tracking. Typically you should have a development process if you have a group larger than 3 people. Also, if you have groups of 3 people where 1 individual is responsible for communication it can work without a "tool" as well.

4. Source control (1-5%) - May not be much of an advantage although most people would think it's essential for development. If you have groups of less than 3 people developing a system source control can be more trouble than it is worth untill the system needs to be delivered. In my opinion though for other reasons Source Control is essential for the sanity of a development team not matter the size.

5. Tools (5-20%) - Depending on the platform tools can bring productivity to the next level. For instance if you are in a Java environment and you are using an old version of JBuilder (8 for instance) and you are trying to build lot's of EJB's this is not the correct tool. Most of the tools available in Java are very in-expensive and can improve productivity by auto-generating code, and offering analysis tools that will find problems before the code is deployed.

5. Productivity Frameworks - After your team is trained it can improve productivity 5-20% because they will focus on implementing business functionality instead of infrastructure. One such Framework is Spring.

posted November 7, 2007

try reading steve mconnel's book rappid softwrere development he summarises a lot of the ways you can improve programer performance

from memory private offices where worth about 10-15%

i would add a decent double or triple screen set up (code ide, main, sql dev)

Links:

• http://stevemcconnell.com/

posted November 8, 2007

The statement "improvements, which can be bought easily (like PC or tools)." is interesting. Are you asking this because this is a realm over which you have some control, and organizational change isn't, or because of a desire for some 'magic pixie dust' to sprinkle over the development team, and wait for the incredible and inexorable results to spring forth?

All of the suggestions I've read are good ones. However, in my experience, the material ones (Belchfire X-5 googleHz PCs, Aeron chairs, whiteboards, refreshing beverages, etc., etc.) are no-brainers, and should be implemented as budgeting allows.

Software is a human activity. Real performance comes from improving the human systems. There are case studies that show Scrum can improve productivity by 50%, and XP practices another 25% or so more. Good management is key. Doors (and much more importantly, the ability to close them) improve individual code productivity and quality, but have been shown to result in more integration effort. Open space tends to do the opposite. Are you interested in individual developer performance (however you metricize that) or overall delivered software performance improvement?

Tooling is necessary, but not sufficient, for significant software development performance.

posted November 8, 2007

I think we should turn our attention to how we can improve the productivity of a company as a whole. Too many improvements efforts are focused on R&D in isolation but we need to "Optimize the whole" in order to capitalize on our improvement efforts. I think that the productivity of a development team is directly correlated with other areas in a company, but these dependencies are often over-looked when management decides that we need to improve our productivity. We need to look at the whole value chain, from the time a feature request is received by a sales representative to the time when we rollout the new solution at a customers site and we should strive to improve that lead time.

I prefer to run development projects with a lean approach. As a project framework we use e.g. Scrum and then we add the engineering practices from XP e.g. TDD, unit testing, continuous integration, automated testing etc. In parallell with the development project we coach management and other departments in lean thinking and ways of working.

This way of working gives us several benefits that will improve the productivity of the whole company:
- A dedicated team, no more multitasking.
- Crossfunctional team, no more handovers.
- Prioritized backlog of features, no more scope creep or change control board meetings.
- Timeboxed iterations, no more slipping dates.
- Focus on delivered (potentially shippable) business value in every iterations, no more inventory of 90% done features.
- One product owner who owns the product and make sure that we keep focused
- A realistic status of how the project really is going by the use of taskboards, burndown charts, daily scrum etc.
- Improving lead time
...

This lean and systems-thinking approach improves the performance of the development team and the company as a whole. I think that once you have fulfilled the basic needs of a development team e.g. PC:s, IDE, SCM etc, the way to achieve great productivity is in the ways of working, throughout the whole company!

Best regards,

Martin

posted November 12, 2007

I spent some time thinking about this, read Peopleware and Rapid Development, and I've come to the conclusion that there's a limited number of things you can do to improve the performance of programmers individually.

Programmers have a set amount of code they can write all day, every day. You can produce more code by applying pressure and working more hours, but the increase is temporary. Two weeks of overtime will cause degraded performance, and you'll get an "underwork" factor following the overtime as people recover.

I wrote more about this on my blog here:

http://tersesystems.com/post/by_id/9700070

However, there's much more that can be done to improve performance of a development team. Individual practices may not help all that much, but team and department practices have been known to more than double productivity. What techniques to pick will depend on your team and your comfort level, but they can (and have) reaped dividends.

Probably the simplest, fastest thing you can do for an improvement is buy large monitors. There have been a number of studies that show that large monitors decrease the "context switching" required to find an item. Compared to the cost of a full time programmer, they are very cheap.

Links:

• http://tersesystems.com/post/by_id/9700070

posted November 12, 2007