Bushido of Software Development

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.

  1. 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);
  2. Continuous integration. Running integration testing at least daily;
  3. All developers (of all sub-teams) on the project can communicate with each other directly (not only though representative person);
  4. Adequate number of developers on the project (not too small and not too much);
  5. Adequate volume of design documentation (again not too small and not too much);
  6. Design documentation must be readable, illustrative, brief, well-structured and clear; 
  7. Developers must have adequate hardware and software to develop software;
  8. Team must have at least one development server to have development version of software, DB, continuous integration there;
  9. Team must have mock-ups (separate DB) for continuous integration;
  10. Team must use source-control system, all sub-teams of the team must integrate with code in the source control at least daily;
  11. Team must have development infrastructure. Such as wiki, project management and bug-tracking software, etc.;
  12. 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.

Advertisements

Author: Artem's Blog

Working on software and more...

2 thoughts on “Bushido of Software Development”

  1. Artem, based on your own level of experience and development life cycles,
    what type of documents would you consider to be enough to constitute design phase in the software development life cycle?

    One of the main roles that many companies miss is Business Analysts. It is not in the main interest of the developers to do the jobs of Business Analysts. B.A.s should be the ones gathering all the requirements and meeting up with clients to discuss what needs to be done. The Developers will answer the main question: How things are going to be done and accomplished

    Source control: From my own experience, don’t use Subversion as a source control utility since it is very difficult to manage MERGING of branches into trunk and out due to the fact that merge integrates all the lines. When this happens, our team usually ends up with buggy code due to the inclusions of the source code from different teams and noone knows for sure which lines don’t need to be in the main source code…so we end up with redevelopment of the same….

    Team Foundation is a better choice to go about this.

    For Business Analyst: Please do create Screen Shots of what needs to be accomplished and presented from the client. This is very important. Screen Shot is the key to visual representation of what needs to happen.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s