That crazy plugin was one of the most annoying pieces of software ever... I'm glad it's gone. Who really wanted every phone number on every site clickable into skype... Very happy FF did this. Now they need to prevent auto installs of plugins...
Changing someones development practices is a kin to changing any other behavior, I.E. hard to do.
I've found that code reviews offer a good barometer of where everyone is on the behavior chart but it is not enough to make a significant change to the behavior.
Here are few items that I find essential: 1) Maintainability Must be a priority: The architect\tech lead on the project must make this a priority. Simple code must be reinforced at all stages of development. This means new development must wait for previous development to be refactored into simpler code.
2) Shared understanding: The team MUST recognize the importance of this requirement. If they don't then the constant reinforcement will seem more like nagging, nit-picking than anything else. Have the entire team read "Clean Code" send out the Daily WTF articles. Jokingly pass out the bad code offsets.
3) One on One Coaching: Often complicated code is written simply because the simpler solution was not obvious. To help overcome this, team members should help each other with refactoring efforts. As an example: Interfaces and factories are often seen as "To complex to be simple" by junior developers. Consequently, it is the responsibility of the entire team to help teach why these "more complicated" solutions are actually much simpler and cleaner than the alternative.
4) Constant Communication: As with all creative work, whether you've accomplished the goal is very subjective. This means the team must have constant discussion, and sometimes debates, on what is maintainable. If you are the tech lead, be sure to show examples of your own code that is sub-par, and then discuss how it can be improved. If you don't have samples of sub-par code, you need to start writing more code. I can't emphasize enough that the tech lead must use their own bad code as examples, this helps create an open environment where people feel free to make mistakes and ultimately learn how to write better code.
Well that's my two cents as I sit here getting ready for Football to start. (c:
Slashdot Mirror
That crazy plugin was one of the most annoying pieces of software ever... I'm glad it's gone. Who really wanted every phone number on every site clickable into skype... Very happy FF did this. Now they need to prevent auto installs of plugins...
Changing someones development practices is a kin to changing any other behavior, I.E. hard to do.
I've found that code reviews offer a good barometer of where everyone is on the behavior chart but it is not enough to make a significant change to the behavior.
Here are few items that I find essential:
1) Maintainability Must be a priority: The architect\tech lead on the project must make this a priority. Simple code must be reinforced at all stages of development. This means new development must wait for previous development to be refactored into simpler code.
2) Shared understanding: The team MUST recognize the importance of this requirement. If they don't then the constant reinforcement will seem more like nagging, nit-picking than anything else. Have the entire team read "Clean Code" send out the Daily WTF articles. Jokingly pass out the bad code offsets.
3) One on One Coaching: Often complicated code is written simply because the simpler solution was not obvious. To help overcome this, team members should help each other with refactoring efforts. As an example: Interfaces and factories are often seen as "To complex to be simple" by junior developers. Consequently, it is the responsibility of the entire team to help teach why these "more complicated" solutions are actually much simpler and cleaner than the alternative.
4) Constant Communication: As with all creative work, whether you've accomplished the goal is very subjective. This means the team must have constant discussion, and sometimes debates, on what is maintainable. If you are the tech lead, be sure to show examples of your own code that is sub-par, and then discuss how it can be improved. If you don't have samples of sub-par code, you need to start writing more code. I can't emphasize enough that the tech lead must use their own bad code as examples, this helps create an open environment where people feel free to make mistakes and ultimately learn how to write better code.
Well that's my two cents as I sit here getting ready for Football to start. (c: