The MM-M: O Melhor Livro de Software?

Hello folks, Fábio Akita. Some videos ago, someone asked in the comment section for book recommendations in the tech area I'll say right away that any "top ten" tech books list that doesn't include Fred Brooks and his magnum opus "The Mythical Man Month" close to the top is not a reliable list actually, here goes an important tip: the most recently published book, by more "celebrity" authors, rarely very rarely are useful. I don't buy them and don't recommend buying if your goal is to build solid foundations.

It should be obvious, but to really be considered good, a book needs to pass the test of time. If after 10 years it's still valid, I begin to consider it. If it lasted 30 or 50 years, now I begin to consider it for a top ten list.

Placing books that are less than 10 years old in a "top ten" usually exposes the list's weakness. Many modern authors despise the old software engineering books for having the wrong notion that the current "fake agile" or the glorified "kanban to-do lists" books are the only necessary doctrine and the ancient COBOL programmers did everything wrong If that's how you think or has any remnant of that in the back of your head, I'll tell you again right upfront - you're still a brat! Continue thinking like this and prepare to have a long mediocre carreer.

If you are in the tech area for a while now, Fred Brooks book "The Mythical Man Month" Is going to be surprisingly prevailing. When I read it, about 15 years ago I thought "Man, if I had read this ten years ago, in the beginning of my carreer, maybe I would have avoided many problems" or would at least have had insights to deal with different issues. Brooks describes in detail EVERY problem I've had in projects and possible solutions the book was published in 1975, after a lot of experience acquired with projects such as the Operating System OS/360 from IBM.

That is, after almost half a century, our area of software engineering keeps erring on the same things that they erred since the 60's George Santayana said: "Those who do not remember the past are condemned to repeat it. " I try not to be an idiot so I passed the last few years going after the past and that's why I deal with projects and teams in a different way and that's also why I have zero interest in the current discussions about "agile" I'll talk about this in another video. Actually, probably every big cliché you've heard has been taken out of this book by Brooks For example: the book's title is it's chapter 2, and also the so called "Brooks law": "Adding manpower to a late soft ware project only makes it later".

"Man Month" is the definition of the amount of labor a person can produce in one month - it's the fallacy that "people" and "time" and equal resources that is, if you have one person in a three months project or three persons on a one month project, it's the same thing. The biggest issue in a project is coordinating these people. Coordinating people, combining different paths among multiple nodes What was the formula you learned in college?

Oh yes: in the worst case scenario you have n * (n - 1) / 2 paths of communication, remember? That is: 10 * 9 / 2 = 45 days of communication among 10 people let's add 5 more people thinking it's g oing to get better: now you have 15 * 14 / 2 or 105 paths of communication. What about 20 people?

190 paths of communication. See how this escales quickly? Every time you assign new people to a project, according to Brooks - and according to my own personal experience as evidence - you disturb the project in at least three important ways: 1.

you now have to split tasks with the new staff; 2. These people will have to be trained with what has been done up to now - the "phase-in" or "on-boarding" time; 3. And finally, we have to new paths of communication to make it worse.

So, how do we set up a large project? Brooks describes the solution: you split the system in several sub-systems, each one with a "surgical team" Which he explains in detail in chapter 3 - a concise team He even mentions the concept of "feature teams" - a multidisciplinary team with a clear leader. It is known empirically for decades that a team should never have more than 10 people.

There's a section in this chapter that I like, in which he says: "if a 200-man project had 25 managers who are most competent and experienced programmers, fire the 175 troops and put the managers back to programming. " BUT that would make the project take 250 years to be done therefore better is to divide the 250 troops in 25 surgical teams of 10, each with a subsystem he initiates chapter 7 describing the Tower of Babel according to Genesis, the Tower of Babel was humanity's second work of engineering the first one being Noah's Ark. But Babel was the first engineering fiasco let's analyse this biblical tale from the optics of engineering: did they have.

. . 1.

A clear goal? YES 2. Enough people?

YES 3. Material? YES 4.

Enough time? ALSO YES 5. Adequate technology YES If they had all of that, why did the project fail?

Because of two aspects: communication, and by consequence, organization. The conclusion: how should small teams communicate with each other? IN EVERY POSSIBLE WAY Grab the goddamn phone and call, send a carrier pigeon, smoke signal and communicate!

It is know since Genesis if you believe the Bible or since the 60's if you believe in Brooks that lack of communication is the main cause of failure of projects. Why do you think some of the most famous softwares nowadays are for coordination? Jira, Trello, Slack, Basecamp, GitHub And speaking of GitHub, in it's republication in 1995, it reflects of the chapter about the Tower of Babel, quoting: "In the Operating System/360 project, we decided that all programmers should see all the material" Harlan Mills argued in a persuasive manner that programming should be a public process, and exposing all the work for everybody helps quality control by peer pressure for making things right, as well as by making possible that anyone can help finding flaws and bugs OS 360 is a project from 1964 If you think the notion of "The more eyes on the code, the better" comes from Open Source, I would say that the notion of Open Source comes from this insight from the 60's.

