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
Apollo program software minutes before deployment

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.

Great expectations.

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.


Give what the client desires.



Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15 (2000).

5 minutes until midnight.


This is the part of the proyect where we find again that the proyect basics must be stablished before the proyect even begins,  determine the requiremets, AKA listening the user is not enought, is one of the basics the proyects need in the planning stage, and requiremets is one of the biggest parts of the proyect because as the experience of the many proyect managers that have been to our class have pointed out, requirements are at the mercy of the imagination of the client.


What a fantastic show


Many books seem to imply that the requirements are already there the moment you aproach the user to request them, the reality of the requirements and what is important to understand is that they are hidden beneath the ground.

Requirement : A statement of something that needs to be accomplished. Good requirements might include the follow.

  • An employee record may be viewed only by a nominatd group of people.
  • The cylinder-head temperature must not exceed the cirtical value, which varies by engine.
  • The editor will highlight keywords, which will be selected depending on the type of file being edited.

The first statement in the list above may have been stated by the users as “Only an employee’s supervisors and the personnel department may view that employee’s records.” Is this statement truly a requirement? Perhaps today, but it embeds business policy in an absolute statement. Policies change regularly, so we probably don’t want to hardwire them into our requirements. Our recommendation is to document these policies separately from the requirement, and hyperlink the two.

Abstractions Live Longer than Details

One very important thing to take into account when we make the system is that the user interface is as important as the system itself, we cannot create a system that is not addecuate for the user, every complex interfaces or non intuitive interfaces have the same problem, is that the functionality is of the system is not exploited by the user because he does not recognize with ease what is in front of him. Make easy to understand interfaces, make contact with the user and see what its currently using to know what he can use later.

In the current years it is imposible for Y2K problem to exist, vast amounts of memory are available and history has shown the damage such problems may cause.


How hard is your puzzle.

The popular buzz-phrase “thinking outside the box” encourages us to recognize constraints that might not be applicable and to ignore them. But this phrase isn’t entirely accurate. If the “box” is the boundary of constraints and conditions, then the trick is to find the box, which may be considerably larger than you think.

The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you’ll find your solution. This is why some puzzles are so effective; you may dismiss potential solutions too readily.


can you connect all of the dots in the following puzzle and return to the starting point with just three straight lines—without lifting your pen from the paper or retracing your steps ?


Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15

While you are coding.

Chapter 6. Common knowledge with programming is once the codding part beggins is all about the keyboard the machine and the programmer, in reality programming is another kind of communication, and communications requieres understanding, being careful with what you do, and knowing what you do, what it does and why it does that, otherway we may end up coding by concidence.

rglfizfThat sweet sweet corsair K70 will have to wait until after proper colaboration with the testing team is stablished.

The programmers need to know the algorithm speed of the methods they created, most nontrivial  algorithms handle some kind of variable input. Normally the size of this input will affect the algorithm: the larger the input, the longer the running time or the more memory used.

More significant algorithms are not linear. The good news is that many are sublinear. A binary search, for example, doesn’t need to look at every candidate when finding a match. The bad news is that other algorithms are considerably worse than linear; runtimes or memory requirements increase fer faster than n. An algorithm that takes a minute to precess ten items may take a lifetime to process 100.

xw539eaRobbie Rotten finds out the intern name selection bubble sort.

Moving forth and afar from the diferent kinds of algoriths that may take another post or two to talk about. The next thing we need to take into account when coding is the refactoring. Refactoring the action of reviewing the code and modifing the code in order to make it more organic and natural the the solution in question. Clearly refactoring is an activity that needs to be undertaken slowly, deliberately and carefully.

Testing against contract

We like to think of unit testing as testing against contract. We want to write test cases that ensure that a given unit honors its contract. This will tell us two things: whether the code meet the contract, and whether the contract means what we think it means. We want to test that the module delivers the functionality it promises, over a wide range of test cases and boundary conditions.

What does this mean in practice? Let’s look at the square root routine.

    argument >=0;
    ((result * result) - argument).abs <= epsilon * argument;

this tells us what to test:

  • Pass in a negative argument and ensure that is rejected.
  • Pass in an argument of zero to ensure that it is accepted.
  • Pass in values between zero and the maximum expressible argument and verify that the defference between the square of the result and the original argument is less than some small fraction of the argument.

This style of testing requires you to test subcomponents of a module first. Once the subcomponents have been verified, then the module itself can be tested.


Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15

Bend or break

This is about chapter 5 in The pragmatic programmer. The job of  a programmer is always evolving, new things come out everyday, many new frameworks come and go and that applies to many areas of programming, web programming is affected the most because the nature of how the INTERNET moves. In this chapter we dedicate some time to the best practices to keep your programs flexible and maintainable.


