Coding on a team of developers is challenging. You've got different coding styles, different personalities, different strengths, and different weaknesses. Aligning all of the team members together can be extremely difficult, and can result in some pretty amazing things when you get it right. But it also results in higher expectations for the future. If you over deliver, you're expected to do the same in the future.
Here's how to make sure that doesn't happen:
- Treat members of your team differently. Only allow certain members of your team to work remotely. If a team member is used to working remotely from previous employment, make sure that he is required to do all of his work at the office. This ensures that he puts in only eight hours a day and can't maintain focus on projects during off hours.
- Make sure there are plenty of interruptions in your developers' office. This is easy to do if you have a cubicle environment, since there is no way for any team member to find silence or privacy. If you do have offices, be sure to cram several developers in to an office. For even better results, make sure that developers that work on the same project do not share offices with each other. Best results can be achieved by seating developers with non-developers that have lots of phone calls and in-person discussions. Salespeople and customer service representatives are perfect for this. Cubicles provide yet another benefit in that they transfer vibration very well. One team member's finger drumming can completely disrupt concentration of others.
- Don't use source control. Allowing developers to use source control keeps them from stepping on each other's toes. It also keeps a record of changes so that the source of bugs and regressions can be found.
- Avoid unit testing. Unit testing helps avoid functionality regressions and new bugs. While it seems that doubling the amount of code developers write would be good for destroying productivity, the gains that come from good unit testing should be avoided. However, you can still impede productivity by halfway using unit testing. This means having one team member write and maintain unit tests for the entire team. Other team members should never run the unit tests.
- Develop an in-house coding standard different from all other coding standards for the language you program in. This ensures that automated code formatting and linting tools are at best difficult for the team to use.
- Ignore established testing and design patterns. Using common idioms makes it easier for developers to keep everything in their head.
- Think about using one of the new software design methodologies. Agile and scrum are very popular for development teams. You should think about using them, maybe have some meetings to discuss the concepts and benefits. Under no circumstances should you actually try them. It is relatively easy to find excuses not to use them.
- Switching the task that individual members of your team are working on helps them to be more well-rounded developers. Allowing them a sufficient block of time to finish a project would only let them gain satisfaction in some finished code. For best results, constantly switch their top priority so developers leave a long line of half finished projects in their wake.
- Make sure that developers do not have adequate machines to do their work. Developers like to have many applications open at any given time. They should have to shutdown Eclipse to load Photoshop for example.
- Impose restrictions on the tools that developers use. Developers get used to using certain programs. Require all developers on your team to use Emacs, or Vim, or Eclipse, or Netbeans. This is also a great way to kill some productive time by arguing about which development environment the team should use.
- Have lots of meetings spread throughout the day. Meetings are a great time sink. In addition to the time actually spent in the meeting, developers may have to prepare for the meeting. To amplify the effect of your meetings, make sure they are spread throughout the day. Developers work best in large blocks of time. So instead of putting all of your meetings in one contiguous morning block, spread them throughout the day so developers will have 45 minute pieces of development after taking in to account commuting to/from meetings, replenishing caffeine, and using the restroom.
Do you have any other ways to subtly impede the productivity of developers?
No comments:
Post a Comment