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.

 

Anuncios

2 of Plato’s regimes – MMM Ch. 4

Conceptual integrity is to maintain the good initial ideas, even if it implies not making that many features. This is better than having lots of uncoordinated ideas.

Likewise, functionality and simplicity. Which is better? There have been software projects that have an outstanding performance in one of both.  But we have to say that it’s a combination of simplicity and straightforwardness. Every part must use the same philosophies, same semantics and syntax and the, you have conceptual integrity.

And how, or more precisely, who will achieve that integrity? Either one mind (Surgical team), the equivalent to an aristocracy; or a handful of minds, with a division of architecture and implementation, the equivalent to a democracy.

And it’s no bad to desire a democracy, but it has several problems. The people in charge of the architecture should consider methods to implement their architecture; the implementers, when suggesting ideas must preserve the integrity of the architects.
That’s why at the end, the aristocracy (Surgical team) is better because as long as the design and implementation are clear in the surgeon’s mind, everything is ok. Or at least, an aristocracy of architects, who have a clear idea of how the system should behave, and they should decide how to maintain integrity, even if that means to leave the implementers with practically no voice, at the end, what must endure the most is the design, not the implementation.

11487085615_d2a8126404_o
Using CC (BY-SA). Published by Jocelyn Kinghorn. From https://www.flickr.com/photos/joceykinghorn/11487085615

 

The Surgical Team – MMM Ch. 3

The dream: To develop a project with a small team you can know, and trust in their abilities. Forget the big teams, integrated by mediocre developers. In fact, by spending the double on a very good programmer, 10 times the performance could be expected. We can do this all by ourselves. Ah… The dream…

The reality: Big and complex problems need to be done and big teams are needed to do this.

How? Harlan Mills offers a solution. To make several teams, where only one member of each attacks the problem, and the rest only assist him in achieving maximum productivity. You keep a few number of people in the building design, but a lot of them in the actual construction. Just like a surgical team.

Here are the roles of this approach:

  • The surgeon: Define functional and performance specification. Designs, codes, tests the program and writes its documentation.
  • The copilot: Is a less-experienced surgeon. He advises the surgeon, and he can listen to him, or not. He knows the code perfectly but isn’t responsible for it.
  • The administrator: Even though the surgeon is the boss, he needs someone to be in charge of his administrative (Money, personnel, machines…) decisions. The administrator can serve 2 teams.
  • The editor: He writes the external and internal documentation. He reworks the draft of the surgeon.
  • Two secretaries: One for the administrator and the other one for the editor.
  • The program clerk:  He is in charge of the maintenance of the machine and user readable files.
  • The toolsmith: File, text and debugging services. Made fast and with quality
  • The tester: Design test cases and data.
  • The language lawyer: Master of the language selected for development. Can work with 2 or 3 surgeons.

Because the purpose of this team organization such that everyone is represented as just one, the surgeon. At the end, instead of organizing a 200 people team, you just have to deal with 20 surgeons.

6878041625_bf20f073b7_o
Using CC (BY-NC-ND). Published by UCD School of Medicine in https://www.flickr.com/photos/76652722@N04/6878041625

Schedule – Ch2 MMM.

Which is the main reason for a project to fail? Lack of time in the calendar. And why is there little time? Fail to estimate, confuse progress and effort, bad monitoring, and bad manpower management.

But, don’t let this bad things get to you… Lets be optimists.

In fact. that its exactly what we must stop doing (We shouldn’t stop being optimists, the problem is that in the programming area, we kinda abuse of it). We are always stuck saying “This time will work!” and “I assure you, it’s the last bug”. And why all of this optimism? Because programming involves creating what, in our minds, it’s already completed; So we tend to think everything will be fine.

So lets stop being optimists, shall we?

Let’s talk about the fallacious idea of a man-month. Bad project managers tend to think that the more people working on a project, the less month will be needed to complete it. But that is only true is there is a lack of manpower, when the programmers aren’t enough to do some progress at all. After that point of equilibrium, more manpower only involves more costs, because the tasks need a minimum time to be completed (A baby will be born in 9 months, no matter how many mothers he has). Even if some independence between some task was found, the time to “train” the new programmers, it it doesn’t increases even more the time needed, at least it doesn’t affect the schedule whatsoever. The only way that increasing the manpower with no limits could be a good idea, is when every single task has nothing to do with the rest of them.

And now that we have the manpower thing sorted up, you should know that what most affects a schedule is the debugging and testing. Because we are optimists, this phase is usually badly estimated. 1/6 of the schedule should be for coding, and 1/2 to all the tests and debugging. And why this bad estimates (Apart of positivism), the managers will select a schedule that will me the owner happy, instead of defending the procedure.

The Mythical Man-Month Ch1

The Tar Pit

This chapter starts with an analogy, comparing the development of a project with a big animal trapped in a tar pit. Why? A animal, as it tries to escape, makes strong and fast moves that will only make him more stuck. Like an animal, a big project, where each problem isn’t solved with delicacy and order, makes things worse. But also, the best could happen, and the project can survive.

A project can produce either a “simple” program (Like the ones produced in garages by two programmers that then became famous) and a more useful but complex and costly program, that evolves from the “simple” one.  There are two types of these programs: The programming product, program that can be run, tested, repaired and extended, implemented in multiple OS and well documented; and a programming system, is a collection of interacting programs, with lots of interfaces, semantic and syntax, with a precise budget of system resources and a bunch of testings with different system components. Both of these types of programs cost at least 3 times more time of development.

There is a final program type, that combines the characteristics of a programming product and system. It costs 9 times as much but it the the truly useful program.

A programmer enjoys his craft, but also a programmer can woe it. I’m assuming every idea regarding this part of the chapter, is kind of subjective, because obviously everyone is different and something someone might enjoy, might be the difficult part for another one.

The reasons a programmer enjoys the craft are:

  • Its always fun to make things
  • Receives pleasure from doing things useful for others
  • Resolving puzzle types problems with lots of moving and interacting parts
  • Joy of learning, because the problems are always new
  • Delight of working the ming, because a programmer works with pure thoughts, it build everything from air

In general, its fun, because it promotes creativity and sensibilities.

The reasons a programmer woes the craft are:

  • The performance must be perfect, if there is an error in the code, that’s it, it won’t work. It must be perfect
  • There is always someone who establishes your objectives, resources and available information
  • There is a great dependence on others’ work
  • It’s not fun to being a bug finder
  • The project might be obsolete (To your own eyes) before completion. All because new ideas might arise, that aren’t implemented. Usually this one might really affect the morale, but the truth is that it might not be as bad, because the obsoleteness of a product mustn’t be measured against non-implemented ideas, but against similar already-released products.

So this is the views of a programmer in programming