Skip to main content

I program stuff, I hope fix yours. Hi, mi name is Luis Eduardo Vargas Victoria, I study Bachelor of Science in Computer Engeneering in Tecnologico de Monterrey Campus Guadalajara, I studied app developing for IOS, I love videogames I'm working on an idea, I love movies, series, books, hang out with friends and code. I make videos on youtube, I'm starting actually I had almost 2000 views and 60 subscribers, I have another channel where I have almost 20,000 views and almost 300 subscribers, I love all the stuff above and in this class I would like to learn so that way continue with my ideas in app development.


#TI2011 #PragmaticProgrammer

3 min read

Review of the 

Amazing programming book at first because it is very easy to read and it contains a lot of useful programming tips so that is exactly what all the coders need.

I agree with almost all the tips and many of them are obvious, I liked that the tips are not tied to any technology, so this makes them very general and understandable.


Here are some of the tips I get from reading this book:

·       If you have a badly written code try to fix it as soon as possible, if you don’t take the time to clean it up, the bad code can make you feel of not caring about code quality and you will end working with code that is poorly written and soon that code will spread all over your codebase without noticing.

·       If you release good software and usable early you can work together with your users on polishing it to make a perfect software because great software today is often better that perfect software a year form now.

·       Use your time to learn useful things that you don't know yet, and keep an eye on emerging technologies because that is the best investment of time you can make as a programmer.

·       When debugging step back and think of the things that could be the origin of the bug, and how the bug propagates through the entire program and always test it with relevant inputs, doing that you eliminate all the possible things that could cause the bug to appear, leaving you with the real cause.

·       Document your code at first the set of data that works on correctly and you document because any problem like crashing early is better than letting bad data flow through the whole program and instead of thinking that wrong data couldn't make it this far make sure it doesn't happen by documenting.

·       When faced with a problem always ask yourself: Why is this thing a problem? Does it have to be done this way? Does it have to be done at all? Answering those questions, you’ll get another look at the problem and find out if your constraints are the real ones.

·       Testing is very important, try to think of the cases that could break your code and test them. Test early, often and automatically because the earlier the bug is found the easier it is to fix so test, test and test. 


I recommend to read this because this are the tips that got me and maybe you'll find another tips that be useful to you so if you have the time to read it, do it


#TI2011 #MissionAccomplished

3 min read

Mission Accomplished

Review of Mission Accomplished

This volume is about what you did during the project it’s exactly what is says, history, the history of how you develop your project, this is useful for future projects because it is written to know in what you were stuck and how not to repeat that in the future.


Whether the project has been an awesome success or an awful failure, it was also a time to learn from what you experienced during that project and for the future to build a foundation for future successes.


You can also have project review meetings that can be valuable times for project members to discuss their insights candidly because everyone has a perspective on how the project outcome at the end, and those insights can be tremendously beneficial to the organization or future projects on the organization or in an individual way.


Here are some do’s and don’ts for developing a project from NASA, enjoy.



·       Empower project personnel

·       Minimize the bureaucracy

·       Define the requirements baseline, and manage changes to it

·       Take periodic snapshots of project health and progress, and replan when necessary

·       Re-estimate system size, effort, and schedules periodically

·       Define and manage phase transitions

·       Foster a team spirit

·       Start the project with a small senior staff



·       Don't let team members work in an unsystematic way

·       Don't set unreasonable goals

·       Don't implement changes without assessing their impact and obtaining approval of the change board

·       Don't gold-plate

·       Don't overstaff, especially early in the project

·       Don't assume that a schedule slip in the middle of a phase will be made up later

·       Don't relax standards in order to cut costs or shorten a schedule

·       Don't assume that a large amount of documentation ensures success

I hope you like to read my posts about the software project survival guide, it was amazing reading this I learn a lot and I hope my explanations of my point of view are the ones you need to understand the importance of the main topic of this book, thanks for your time.


#TI2011 #SucceedingByStages

3 min read

Succeeding By Stages

Review of Succeeding By Stages

This volume is about the stage planning these maps out a detailed course of action for each stage. Each stage in a project is like a miniature planning, this means that in each stage there is planning, design, construction, testing, and preparation for release. Software developers noticed that each stage is like a small project, that means that if you finish a stage (small project) is less risky to fail than a big project, but hey, at the end is finally the big project you’re making so yeah, mind-blowing.


Now I’m going to explain the stage planning activities, so yeah, as I told you in past blogs, planning is the key of success it makes everything easier, so let’s start…

 ·       Requirements updates, this are the same you specified during prototyping and requirements development the difference here is that you evaluate possible changes to requirements.

·       Detailed design supports the software construction that will be done during the stage.

·       Construction is when the developers code the software to be delivered during the stage.

