martes, 28 de febrero de 2017

(Nunca) Dejaré de defender a La La Land.

14 veces nominada al Oscar. Aclamada por audiencias, cinéfilos y críticos de cine por igual. Una gran oda a los musicales, las películas y Hollywood en general. Un sueño de Damien Chazelle llevado a la pantalla grande junto con su "roommie" de la universidad Justin Hurwitz (compositor de la música de la película). No me debería de sorprender la cantidad de odio que recibió/recibe.

La La Land nos muestra una historia de 2 artistas que, en tiempos contemporáneos, se encuentran en la ciudad de las estrellas buscando convertirse en unas. El personaje de Mia es una actriz que, después de muchos intentos, sigue buscando la forma de conseguir un papel para cualquier obra que se le presente. Sebastian es un jazzista clásico que está herido a causa de la lenta muerte de su género musical. La película está tomada en CinemaScope, tecnología utilizada para grabar los musicales de los años 50s y cuenta con un estilo obviamente inspirado por Lubezki y sus tomas largas que te sumergen en la cinta. Y claro, cuenta con un guión romántico y comédico que hace click con todas las demás características de La La Land.

Al ser clasificado ante la sociedad como un "fanático de La La Land", he recibido todo el criticismo (bueno y malo) de la película, y me entristece que, muchas veces, la razón que eligen para decidir que la cinta es mala sea "No me gustó". Voy a recorrer algunos pensamientos que me han compartido amigos y conocidos al respecto de La La Land y daré mi opinión al respecto de cada una después.

El guión es bastante sencillo. Es cierto. No trata con temas complejos como Moonlight, ni con reflexiones profundas como Nocturnal Animals. La idea es bastante concisa y lineal. ¿Esto es malo? Yo creo que no. Películas como Titanic y Casablanca cuentan con guiones que no son complejos y aún así son interesantes; vaya, The Avengers es una de las historias más lineales que conozco y jamás me aburro de verla. Quizás el guión de La La Land parezca simple, pero ¡La manera en la que lo llevan a la pantalla es impresionante! Si te fijas bien (y yo noté esto gracias a la plática con un amigo) puedes ver que en cada escena hay algún objeto azul, amarillo, rojo y verde. Los vestidos de Mia se van oscureciendo conforme pasa la historia y en el montaje en el que se enamoran, el cielo brilla en morado (combinación de 2 colores).

No es inclusiva, sólo hay actores blancos. Hay dos razones para que esto sea "un argumento". Si lo que en realidad me quisieron decir es que "Todos los actores principales (menos John Legend) son blancos", es porque la cinta lo requería. La La Land no guarda secretos en cuanto a las referencias a los musicales clásicos del cine. Toda la cinta tiene pequeños mensajes ocultos que quieren mostrar su amor a películas como Singing In The Rain y Rebel Without A Cause. Al querer ser una oda, respetó todas las reglas que estos musicales impusieron implícitamente, y aún así logró ser inclusiva en comparación a las cintas anteriormente menionadas.

No tiene final feliz. Hay dos respuestas correctas para esta afirmación. 1. Claro que sí tiene. 2. De eso se trataba. Mia y Sebastian al final (SPOILER ALERT) consiguen alcanzar sus sueños, y son felices con ello, cada uno a su manera. Claro, no es el final romántico que el trailer y después el epílogo te logran vender, pero eso es lo especial de La La Land. Damien Chazelle te muestra cómo hubiera sido la película si hubiera existido en el siglo pasado, y el giro que él le otorgo.

No es realista. Pues, no. De eso se trata. La primer toma es cómo todos se ponen a bailar y cantar en la avenida más transitada de los Estados Unidos. Es una forma cortés de pedirte que te desconectes de la realidad por un rato y sólo disfrutes la película. Deja de pensar en tu realidad por un  momento y disfruta.

La verdad no sé, sólo no me gustó. Este argumento es terrible. De seguro te encantó Manchester By The Sea, oh espera, estoy bastante seguro de que no la has visto. (Lo siento, me pasé de sass). Está bien que no te haya gustado, pero eso no rige si la película es buena o mala, a mi no me gustó Hacksaw Ridge y puedo afirmar que la película es buena. El ser una buena película no siempre está conectada con los gustos personales de todo el mundo.

