Working as a team
A project is not accomplished by only one person and in this chapter we focus in the many individuals that are directly related to the development of code, that is the working project team. The idea of the pragmatic programmer behind the pragmatic project is about to make the team a pragmatic team, by expanding the universe of action of pragmatism we now have a functional unit of people willing to cooperate for the sake of good programming.
As your project gets under way, we need to move away from issues of individual philosophy and coding to talk about larger, project-sized issues. We aren’t going to go into specifics of project management, but we will talk about a handful of critical areas that can make or break any project.
As soon as you have more than one person working on a project, you need to establish some ground rules and delegate parts of the project accordingly. In Pragmatic Teams, we’ll show how to do this while honoring the pragmatic philosophy.
When working on a team you must look up at the team while looking for broken windows, make your code clean and good to avoid this, and keep the communication about what is happening with the project in a pragmatic team people are looking for a meeting to keep in touch communication with the team is very important and helps to take more important decisions.
Testing is by no means an easy task, there is quality to be maintained and many things to keep in consideration when doing this, the testing is the part of the project where we look forward to the quality guide lines and go outside to look up defects in the code.
We need testing because programmers are unable to create bug free software.
There are several major types of software testing that you need to perform:
- Unit testing
- Integration testing
- Validation and verification
- Resource exhaustion, errors and recovery
- Performance testing
- Usability testing
Comment your code.
Pragmatic Programmers embrace documentation as an integral part of the overall development process. Writing documentation can be made easier by not duplicating effort or wasting time, and by keeping documentation close at hand—in the code itself, if possible.
There are basically two kinds of documentation produced for a project: internal and external. Internal documentation includes source code comments, design and test documents, and so on. External documentation is anything shipped or published to the outside world, such as user manuals. But regardless of the intended audience, or the role of the writer (developer or technical writer), all documentation is a mirror of the code. If there’s a discrepancy, the code is what matters—for better or worse.
Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can’t be documented anywhere else: engineering trade-offs, why decisions were made, what other alternatives were discarded, and so on.
Going back to the expectations of the client and the characteristics of the project, the users want something that can solve all of their needs and we as developers want to deliver but sometimes we deliver more than is required be weary of that.
In reality, the success of a project is measured by how well it meets the expectations of its users. A project that falls below their expectations is deemed a failure, no matter how good the deliverable is in absolute terms. However, like the parent of the child expecting the cheap doll, go too far and you’ll be a failure, too.