·       Test case creation is when testers create the full set of test cases needed to test the functionality developed during the stage this can be done while construction is being develop.

·       User documentation updates is the User Manual/Requirements Specification that updates to describe the as built software.

·       Technical reviews are when developers participate in design and code reviews.

·       Defect corrections are when developers correct the defects uncovered by testing and reviews.

·       Technical coordination is when managers of large projects coordinate the activities of different groups of developers.

·       Risk management is when the project manager review the project's current Top 10 Risks List.

·       Project tracking is the tracking of completed activities this is the major management task during all stages.

·       Integration and release is when developers integrate the code for that release.

·       End-of-stage wrap-up is as simple as the title says.

In conclusion is just the plan that will lead each stage so as I always say, planning everything is the key to success and time saving, and many things you can avoid, so please take the time to plan so you won’t take more time during development.


#TI2011 #ChapterEleven

2 min read

Chapter Eleven

Review of the 11th chapter

This chapter is about the final preparations of planning, so here I go, explaining that the team is ready to finally create its first estimates, develop a plan to deliver the project.


Describes the preparation work that should be done after the project requirements have been baselined and architecture work is under way. This work includes the following tasks:


In the project estimates
 the requirements are finally been baselined, now it’s the time to create meaningful estimates for effort, cost, and schedule, keep in mind that the estimation procedure should be written, estimates should include time for all normal activities, the project plan should not assume the team will work overtime, estimates should be created using estimation software, estimates should be based on data from completed projects, watch for estimates that developers don't accept, the project team should plan to re-estimate at several specific times during the project, estimates should be placed under change control.


Writing a Staged Delivery Plan, the software is ultimately delivered in stages, with the most important functionality delivered first, this means in this order Software concept, requirements development, architectural design, Stage 1 to n: Detailed design, construction, and release and finally software release.


Performing ongoing planning activities explicit risk-management activities that were initiated at the beginning of the project should continue throughout the project. Check the vision statement and, if necessary, revise it so that it can provide direction throughout stage planning, architecture, and detailed design and implementation. Check whether the decision-making authority identified during preliminary planning is clear about the project plans and goals, including the Change Control Plan and preliminary estimates.


In conclusion, the project estimation is also important because is the way to know what you’ll do give you profit for all the work you’ll do, it’s the key point to the client say yes or no to the development of the project.


#TI2011 #ChapterTen

2 min read

Chapter Ten

Review of the 10th chapter

This chapter is about the software architecture which provides the technical structure for a project. If the architecture is good makes the rest of the project ready but if it is a bad architecture the project will be impossible to develop so here we have another important fact that should be take care of, the wonderful architecture.


The architecture phase in software development is a time during which the software is mapped out using prototypes and design diagrams, it also provides an exploring feature that search for types of low cost, the architecture team partitions the system in subsystems to specify the interactions between them, it also address the major design issues that appear throughout the system such as memory management, string storage and error handling.


Architecture must support the delivery plan and the architecture document.  For the delivery plan, it must accommodate functionality to each piece of a delivery, and for the architecture document it should describe all the architecture process. The architecture plan won’t stop, but it should be committed to put the conceptual into real with its analyze requirements working perfectly.


In conclusion architecture is an essential phase so the project has the correct construction is like the base of it because is part of the design, If it is not well designed, it will not work for what was intended to do.


#TI2011 #ChapterNine

3 min read

Chapter Nine

Review of the 9th chapter

This chapter is about the quality assurance this is testing but now it’s not only that it’s also about technical reviewing and project planning. The general definition of quality is "the degree to which the software satisfies both stated and implied requirements." In fact, this chapter explained how to assure that kind of quality.


Why quality is important? Well, software quality has a bottom-line impact on the costs of doing business, so that is the main reason. Low quality software increases the burden on end-user support. Leading-edge companies by charging end-user support costs back to the business unit that produced the software responsible for the support call.


It is also important what you decide because the effect of releasing low quality software will cause an effect on your business. Normally, customers do not remember that high-quality software was delivered late or that low quality software was delivered on time as much as they remember whether they like using the software.

An effective quality assurance plan will call for several quality assurance activities, that I’ll explain in an easier way:

·       Defect tracking is the activity of recording the defects from the time they are detected until the time they’re resolved. They can be detected and resolved in both levels individual and statistical

·       Unit testing is informal testing of source code, is usually performed informally but should be required for each unit before that unit is integrated with the master sources or turned over for independent review or testing.

·       Source-code tracing is stepping through clearly the source code line by line in an interactive debugger that are many. This work is usually performed by the developer who wrote the code, but it can be a special worker.

