12 Must Have in Software Development
Just a minimal simple set or rules and approaches, which, I believe, help projects to succeed. Most of software developers will say that it is something like “must have” on your project and, of course, it is not complete set. Since each complete set is a process and you can always chose the most suitable process for you.
- Unit and integration testing full or most code coverage (of course, you don’t have to test your DTOs or VOs if they don’t have any business logic inside);
- Continuous integration. Running integration testing at least daily;
- All developers (of all sub-teams) on the project can communicate with each other directly (not only though representative person);
- Adequate number of developers on the project (not too small and not too much);
- Adequate volume of design documentation (again not too small and not too much);
- Design documentation must be readable, illustrative, brief, well-structured and clear;
- Developers must have adequate hardware and software to develop software;
- Team must have at least one development server to have development version of software, DB, continuous integration there;
- Team must have mock-ups (separate DB) for continuous integration;
- Team must use source-control system, all sub-teams of the team must integrate with code in the source control at least daily;
- Team must have development infrastructure. Such as wiki, project management and bug-tracking software, etc.;
- Automate everything you can.
Unit and integration testing full or most code coverage
It will let developers be sure that their code is functioning OK. More of that, it let them to to check if some part is OK without re-testing whole application.
Continuous integration
Imagine, some developer changed behavior of her/his module and updated his unit tests. Her/his unit tests works fine, but some other, dependent part could be broken.
Continuous integration allows developers to know if there are hidden problems in their application.
All developers on the project can communicate with each other directly
Don’t let absence of communication to become bottleneck of your process. If one developer has question and/or misunderstanding regarding some part of other developer’s work, communicating though contact person could delay delivery date of your project. Or even worse: communication person could transfer information incorrectly.
Adequate number of developers on the project
No need to tell you what happens if there not enough developers on the project. The surprising problem could happen if you took too many developers:
they will face all integration issues. Sometimes small teams could perform better than big ones. The one more issue about big teams is non-uniformity of the application
design. Not all developers have the same level and not all people have the same approaches.
Adequate volume of design documentation
It is simple. Nobody will read bad-structured huge design documents. On the other hands something should stay in-written to reflect common parts, possible misunderstandings,
etc.
Design documentation must be readable, illustrative, brief, well-structured and clear
If it not readable obviously nobody will read it. Non-illustrative documentation hard to process and developers could miss something. Why should it be brief is discussed in
previous section. In badly structured document hard to find information you need, so such documents become useless.
Developers must have adequate hardware and software to develop software
Just not fast enough hardware will simply delay your project. Do you need it? Usually the biggest expense is developers themselves. So it is very improvidently to spend
their time for waiting while program is compiled. The same idea is about software. Just let your developers work more effectively.
Team must have at least one development server to have development version of software, DB, continuous integration there
By word “server” you can understand some computer. They are not so expensive nowadays.
Team must have mock-ups (separate DB) for continuous integration
Don’t let changes in your development DB break your unit-testing. It is not such a big deal to maintain 1 more DB for testing.
Just let your developers play in development DB (or DB on their PCs) and put only what you need for testing to test DB.
Your continuous integration will hardly work well without it.
Team must use source-control system, all sub-teams of the team must integrate with code in the source control at least daily
I can’t imagine a project without source control. I’m sure everyone does the same. The issue can be, for example, if you have one team in
closed proprietary network (say, writing business logic) and one outside (say for presentation layer development). Sometimes both teams
can’t use the same source-control for various reasons, but at least in one of teams should integrate with others frequently (they can put
other team’s code in their source control. Even this process can usually be automated.).
Team must have development infrastructure. Such as wiki, project management and bug-tracking software, etc.
Don’t make your developers search their emails for some important information. Just set up wiki. Your developers are still write
their tasks on pieces of paper? How do you plan to manage it? Use software to develop software.
Automate everything you can
Compilation, deployment, integration with other source controls, sometimes even code-generation, etc. Usually you already have to do much for continuous integration. You can even chose dedicated person for this task if your team is big enough. Save costy time of your developers.
Artem's Blog 