Mythical Man-Month Analysis

Well. What I’ve learned from this book, in fact, it’s stated from the start (I don’t remember at which point exactly, but I think it was in the beginning chapters); It’s that there isn’t a thing that causes problems and delays, there isn’t a specific thing that the book, the teacher or anybody else can tell you and warn you about at the moment when you become a software manager, or project owner, or developer.

Things just happen. A lot of them. At the start it’s just something simple, maybe something that no one thought that it could evolve to something else. Then another thing appears, now you notice but you don’t react immediately, and then another, and another, while the progress keeps getting slower and slower. And then the morale gets lower, and the performance too, and the client gets mad.

It’s a sad and stressful path. And there really isn’t something that you could know it will happen in every project. But you can try to prevent, everything, and make plans for every scenario if it comes to be, even if at the end the project goes very well.

And this is what the rest of the book is about. What is to really manage a software project and everything you can do when assuming such position. Either as a manager for the architects or a manager for the implementers, or general manager.

A basic concept for a good project to try to get to the end is communication. There is no chapter in the book where this capacity isn’t mentioned. It’s very important. At first level, there needs to be a very good communication between the architects and the implementers’ representatives. This is essential because the implementer will try to keep the architect from the skies and the architect can explain to the builders exactly what he wants. Then, problems will arise at the moment where an implementer has a doubt and doesn’t communicate it to an architect, and decides to just make assumptions. This only causes a slippery slope, where if this assumption causes a malfunction or a undesired quality of the project, a full redo must be done. Full communication should be present when talking to the clients, because after all, even if the architects are the ones who tell how they see the project, the client is the one who will have the final word. The don’t need to see the white box of things, only the black box, and if they don’t like it, everyone in the project is in problems.

Now, not every part of the communication has to verbal, in fact, it shouldn’t be. There is something important in writing things on paper. It will force the top-level architects, the implementers’ leaders and the implementers themselves to make micro-decisions at that moment. Sometimes just talking about it provides nothing useful (And if the person is like me, this happens a lot). Writing things out forces the author to state his ideas clearly. For the architects, it’s important to write on paper the specifications of the project. And those should take as many sheets of paper as necessary. Precision and lots of details are needed, even if the document becomes boring.

In the other hand, the main architect (Who is the main surgeon, as stated in the proposal for team organization in chapter 3) can’t deal with all the administrative work. Budgets, schedules, space allocation, and other organizational information should always be documented by the architect’s right hand. And why is this important? If most of the staff can work without knowing this information. Well, it’s important to not just tell on a daily basis what should the implementers do. They tend to feel more secure and have a better performance if they know the full work plan. Where are they working? How much time they have left? What is the course of action if some requirement isn’t meet on the schedule? It’s important the full staff is aware of all these questions and answers.

And finally, what should the base developer write? Like everyone else, everything. His doubts, his progress, the bugs he has found, the bugs he has solved and how were solved. This log will serve for the future because we can almost assume that those questions weren’t thought only by on developer, but by many of them, or almost everyone, especially if an architect hasn’t made a good job describing his design.

Who would have guessed that at the end, communication is the basis for a project not to fail, as it is to solve most or all of the problems in life? Always ask, never assume. Talk in the proper medium and style as corresponds to your position, talk with respect, but most importantly talk with precision and details. It will be easier for the other person to provide you with a solution to your problem, or answer your question.

Oh, and another thing I like a lot about the book is the proposal for team arrangement. Instead of having to deal with a lot of programmers that are currently working for the project (And them having to deal with each other, and a unique leader -you-), let’s have micro teams. Where each team will have a surgeon and a copilot, and they and only them will work directly with the code (In fact, the copilot can suggest changes and offers his opinion, but he doesn’t make any decision) and the rest of programmers can work on other things. There will be also a chief surgeon (Chief architect) who will coordinate with the rest of surgeons. This makes the work related to the chain of command easier. And also for each developer, because know their specific role in all the frame.

I must say that I was planning on giving an analysis per chapter, but time wasn’t enough. So I instead preferred to give this more general opinion of the book.

You can find some specific posts I did make here.



Simpson & Romberg

Por: Arturo Fornés A01227071 y Miguel Montoya A01226045

Nota: Tanto en el diagrama de flujo, como en el código y los ejemplos, utilizaremos el método de Simpson 1/3 múltiple.


Hay varios métodos para calcular integrales definidas donde se hace una aproximación por cada intervalo, como Riemann desde la izquierda y derecha, o por método de trapecios. Existen dos métodos más complejos que obtienen una mejor aproximación, estos son los métodos de Simpson (Trataremos especialmente el de 1/3 múltiple) y el e Romberg.

Simpson 1/3 está basado en la “interpolación cuadrática”, pues crea una función que pasa por todos los puntos dados e integra. La función es para dos intervalos continuos (Uniendo 3 puntos). La aplicación múltiple, es crear pares de intervalos para aplicar Simpson 1/3 a muchos puntos.

Romberg está basado en la integración por trapecios, y utiliza un método parecido a las diferencia divididas de Newton. Obtiene aproximaciones de integración con diferente número de trapecios para cada aproximación, y las mejora, hasta obtener un mejor resultado para la integral.