¿Qué pienso de lo que sucedió en los Oscar Awards? Más que nada estoy triste porque el equipo de Moonlight no tuvo su momento dorado, en el que todos los voltearon a ver diciendo "Wow, Moonlight, ahora sí tengo que verla". Me entristece que esa situación sólo les afecta a todos negativamente y yo espero que al menos sirva para que todos vayan a ver ambas películas. Merecen amor y respeto porque son increíbles.

Disculpen mi La La Rant, pero desde que empezó el backlash de la película, ésta ha recibido más fuertes críticas de lo que merece y se está perdiendo el cuadro completo. No podemos negar que La La Land es una gran película que va a trascender de 2016 y va a ser observada como camino a seguir por muchos más. Me encuentro a la espera de la siguiente obra de Damien y nunca se les olvide, si quieren hablar de esta película (o cualquier otra que haya visto), pueden hacerlo conmigo. Es muy interesante oír puntos de vista fundamentados diferentes al mío. Gracias por soportar el berrinche.

Image result for la la land poster

miércoles, 15 de febrero de 2017

Surviving at the Software Industry (6) - Don't take the red pill!

So, do you remember how in The Matrix the machines controlled the human race? Yeah, pretty good movie, if I spoiled you: c'mon that movie is 18 years old, it is actually your fault.

What do I mean when I ask you to not take the red pill? Well, it means that if you are not ready to take on a project. If you haven't read this lovely survival guide or my blogs and followed my instructions, well, you're gonna end being controlled by the project and not the other way around.

Changes are inevitable. You as a PM are going to have to deal with them and you better be prepared by downloading all the martial arts into you system. Or you can just follow the following advices by Steve McConnell.

  • Make changes at the beginning of the projects without worrying too much.
  • Create technical reviews to declare work stages complete.
  • Having a group of people who can discuss the changes in the project.
  • Make revisions to the project.
  • Notify changes to everyone.

All changes have to be considered before being applied. And we have to remember to ACTUALLY tell all the members on the team how the changes will affect them. So, take the blue pill of your project and have a blast developing it!

I always thought the blue pill looked like an Advill.

Image result for blue pill red pill gif

Surviving at the Software Industry. (5) - What to do?

This chapter helps us to create a well structured plan. Knowing our abilities and skill, the book emphasises in dividing the project on three phases: the discovery, invention and implementation. Discovery is to find new areas of our project, and trying to find all the opportunities of it by doing interviews. Invention is the place where we create our ideas, and implementation is to put those ideas on paper and actually make them a reality.

When you already think that you are ready for the implementation face, now it is time to create a staged delivery plan. This is achieved by analyzing all the requirements, dividing our teams and having a design ready. The Stage Delivery plan is pretty detailed about the activities of all teams and if helps you to know what will you get when a phase of the project is done.

By doing a Stage Delivery Plan we can get this advantages:
  • Critical functionality is available.
  • Identifying risks earlier.
  • Aknowledging of problems on earlies phases. 
  • Status-Reporting overhead is reduced.
  • Staged delivery makes more options available and gives us flexibility at work.
On the othe hand, by doing a Stage Delivery Plan we also get this disadvantages:
  • It increases the project overhead.
  • It increases the cost.
  • It needs plenty of testing.
  • a.k.a. More money.

When you get your client's money (of course this is a joke, don't take it to seriously), you can now think on the planning phases, the staffing and the code growth curve; each of these phases have a stage of requirements, architecture and construction (So right now, we are on a phase inside of a phase inside of another phase, if this ain't Inception, I don't know what it is then). To go from one stage to another one, you should be positive that you can work with what you already have.

It is super important to have milestones and deliverables. If not, we won't know in what phase of the project are we on. The also help the team to commit to the project and as a PM you can see how everything is working along.

That's all folks I'll upload the chapter 6 in just one moment, so stay tuned! 