keeping a cake shop is not as bad of an idea now we envy you Stephany.

The Law of Demeter for Functions

attempts to minimize coupling between modules in any given program. It tries to prevent you from reaching into an object to gain access to a third object’s of demeter

Dynamic configuration

Use metadata to describe configuration options for an application: tuning parameters, user preferences, the installation directory, and so on.

We use the term in its broadest sense. Metadata is any data that describes the application—how it should run, what resources it should use, and so on. Typically, metadata is accessed and used at runtime, not at compile time. You use metadata all the time—at least your programs do. Suppose you click on an option to hide the toolbar on your Web browser. The browser will store that preference, as metadata, in some sort of internal database.



McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

You are (not) perfect

Everyone knows that they personally are the only good driver on Earth. Well its the same with codding, we go around making sure everything is perfect when we have in hand the code of another person. And pragmatism is about taking this one step further, to not trust ourself. We know that no one makes perfect code, including ourselves. Ahead well find some measures to protect ourself from what software we create.

Design by contract is about focusing in the documentation and the rights and responsibilities of software modules to ensure program correctness. Correctness is something that does what it claims to do?

Every function and method in a software system does something. Before it starts that something, the routine havve some expectation of the state of the world, and it may be able to make statement about the state of the world when it concludes. These are.

Preconditions. What must be true in order for the routine to be called; the routine’s requirements.

Postcondition. What the routine is guaranteed to do; the state of the world when the routine is done. The fact that the routine has postcondition implies that it will conclude: infinite loops aren’t allowed.

Class invariants. A class ensures that this condition is always true from the perspective of a caller.

The contract between a routine and any potential caller can thus be read as

If all the routine’s preconditions are met by the caller, the routine shall guarantee that all postconditions and invariants will be true when it completes.

All errors give you information. You could convince yourself that the error can’t happen, and choose to ignore it. Instead, Pragmatic Programmers tell themselves that if there is an error, something very, very bad has happened.

Tip 32
Crash Early


with style

One of the benefits of detecting problems as soon as you can is that you can crash earlier. And many times, crashing your program is the best thing you can do. The alternative may be to continue, writing corrupted data to some vital database or commanding the washing machine into its twentieth consecutive spin cycle.



Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15

How to handle programming tools.

Many are the tools that have been created by programmers for programmers, we tend to have very specific tastes when it come to languages, paradigms, text editors and IDES that it is hard to track the really useful tools. But after reading this chapter I can deduct that there are some tools that never get old, vi, emacs, are the ones that stand the curse of time the better, but there are also new tools that are worth mention. For example atom, and sublime text can be very powerful on their own and can handle many kinds of language while keeping the simple plain text for everyone to use, even better atom already comes with source code control integrated in the form of github. Github tracks the files you are working on and  keeps track of the changes you make to said files. pgcif7h


Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15

Pragmatic approach

Welcome to my views and thoughts regarding episode 2 of the fantastic book “the pragmatic programmer”, in which a hope to share some of the already digested insight from this chapter. The main focus of this chapter is the aproach to solutions in the development plan of a project and it starts by discusing the advantages that a well though project can avoid the duplicate problem. Inside a software project information can tend to duplicate itself for many reasons, some of this reasons are.

  • Imposed duplication. Developers feel they have no choice, the environment seems to require duplication.
  • Inadvertent duplication. Developers don’t realize that they are duplication information.
  • Impatient duplication. Developers get lazy and duplicate because it seems easier.
  • Interdev eloper duplication. Multiple people on a team duplicates a piece of information.

And also, speaks about the project orthogonality, a concept taken from geometry that implies independence from code module to module or from person to person, good orthogonality can be applied even outside the programming concept. In every day’s work the orthogonality is reflected on the lack of information repetition. The advantages of this are many, but it is simplified in code reuse and little modifications in case of need of more features. On the other hand, projects that lack orthogonality are those that are really chaotic, adding new button in the AI needs the whole architecture to take a new approach.

spxwmpsThe fact this thing can fly is pure coincidence.

Reversibility is about the simple solutions, how the simple solution is not always the desired one and how we the developers must be looking at the bigger picture. Is our project likely to be client based or server-client? even if we don’t know yet (or even if we know) we must consider that the specifications and the marketing team can change the rules of the software by the night, so is better to rest prepared than to fall back to square 1.

Last but not less estimations, estimating is the art of making numbers out of activities that are to be executed in the plan, the one very important skill I take from this activity is to ask another person who has done something similar to you and to know where he took the longest time.



Hunt, Andrew, and David Thomas. “The Pragmatic Programmer.” Addison Wesley 15