·       Technical reviews are reviews by developers of work their peers have completed. These reviews are used to assure quality of the User Interface Prototype, requirements specification, architecture, designs, and all other technical work products.

·       Integration testing is exercising newly developed code in combination with other code that has already been integrated.

·       System testing is the execution of software to finding defects. System testing is performed by an independent test organization or quality assurance group.


In conclusion, the quality is very important because it is the way in which you realize that your software is in its full functionality. This means that it has no problems and doing this type of tests helps the proper functioning of it.


#TI2011 #ChapterEight

3 min read

Chapter Eight

Review of the 8th chapter

This chapter is about requirements and the importance of knowing perfectly what the project need to fulfil its creation so this part is essential to the success of it.


The development of requirements is divided in three parts:

·       Candidate requirements, this is done by interviewing the client questions to make sure that him and you are in the same page.

·       Specifying requirements this is done by committing the candidate requirements to a tangible media, and not just words, because writing in paper make those things clear in your head, you must check and make him sign what you talked and write is what the client wants.

·       Analyze requirements is breaking down the essential characteristics


When the author said, “I use the word development to emphasize that requirements work is usually not as simple as writing down what key users want the software to do.” Is brilliant, because this is a step that many people that is new in developing software skip and they just write and write what the client says and that’s not the correct way, you must analyze and say to the client if his idea will work and how you will implement it so he knows what can be done.


SPECIFYING requirements is so important for further development and specially in coding, because you will take 50-200 of time correcting the requirements, so please, make sure that your requirements are ready to be code.


The author give us nine steps to develop requirements that I would break down in an easy way.

1.     Identify a set of users who will provide the guide lines in the project’s software requirements define.

2.     Interview the client to create the preliminary requirements, this is the first part of the development of requirements.

3.     Build a simple User Interface Prototype, prototype as simple as possible, the point of this is to present many alternatives to the user before you commit a greater effort to it.

4.     Show the simple User Interface Prototype to the client and solicit his feedback. Continue revising the simple prototype, keeping it simple, showing it, and revising it again until the client is excited about the software concept.

5.     Develop a guide that codifies the prototype's look and feel, review it, and put it under change control.

6.     Fully extend the prototype until it demonstrates every functional area of the software. It should demonstrate the functional area, not actually implement it.

7.     Put the prototype under change control. Then require the developed software to match the prototype exactly except for changes approved through the change control process.

8.     Write the detailed documentation based on the prototype. This detailed documentation will become the detailed software specification, and it should also be put under change control.

9.     Create separate, non-user-interface requirements document this is for the interactions with other hardware and software. Put that document under change control.


In conclusion, requirements are the base of an easy coding part so please take the time to be completely sure that the project is under these steps so you won’t fight against common errors.


#CreandoUnaCulturaDeExito #TI2011

4 min read

Esto es un resumen de lo que logré adquirir de la conferencia de Ricardo Rodríguez Fernández uno de los muchos presentadores que Ken nos ha traido

¿Cómo ciertos grupos llegan al éxito? Característica, los que llegan al objetivo es los que están a favor/buscando algo y no en contra lo negativo no prospera, esto tiene relación con los equipos de Software

Cuatro factores principales/ Los Pilares

  • Objetivo claro, puedes hacer un mapa
  • Propositivo que sea de ideas, serie de personas que dicen que no va a funcionar (fracaso)
  • Equipos exitosos tienen un plan, los planes no sirven en la ejecución para nada, pero si no planeas fracasas ya que no sabes que hacer
  • Los equipos exitosos tienen compañerismo, apoyo es fundamental

Objetivo en un programa de Software

Software exitoso = Software utilizado

Para que usen tu software tiene que ser consistente

A pesar de errores el software debe de ser consistente a menos que sea erróneo

Imposible llegar al 100 en un software

La consistencia es el factor principal para mantener a un cliente satisfecho


Producto mínimo viable / Minimum Viable Product (MVP)

Crear un producto que entregue valor y por el que estén tus clientes dispuestos a pagar

“If you’re not embarrassed by the first version of your product you’ve launched too late” – Reid Hoffman

El software se vuelve bueno con el tiempo, el software es iterativo, no tardar tanto en desarrollo


Feature Creep

You are confined only by the walls you build yourself

Ser objetivo, aterrizar las ideas y dejar las cosas que no te pidieron pero que pueden funcionar para parte de actualizaciones que sean cosas que el usuario en verdad las vaya a usar sino son extras inservibles.

No existe el requerimiento estable los requerimientos son dinámicos.

Ser claro con lo que se va a hacer, ciclos cortos de desarrollo.


Todo el equipo va a un objetivo

Actitud del equipo


Kaizen / japonés, mejora continua


Las cinco palabras que matan a toda organización

Siempre lo hemos hecho así