In chapter 4 he talks about Aristocracy, Democracy and System Design where he postulates something probably more important than the title of the book: Conceptual Integrity and, quoting Brooks, I'm going to support that Conceptual Integrity is the most important thing to consider in System Design It is better for a system to omit certain features and enhancements but reflect one set of design ideas than having a system that contains a lot of good but independent and uncoordinated ideas. one or several teams doesn't matter - what is needed are leaders whose main job is to keep the Conceptual Integrity software projects are not and should never be democracies where every good idea someone has gets into the system. someone needs to be responsible for the integrity of the product as he says in the chapter's title, an aristocracy, a "benevolent dictator" or have you seen any Open Source project without a core team which decides what to merge or not?

let it all in, and what you get is a Tower of Babel. In the 90's we got that concept wrong and elevated the ideia of the famous "system architect" too high without putting this goal in a clear manner CONCEPTUAL INTEGRITY but that was another mistake from not reading the book since Brooks puts very clearly that the purpose of programming a system is making a computer easier to use a monumental architecture done by an architect has no purpose if it served the system but no the system's use another thing that I always say, but Brooke said it first: an architect that can't code is good for nothing quoting Brooks: "The architect must always be prepared to show an implementation for any feature he describes, but he must not attempt to dictate the implementation. " we shifted the focus from that and split the architect in tech lead and another role for keeping part of the conceptual integrity.

nowadays there's a similar concept - the product owner and since we've mentioned "agile", let's get back to another fallacy: that only in the 21st century did we learn that Waterfall is bad, and because of that we changed it with agile which is one of the furthest to the truth notions of all time - and I say that from my own experience because that implies that all programmers from the 90s, like me, were dumb. Well, some were. But think about it like this: we delivered software in the 20th century.

On to the 11th chapter: Plan to Throw One Away. Quoting Brooks: "In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three.

There is no alternative but to start over, smarting but smarter, and build a redesigned version in which these problems are solved. " That can be done in one go, or chunk by chunk everything you discuss today about rewriting or refactoring is a discussion that has been around for decades nothing new here in this chapter he says that the only constant is change, and the first thing to do is accept the fact that changes are facts in life and not exceptions. prepare the project's management to accept changes sounds like a modern agile theme, but this idea is also from 1975 he says that eventually you will have to (in one go or by chunks) end up rewriting the first system but in chapter 5 he warns about the dangers of the Second-System Effect quoting: "The general tendency is to over-design the second system, using all the ideas and frills that were caustiouly sidetracked on the first one.

" He warns that the "second is the most dangerous system a man ever designs. " a classic example - remember Windows Vista? Or in our more recent world, every new JavaScript Framework?

He defines and describes in detail those stages, including the amount of bugs that emerge from this changes, and how to deal with them. he doesn't call them by this names, but he advocates: tests, fixtures, regression testing. .

. let me quote a section in this chapter again: "The fundamental problem with program maintenance is that fixing a defect has a substantial (20 - 50 %) chance of introducing another therefore, the whole process is "two step forward and one steps back" and why are defects not fixed in a better way? First, because even a small defect that seems local, has ramifications throughout the system.

Any attempt of fixing it with low effort will repair the local and obvious defect, but, unless the system's structure is pure or very well documented, the effects of that repair will go unnoticed. Second, the repairer is usually not the programmer who wrote the original code and is usually a junior or trainee. As a consequence of the introduction of new bugs, maintenance programs require more system testing theoretically after repair, you should run the whole test suite to ensure the system has not been damaged.

You think the concept of running test suite manually or automatized is something new, again: 1975. In chapter 14, there's a phrase I used in the video about "priorities": "How does a project get to be a year late? .

. . One day at a time.

" In this chapter he says: "How can someone manage a big project with a tight schedule? The first step is to have a schedule. Defina milestones, define priorities, define dates.

Milestones need to be concrete, highly specific and measurable. In the agile World, that would be close to the notion of "done" of each stage. Define dates and make it fit.

For that to work, you need to change something teams, architectures, backlogs. . .

change! Just don't change the date - this is managing. Anything else is interference.

If this alone didn't convince you, let's move on to the 1995 edition The interesting part of the modern editions is that Brooks started to criticize his own book besides updating and expanding some concepts. In 1995 he talks about chapter 11 where he says you're going to throw away the first system at some point and clarifies: he begins by saying that the Waterfall model is wrong and also correctly points out how Winston Royce improved the sequential model in 1970, adding feedback stages. So Brookes sums up: the first basic fallacy of the Waterfall model is that it assumes that the project advances through this process only one time and the second fallacy is that it assumes the system is built in one go.

