It is Already April 2019, for me the year is going faster and faster, and with this, I managed to finalize the fourth book I read this year, and this book was The Mythical Man Month , this book is recommended for any professional who wants to improve his knowledge about Management of software projects, and despite being a book with the first edition published in 1975 , it still shows us some visions that although they are in our front, we generally do not see, here are the most important points that I've considered the book:
1-programming is an art
This was the main idea that interested me already in its first chapters, in fact, because it is an intellectual work in which each individual has a unique and peculiar way of working, even if it follows one or more of the different patterns that we have today in the world , programming is a art .
"First of all, The execution must be perfect, In this respect, the computer Resembles the magic of Legends, If a letter or pause of the charm does not are rigorously in the appropriate format, The magic does not work "
"The adjustment to the requirement of perfection is, I think, the hardest part of Learn to Program "-The mythical man month
But This analogy presents good and bad points. As the author himself explains, as human beings, we do not have the habit of being perfect in our actions, in fact it is just the opposite, the mistake ends up appearing much more in our lives than the hits, which is a good Reason to remember why Agile methodologies , with the purpose of "fail fast but get it fast", eventually fell into the taste of corporations, in theory at least.
2-There are different many interesting roles that can be inserted into a software project
Despite being just an achism on my part, I saw that most companies summarize their teams at most between these points:
- Project Manager
- Programmers
- Database Administrators
- Infrastructure Support
Some companies may have more roles generally dealing with UX, testing and BI, but generally, the roles above are the most used by corporations, even so other roles can be added, the ones that interested me most were:
Language lawyer
The Lawyer of language is a role that really interested me, after all I always supported the idea of having someone who specializes in the language that is programming, bringing the best possible way to use the resources of language to improve our project. This role is rare, both in vacancies and within the development process, hopefully this will change one day.
Surgeon And Copilot
These 2 roles in the organization are also more interesting, the surgeon is a more common professional in companies, being a master programmer, always ready to solve the problems, the Ace. The copilot is already harder, having someone to criticize our work is usually not comfortable, so this paper ends up trying a very large barrier to exist, but as in football, have a support to the star is very important.
3-Certain internal problems of companies are older than they seem
One of the chapters of the book deals with certain social conflicts that we have in the area of T. I within companies. The point that drew the most attention to me, was that the author leaves explicit the barrier we have when considering that a person who does not program has more merit or importance than who program.
If we analyze several articles today about the difference of chief and leader, we see that this does not fit into a model of T.I, after all the leader does not program how he can "descend" next to his team to help in the work. With This, author suggests that management positions and technical positions have separate but hierarchically equal roles to reduce conflicts between managers and technical leaders.
Focus on Changes
When admitting that a pilot-system should be built and then discarded and that a redesign of modified ideas is inevitable, it becomes useful to fully face the phenomenon of change.
Even if it is an old book in our area, it still shows a problem we have until today, we do not treat the first versions of a system as something that will likely be discarded, because over time, the ideas on top of the software ripen, both in Conception as in representation.
4-For more technologies that come up, we cannot change a whole structure when it comes to legacy systems
The analogy that the author makes in one of the chapters between softwares and churches was quite interesting, putting a view that from the first architect have defined the concepts upon construction, they must be followed by the next builders who will come, to That the software is integrated into your project, and I have to agree with this, after all in my view, it is better a software more archaic and simple, but I integrate the concepts used, than a software that does everything but is a project without foot or head.
[Conclusion]: Despite being a well-dated book, The Mythical Man Month is a book that lives up to its name, for presenting some less conservative approaches, even though it has been so long, of course we know much more about software engineering than at that time. , where IBM's computers still worked with punched cards, but it's a good read to join today's expertise and create unique approaches for businesses.
Top comments (0)