Modificar la mentalidad para llegar al éxito

Las cosas pueden cambiar para mejorar

La actitud es lo que hace al éxito


Los rusos no van al baño, hijo, sin un plan

Metas claras, no son objetivos ni características, quiero llegar a…

Estrategias, como llegar a esas metas

Acciones, que hacer para poder llegar a la meta

Recursos, con que podré llegar a la meta


Composición del equipo

Saber qué hace cada miembro del equipo

Valores del equipo, interacción humana, puntualidad, integridad lo que dije que iba hacer lo voy a hacer, compromiso hacer lo que dijiste que ibas a hacer, honestidad en verdad hacerlo


Protocolo Operativo

¿Cómo se toman las decisiones?

¿Cuál es el método de comunicación?

¿Cuál es la frecuencia de la comunicación?

¿Cuál es el método de resolución de diferencias de opinión?

Managing software is managing people

Administrador de software también tiene que ser un administrador de personas

Inspirar a que haga y no regañar para que lo haga


El punto de partida

Clásico FODA a nivel proyecto y a nivel personal

Asignar que hará cada quién la situación cambia en el proyecto, pero planear funciona para un comienzo


El equipo

Apoyo no es el compañero que te motiva cuando todo va bien, es cuando te echa a mano cuando todo va mal, estar dispuestos a ayudarse mutuamente, levantar ánimo, culpar menos

ALGO VA A SALIR MAL, cuando sucede algo que no debía ser, comunicación decir algo claro, confianza saber que tu compañero puede hacer algo, respaldo que sabes que si te trabas te van a apoyar. 

Los proyectos de software llegan a tener un nivel de estrés muy alto, saber cómo manejar a la gente, todo está en el equipo de software.


#TI2011 #ChapterSeven

2 min read

Chapter Seven

Review of the 7th chapter

This chapter is about planning plans for plans to have plans correctly planned, I did this so you are aware that the objective of this course is totally about planning so you can have a nice and less stressful project, so here we go. 

The first thing about any project is to have a vision and more than that a common vision, without a shared vision high performance teamwork can’t take off. Studies mark that having a clear objective the team function in an effective way, helps to decision making on smaller issues, helps to keep the team focused and avoid time-wasting side trips and many other things, so have a common vision to make an effective project. To define what to leave out is linked to the vision so it must be precise so it can guide the project to an easy way to develop and knowing what is going into the project and what won’t.

The executive sponsorship is the support given to the group who has the final decision, this is critical to project success, this group should be responsible for committing to a feature set, approving the user interface design, and deciding whether the software is ready to release to its users or customers. When I think of the executive sponsorship I remember of a conference that we had in Ken’s class that is about having one person that says go ahead with that or not and is the CEO, so for every final decision it goes right to the CEO’s hands to decide.

The project scope targets are having an idea about the intended budget, schedule, staffing, and feature set of the software at the end all of them are estimates, it’s rarely that a project is on the budget or at the schedule, that’s the reason of the estimations so it won’t affect that much the result of the project.

Risk management is also an important subject, part of the budget must be assign to the risk effects that will happened throughout the develop of the project.

In conclusion, planning will lead the project to a simpler and less stressful development, planning makes us locate what the project needs, minimize risks, mistakes and times, plan is life, plan is love.


#TI2011 #ChapterSix

2 min read

Chapter Six

Review of the 6th chapter

This time I’m bringing to you about how to manage the changes correctly in a very efficient control without making an expensive investment in them because controlling changes is an integral part of the project planning and is critical to project success.

The procedure to control changes in a project is at first in the initial development work, here the changes are made in a free way to the work product, in second place the work product is submitted to technical review and declare complete, in third place we send the work product to the “change board” which in here we make changes in a more systematic process, in fourth place it is send to revision control where everything you do is checked to find things that can change, in the fifth and final place is explained the process of a change, at first the proposal change is sent, then the change board identifies what is affected by the new proposal change and notify, the next step that is assess the cost and benefits of the proposal change, then is to accept or reject the proposal change and finally notify if the change proposal will or won’t proceed.

Change control primary benefit is that it does what is intended to do, another thing it does is that it protects the project from unnecessary changes by ensuring that the changes proposal is considered by a systematic way as we talk the last paragraph, it also improves the quality of decisions making every parties involved in them. The change control is aware of everything when something is “finished” it reviews and check if the work product or the reached milestone is complete. 

One of the benefits of automated revision control is versioning, it enables project members to retrieve ant version of any major document that has been produced throughout the project. They can recreate any version of the product that has ever been released to a customer.

In conclusion is very important to be aware that changes are coming throughout the project so at first, we must analyze them if the change is necessary or how much it will cost the change talking about time, money and development crew.