Justificación y propósito

Simpson 1/3 utiliza la siguiente función, para calcular la función perteneciente a los intervalos, antes de integrar.

{\displaystyle P_{2}(x)=f(a){\frac {(x-m)(x-b)}{(a-m)(a-b)}}+f(m){\frac {(x-a)(x-b)}{(m-a)(m-b)}}+f(b){\frac {(x-a)(x-m)}{(b-a)(b-m)}}.}

Debido a que siempre es la misma formula para obtener el polinomio, es fácil calcular la integral.

{\displaystyle I=\int _{a}^{b}f(x)\,dx}

Donde f(x) es el polinomio de Lagrange de grado dos. Podemos calcular una ecuación para cada intervalo, sin necesidad de calcular la integral de cada uno.{\displaystyle \int _{a}^{b}f(x)\,dx\approx {\frac {b-a}{6}}\left[f(a)+4f(m)+f(b)\right].}

Por otro lado, Romberg mejora el método de trapecios utilizando la siguiente formula

Screenshot from 2017-05-04 13-21-56

Donde se obtiene una integral mejorada, utilizando otras dos aproximaciones de trapecios, de menor nivel (Uno más exacto que el otro). Se denomina como aproximación más exacta a la que utilizo un mayor número de trapecios. Este método es recursivo, si obtienes x aproximaciones de un nivel mayor, todavía puedes obtener x-1 aproximaciones de nivel mayor.

Diagrama de flujo

Simpson 1/3 Múltiple.




Código en C++

Simpson 1/3 Múltiple: Github.

Romberg: Github.

Ejemplo comparativo

Para Simpson 1/3 múltiple, no se utiliza el método de trapecio para intervalos extra (En caso de que el número de intervalos sea impar, el último intervalo se integra con trapecios).

f (x) = x²

Se integra f(x) de 1 a 5:s_x2_integral


Usando Simpson de 1/3 múltiple se obtiene una aproximación con una precisión de 0.00001:


Usando Romberg de 3 aproximaciones iniciales, usando aproximaciones iniciales de 100, 150 y 200 trapecios:


Romberg no fue preciso en este caso ya que este método fluctúa dependiendo de los valores de las aproximaciones por trapecios que se obtengan y qué tan diferentes sean estas entre sí.

f(x) = e^(x)

Se integra f(x) de 1 a 3:



Usando Simpson de 1/3 múltiple se obtuvo una aproximación con una precisión de 0.1:


Usando Romberg de 3 aproximaciones iniciales, usando aproximaciones iniciales de 100, 150 y 200 trapecios se obtuvo una aproximación a la integral definida con una precisión de 0.1:


En este caso ambos métodos dieron valores certeros, con el mismo grado de precisión.

Ted-Talks Opinion

Let’s talk first about the talk given by Sam Richards, the one about empathy.

I liked his example, putting the US in a position like the one they make other countries be when a society or a regime gets in between a resource and the US. It’s not right, and it’s even worse when the US citizens know about how are the foreign people treated by their army, by their governments that will do anything to their citizens if the US helps them to stay in power… And won’t do anything. That’s wrong. People should at least acknowledge that what they are doing is wrong. That people are getting killed, innocent people, to maintain the American economic lifestyle.

We often forget to ask who is really paying for our comfortable way of life. And if we did that more often, and put ourselves in the shoes of the people who are paying, with their lives, not just with money for the bills. They are suffering! They are dying! Their houses are bombed every day! From their government, from other nations, from the terrorists, from whoever. And the innocents, they don’t support the terrorists, they don’t support the regime, and still, they are paying the hard bills for us.

At the end, when using empathy, we allow ourselves to see the big picture and understand the other’s perspective. In the experiment Sam Richard does, we understand how a regular person, a regular Muslim, with a regular family, who live on a regular street in Syria, Iran, Irak, Afghanistan or wherever people are being subjugated to the other’s will sees the conflict. And Sam doesn’t ask you to change your perspective, but to understand theirs.

And as I have experienced, if you understand the other party perspective, it’s more probable to solve a conflict.

And if using empathy could help us understand wars, it can help us to solve any conflict in our regular life. Understanding your boss, who is asking you to perform at 110%. Understanding your employees who can’t really give their whole life to the work. Understanding your parents when they are angry at you. Understanding your sons when going to difficult stages of change in their lives.

It’s easier… And more healthy even.

And now into the David Marquet’s conference, about leaders.

First, I like to have control too. And I know that to have control is to give control.

Second, I know that my recurrent problem is that the people who I give the power to do things, they usually do nothing with it. I guess there are some people who need to be pressured as if they were hard-labor workers, like the ones in the photo of the factory.

And I know that it isn’t a really good practice. Because at the end, who really knows how to deal with the stuff, is the one who interacts with it as a regular job, not the one person who wants a change, or an execution of the stuff. And this doesn’t mean to give all the power of control to the subordinates because the organization and performance are at risk (Like the example he uses of giving leaves to the officers).

I gues I’m giving to much control to others… But still… I really do think there are people who ar ejust lazy.