Apollo 11

In todays class we talked about creative commons and reserved rights. The system responsible for the first moon landing is now readily available online, after an enterprising former NASA intern uploaded the Apollo Guidance Computer code to Github this week.

When programmers at the MIT Instrumentation Laboratory set out to develop the flight software for the Apollo 11 space program in the mid-1960s, the necessary technology did not exist. They had to invent it.

They came up with a new way to store computer programs, called “rope memory,” and created a special version of the assembly programming language. Assembly itself is obscure to many of today’s programmers






During construction, the successful project teambecomes increasinglyvigilantabout findingways to make the software simpler and to control changes to it. Progress will be highly visible as the project manager monitors key progress indicators, including miniature milestones, defects, the top 10 risks list, and the system itself.

Coding standards

The goal of a Coding Standard is to make the whole program look more like a blanket made of a single material than a patchwork quilt made of mismatched scraps. The Coding Standard typically addresses several areas :

  • Layout of classes, modules, routines, and code within routines
  • Commenting of classes, modules, routines, and code within
  • routines
  • Variable names
  • Function names, including names for common operations such
    as getting and setting values within a class or module
  • Maximum length of a routine in lines of source code
  • Maximum number of routines within a class
  • Degree of complexity allowed, including restrictions on the use
    of the Goto statement, logical tests, loop nesting, and so on
  • Code-level enforcements of architectural standards for memory
    management, error processing, string storage, and so on
  • Versions of tools and libraries to be used

Proyect objectives

As they did during detailed design, developers should continue looking for ways to optimize the project goals during construction. Construction presents many opportunities to make the project simpler or more complex, more robust or more fragile, more nimble or more ponderous.

Software integration procedure

This consists of the many processes that need to be done before we are sure that a process in the program is complete


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

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

Detailed design


Chapter 13. The detailed design activity during each stage extends the design work begun during architecture addressing many of the same issues but in more detail. The amount of detailed design work required depends on the project’s size and the developers expertise.

Architecture revisited.

During the detailed design, the development team will work in several design areas that were first explored during the architecture phase.

Program organization: at detailed design time, they are concerned with the programs organization at the class and runtime level.

Reuse analysis: Developers again investigate the possibility of reusing existing components and commercially available components in their design, but this time that investigation will explore reuse at a more detailed level.

Requirements resolution: Any requirements affecting a particular staged release must be resolved during detailed design phase of that release.

How much detailed design does a project need?

The omount of design work and the formality of that work depend on two factors: the expertise of the project’s developers and the difficulty of the project.

When the project has expert developers and is a simple project, the detailed desing work can be informal. Design work can proceed


Senior developer Stephanie ready to show the new interns at IBM north campus how to properly apply a lambda function

Successful projects look for ways to trade small increases in overhead for large decreases in project risk, and adding formality to design process is a classic what to do that.



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

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

Stage planning

Chapter 12

Stage planning is where we map out the detailed course of action for a stage to be permermed at the start of each stage delivery cycle. The project team creates an individual stage plan that describes how to conduct detailed design, coding, technical reviews, tests, integration and other activities during the stage. The most labor intensive planning activity is the creation of a list of miniature milestones, which helps the team track progress throughout the stage.

Each stage in a project using the staged delivery approach is essentially a miniature project.


Squidward with the rest of the sponge bob squarepants staff ready to begin stage planning. Colorized circa 1999.

  • Stage planning is a taxiing task, we want to make milestones for the next activities.
    • Requirements updates. in the early stages requirements to be implemented during the stages should be exactly what the project team specified during prototyping and requirements development. Later time should be allocated at the beginning of each stage to evaluate possible changes to requirements.
    • Detailed design. This is to be done near the beginning of each stage, developers flesh out the detailed design.
    • Construction.
    • Test case creation. This is to be created at the same time that the developers are working on a stages construction.
    • User documentation updates. The user manual/requirements specification is updated to describe the as-build software.
    • Technical reviews. This begin in earnest during the post-architecture period.
    • Defect corrections. Developers correct the defects uncovered by testing and reviews.
    • Technical reviews. 
    • Technical coordination. Meetings between developers, testers and architecture designers.
    • Risk management. The project manager should review the project current top 10 risks list and determinate whether the current project plan adequately addresses the current risk.
    • Project tracking.
    • Integration.


Tired yet? Have a picture of a cute doggo.

In addition to their project tracking benefit, miniature milestones help the team to focus on the most important tasks. When only long-term milestones are used. the developers can easily lose a day here or a week there people spend time on detours that seem interesting or productive in some vague sense but fail to move the project forward.

How does a project get to be a year late?… One day at a time.

Frederick P. Brooks.

To close this chapter I would like to add that all of this planning is a warning for the future of the release of the project to always documents the milestones and document the ones that have been reached. If we do as follow future can’t stop us.yvvy86j

Squidward dealing with the humans inner fears. 


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

Final countdown

Chapter 11 of software project survival guide. The fianl preparations period build on and extends the preliminary planning that was performed before the requirements development and architecture pass. At final preparations time, the project team is ready to create its forst estimate develop a plan to deliver its most important fuctionality and refine its other plans.

Project estimates.

As soon as requirements have been baselined, the project team can create meaningful estimates for effort, cost, and schedule. Keep these rules of thumb about software estimation in mind.

  • Its possible to estimate software projects accurately.
  • Accurate estimates take time.
  • Accurate estimates requieree a qualitative apporach, preferable one supported by a software estimate tool.
  • The most accurate estimate are based on data from projects completed by the organization doing the current project.
  • Estimates requiere refinement as the project progresses. jixfgqlProyect estimates.

Estimate procedure guidelines.

The estimation procedure should by written. Estimates should be created by an expert estimator or by the most expert development, quality assurance, and documentation staff available. Estimates should include time for all normal activities.

The project plan should not assume the team will will work overtime. If the project plan assumes that the team will work overtime the project won’t have any reserves to draw from. This is relevant to that project manager that came to visit us 2 weaks ago were he sead that programmers tend to be more cualitaty and that a programmer need to know can be achieved, if the programmer feels that the project is imposible to achieve then he will stop working properly.

Estimates should be based on data from completed projects. Or in case that you are starting in the business ask other people how much they used as a butget and start from there.


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


Chapter 10 of software project survival guide. Is about the architecture of the software. During the architecture phase the architecture team interaction among system into major subsystems, specifies all the interactions among subsystems, and documents the software top level technical plans.

Easing into architecture

Architectural work should start when requirements development is about 80 percent complete. Resolving 100 percent of the requirements before beginning architectural work usually isn’t possible without delaying the project. By the time 80 percent of the requirements are known, the project is on firm enough footing to support creation of software architecture.

Characteristics of a good architecture

  • System overview. Needs to describe the system in broad terms.
  • Conceptual integrity. When you look at the architecture, you should be pleased at how natural and easy the solution is. It shouldn’t look like the problem and the architecture are stuck together with duct  tape.
  • Subsystem and organization. Once you realize that the goal of architecture is to reduce complexity, it becomes clear that the architect must focus as much on what to leave out of the software as on what to put in.
  • Strive for minimalism, simplicity, and coverage of all of the requirements, and don’t worry too much about finding the best solution.


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

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 methods.law 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