Bashmohandes

Top 30 Software Engineering Practices

1. Use Good Source Control System.
• Avoid Microsoft Visual Source Safe (For Large Teams).
• If it has to be Microsoft, use Microsoft Team System.
• Subversion (SVN) is recommended.
2. Small teams from two developers to four developers
3. Use white boards to explain your points instead of meaningless hand signals
• If the white board data is important, you can take a picture of it.
• Write down the data to be attached with the picture.
4. Testers number should be 50% of team members in average.
5. Documentation.
• API documentation.
• User Manuals.
6. Specification should be clear and written by someone outside coding team.
• The (Specs Writer or owner) acts like a customer to the project team.
7. Releases should be scheduled in regular basis.
• Every month, Every couple of weeks … etc.
8. Use a good build server.
• Integrate unit-testing.
• Integrate unit test coverage.
• Integrate code analysis code (FxCop).
9. Code reviews on regular basis.
• If you have different teams, you can make every team reviews the other team’s code in presence of the other team.
• At least weekly.
• Code reviews should be maximum one hour/ review, if you need more time schedule another code review.
• The code review should make sure that last code review comments and advices were applied, before going through the review.
• Code review can start from Unit testing code and go deeper if required.
10. Unit testing using a good unit testing tool (Nunit, Junit … etc).
11. Code testing coverage should be at least %80 before accepting this code in production.
12. Performance analysis should be made at the end of each release cycle.
• Need for Speed sprint.
• Performance analysis results should be recorded for future comparisons.
13. Security and threat modeling should be at the end of each release cycle.
• Keep the basics applied during development (SQL Injection, URL encryption).
14. Use internal Bug tracking system.
• When reaching known zero bug base, beta release is ready for customer review.
• Bugs should have screenshots if applicable.
• If the bug has screenshot, another screenshot should be submitted when fixed.
15. Don’t repeat yourself
• Refactor your code and find the repeated pattern and deal with it in a good way
• Use code generators if applicable.
• Either write your own or buy third party tools
• Bugs knowledge base can be used to refer to similar known bugs
16. Design using design patterns, but don’t design with design patterns
• If a know design pattern is applicable use it, if not, don’t force your code to match the pattern.
17. Designs should be documented.
• UML class diagrams are useful
• Sequence Diagrams are useful in complicated scenarios, but not always.
18. Design meetings should be announced in advance, so everybody can have a vision of the design, instead of start thinking in the meeting.
19. In design meetings, minimum number of people is preferred.
20. Design meetings can be held before weekends
• Review the design in the first day after weekend.
• The weekend is a good mind rest period, this can be useful to find better alternatives for design parts.
21. Make sure that the design is keeping the specs in mind.
22. Prototype the design in QUICK & DIRTY mode.
• Just proof of concept, not a well written application.
• Put in mind that the prototype code is not going to be res-used or go into production.
• Prototype should be developed by a developer outside the design team
• The developer should use the Design Docs and Diagrams to write the prototype.
• If the design is not clear enough, the design phase should be revisited to rewrite the design document in a better way.
• If the design is huge, write prototype for each component , or related components to test different parts of designs.
23. Divide your system into smaller sub-systems
• Make it recursively until no logical smaller sub-systems can be found.
• Make your designs as LEGO as possible.
• LEGO is a good example of a black box that accepts inputs from other LEGO blocks, and produces outputs to other LEGO blocks.
24. Design each subsystem into classes
25. Make your classes as small as possible
26. Low to Medium Fan-out.
• Your class should not depend on a large number of classes
• Maximum number is seven other classes or less
27. High Fan-In.
• Your class should have high number of classes that use the class.
• This means that your code makes good use of utility classes.
28. Every developer is working inside a code bubble, so don’t blow it off every time you want to ask something, send a notice on a messenger or schedule a meeting in outlook, instead of shouting and calling by name.
29. Meetings can be recorded for reference.
• If the recording will make the developers act like idiots stop it.
30. Every month a small conference can be arranged inside for practicing presentation skills
• Conferences should be recorded and published.