What's the solution? Brooks says: "An Incremental-Build Model". as an example he mentions Harlam Mills model where we start by building the system's skeleton with empty functions and go about filling each one - compile, test, repeat.

and, quoting Brooks, we have a system that runs - "If we are diligent, we have at every stage a debugged, tested system. " And since we have a system that works in every stage, we can start user testing much sooner we can adopt strategies that fit the budget what protects the project from schedule delays, costing, maybe, less features. he basically described conceptually the Test-Drven Development model, frequent deploys, staging environment with always working versions.

. . and that's only what there is of more modern in the agile world of today, but in 1995!

if you think that Continuous Integration [C. I. ] and Continuous Deployment [C.

D. ] are creations of the modern agile model, this chapter from '95 mentions James McCarthy, who describes the process of "nightly builds" which Microsoft did since those times. An automatized process that every night recompiles and rebuilds the newest version so the next version could be tested in the next morning.

if there was a serious defect, stop everything, repair and repeat the process. Another quote that everybody has heard at least one time is there is "No Silver Bullet" Where do you think that comes from? It's the first papers included in the 20 years anniversary edition in 1995 it opposes Moore's Law.

In Moore's Law (which is also already dead, by the way) Moore postulated that the processing power would double every 12 or 18 months. simply put, there's nothing like that in software - we can't make software projects in half the time every 12 or 18 months. we are far from having even an order of magnitude in software engineering efficiency.

it's the "missing link" of our engineering. In the book, he mentions other authors which you should check out if you watched my series "Why your language is not special" I'll remind you that I mentioned Niklaus Wirth, who invented one of the most important things in programming: Modularization, with his language "Modula", before Pascal. but Brooks talks a lot about other important researcher: David Parnas who created the concept of hiding information or Encapsulation - one of the pillars of Object-Oriented Programming which you use to this day and I'm pretty sure you've never even heard of David Parnas.

Besides them, Harlam Mills who developed a software engineering methodology he called "Clean Room" and in many ways already has aspects that you could call "agile" and finally Tom DeMarco who I'm sure you have at least heard of because of his famous book, "Peopleware" as you can see, "The Mythical Man-Month" is a "countryman" of some of the most important names in the computational World. It has several aspects that only make sense if you keep in mind that it was written in '75, and therefore mentions languages like EPL, Modula, Algol, Cobol, Ada but obviously doesn't mention Java or Python -- they had not even been invented yet. I saw "agile", extreme programming techniques, repositories such as Git, all the Open Source process being created from day 1 and I see how the concepts already existed before.

If you only started programming in the 21st century, I know it seems like there was nothing before but for me, as I started programming in the end of the 80's, nothing was really surprising it was just an evolution of what I already knew, and I saw a lot of stuff I already did get famous, that's all. I'll talk about that in another episode. Once again: if you take your programming carrer seriously, put aside the newer books I'm not telling you not to read them, but start with this one.

From there, look for Fred Brooks bibliography Those are the authors that really matter For example I mentioned name such as Christopher Stracher from CPL, or Codd, or Dijkstra don't read Brooks as a procedure or doctrine to be followed -- it is a conversation an experienced programmer in 1975 telling a 2018 (or 2020) programmer how he keeps on making the same mistakes using for context the projects and technologies from the 70's and 80's and you should be frightened to realize how in 50 years very little has actually changed in software engineering. And it makes sense, because if every time you ignore what is known about the past, you're simply going to make the same mistakes again. and - if you're lucky - arrive at the same conclusions.

it would be way smarter to "climb on the shoulder of giants" and use what they already knew and warned us about. I do that, and the way I work has more from Brooks than from modern agile. and when I see some of the atrocities that come from the agile world, I can only think .

. . "Eh".

. . In a more bright side, Brooks wrote a chapter called "The Joys of the Craft" where he tried to explore why programming is neat Summing up, he arrived at this topics: First, simply the joy of creating things - that is crafting programming is a profession of practice - it depends on practice Second, the joy in making things that are useful to other people Third, the fascination of connecting complex objects like a puzzle with mobile pieces and see it working playing around with the consequences of the principles set in the beginning Fourth, the joy in learning constantly and finally, there's the joy of working in such a malleable media.

Remember what I've been saying in the videos about colleges: the only thing you really need, is to learn how to learn and the only way to do that is to first enjoy learning things. it's the only way to start to become a good programmer if you become someone who follows a doctrine, only follow certain brands or only use certain tools you will never evolve as a programmer -- you will at best become a decent typist: copies but never creates, repeats but doesn't know why. Where's the "science" in "computer science"?

Science is not dogmatic. So! What did you guys think about this video?

Don't trick me: did you already know about this book? comment below if yes, and tell me what you like the most about it. If you enjoyed the video, leave a like, subscribe to the channel and click the bell so you don't miss the next episodes.

See you next time!