- An agile approach is the best way for developers to feel comfortable.
- Even if Agile principles are partially on not at all applied, assign at least two people on every project; assign each developer on at least two projects over a longer period of time, but try to keep people on the same project until the current release is finished.
- Each piece of code should be considered for reuse, for every feature look if you already have something similar already developed.
- Think out of the specific context, a specific client need might be converted on a more generic approach serving at least another purpose or becoming a reusable platform.
- Great developers are creative but they still like conventions – brainstorm with the team to produce naming conventions and coding style (double objective, users are happy, the code is easier to understand and transferable).
- Ask developers to comment the code using recognized standards, and so to be able to automatically produce code documentation from comments.
- For core long-term platforms minimize third party tools (resist temptation of reuse existing tools), in the long run it is better to have everything under control; but for campaign agile development let users use the tools they like, they will be happy and willing to respect platforms’ less flexible rules.
- Have a clear schedule for team meetings – once a month (ex. First Thursday) lunch & learns, have everybody propose subjects and to vote to establish the schedule, have them present the subject; also have once a month a production meeting talking about projects, but also new technologies, reusable code, best practices.
- Have the team members evaluate their manager – I use the Google manager rating survey, also have team leads evaluate constantly the members.
- Experienced developers and architects tend to stick to proven ways of doing things, young programmers will always want to try the latest and greatest – you need both, let them discuss, argue, eat pizza, drink beers and come up with the solution, it’s important that everybody have a say.
- If you are able to implement an agile approach great; also consider using Joel test - 12 steps to better code:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
- Make tech leads write technical docs about each project during development – it is good for R&D (objectives, iterations, problems) but also for sharing knowledge.
- Use a wiki, let people decide of the structure, put everything there: configurations, tools, tips, ways of doing things, documentation, etc. Developers love doing this and although there is not much of a structure, it is still very useful.
- Use a versioning system for your applications, even for websites (major, minor, build, revision), everything will be easier to follow and the developers and again happy with organized stuff.
- In general, always think of having a double benefit from every initiative, of course, this is not always possible but having this mind set will certainly benefit you team and your clients in the long run.
Happy coding!