Image result for la la land gif

miércoles, 8 de febrero de 2017

Surviving at the Software Industry. (4)

Today I'm gonna try something different. When I write about something I usually have all the resources on hand. But I feel my two last blog entries have been pretty stiff, so today I'm going to do it just by remembering the chapter, so if I'm missing something important, please tell me in the comments below!

I found this guide is just that. A guide. I'm learning as if a friend was telling me how to do something and not as a regular book, and that's just lovely. Now I know what book would I take with me if I was on a desert island. (Guide on building boats.)
 Image result for how to build a boat book
So this chapter talks about those skills we should have if we are planning on starting a project.

  • Checkpoint Overview: Having mock-ups and UX prototypes, and stuff like really well detailed software requirements is super important when you are about to take a decision on doing a project or not.
  • Risk Management: Being prepared for everything, even the worst-most-impossible scenario out of all. Failure in some cases could mean the team not eating for a while, and man, humans literally can't work that way.
  • Project Control: Everyone is doing it's part and CAN manage it. As a project manager you are responsible for the life of your project, as well as the well-being of everyone on your team.
  • Project visibility: Have you ever felt that you "kind of" achieve something while coding? Visibility helps you to understand what have you actually done and what you haven't. It is important for a PM to know in what ACTUAL stage the project is at any time.
  • Peopleware: Rule #89 of being a programmer: Never forget that normal people don't know how to code. Knowing the people that are going to use the final software is as important as the code developped.
  • User Involvement: We may think we know what people want on a software app, but we don't lose anything on asking. Talking with others can give you a better idea on what is the actual things you would want to see in a project.
  • Product minimalism: Man, I just love minimalism. It makes everything so simple and neat. Just as your code should be! If it is simple and readable, you can detect errors faster!
  • Focus on shipping software: Everyone must know they are developping the same thing. I know this sounds stupid, but if not everyone is on the same page, a project can't go right.
PD: I did cheat a little by copying the names of the titles, I'm sorry I don't have a perfect memory don't be all like this. See you soon, bye.
Image result for whiplash movie gifs

miércoles, 1 de febrero de 2017

Surviving at the Software Industry. (2-3)


After a lovely questionnaire in chapter 2, chapter 3 shows us that we have to define development processes and elements needed for the software. If we have this things all put together, our project can move forward easily and the people working on it can be more productive.

We have to define first, “What is software process?” The survival guide gives us 7 different answers to define it.
·       Committing all requirements to writing.
·       Using systematic procedures for control.
·       Conducting technical reviews.
·       Developing a systematic Quality Assurance Plan.
·       Creating an implementation plan.
·       Using automated source code control.
·       Revising cost and estimates of schedule.


Process can turn rigid for the software developers, and each of the answers of steps can have some backlash that can make the project to no happen. We as project doers have to look forward for our team to use their productive time wisely. 


Thank you for reading! I shall give you an amazing gif from the filming of one of my favorite movies, La La Land. The guy on the green t-shirt is the director of the movie and he is a genius.


Surviving at the Software Industry. (1)

I liked the way the book "speaks" to me when I'm reading it, it feels like a guru giving you advices to succeed on the development of a project. Every software project that is considered low or medium size is achievable and optimizable.

The steps commanded by this guide are well explained and pretty basic. The first one is to recognize a software project’s essential survival needs, then it compared a project with a human and its needs illustrated by Maslow.

The author shows us how the needs of a software project look a lot like the human ones by adapting the Maslow’s Hierarchy onto Software needs.

We also learn about the Customer’s Bill of Rights, which are 7 actions that the customer has access to, such as objectives, time of development, features involved, change of requirements, project status, knowledge of risks, and ready access to deliverables.

On the other hand, he have the responsibilities of the Project Team’s bill of rights, these are the actions that everyone involved in the development of the project have to follow. To clarify priorities, to build and clarify the product definition, give the costumer ready access, etcetera.

What we learn today is that the 3 keys of success are communication, communication and communication. (Or at least for the success of the first step).


We shall continue with the second step soon! So I’ll keep you posted.