First time managers who are accustomed to succeeding based on their understanding of ‘how’ will initially struggle to define ‘why’. Nowhere is this more evident than in how new managers commonly dismiss the importance of formal documentation. However, when it comes to running large projects, documentation is often proof for what is going well and can be the first indicator of trouble for what is about to go awry.
A formal document forces the writer to make the hundreds of previously ignored decisions that must be perfectly clear for clean documentation. This task demands discipline and focus. If done correctly, a formal document clarifies policy and brings clarity to uncertain areas. A manager who can document understands the plan and knows how to communicate it. Since a manager's role in general is to keep everyone going in the same direction on a project, the task of creating formal documents should fall to the manager.
The documentation process is also critical for how it forces managers to question designers and ask them to defend their decisions. This process might reveal important information that would otherwise have remained hidden from the manager. If project participants are reluctant to assist with documentation, for example, it suggests that decisions are tentative or that the organization itself is threatening some feature of the project. These are sure signs of impending failure because projects with tentative direction are in danger of becoming uncoordinated - the manager should use this information to take on a larger role in any of the project's coordination tasks.
If the project is run by an organization prone to sudden changes in vision, perhaps the reluctance of participants to help the manager is a signal that the organization will never maintain the focus, discipline, or patience needed to resolve every small issue that arises in the course of the project. A manager armed with this knowledge will be in better position to help guide the team around upcoming obstacles and keep progress on track despite any outside pressure, inertia, or impulse from the organization.
Showing posts with label books - the mythical man-month. Show all posts
Showing posts with label books - the mythical man-month. Show all posts
Thursday, July 5, 2018
Tuesday, June 19, 2018
leftovers #2: mythical man month --some more thoughts on growing a system or team
The complexity of modern software is driven by three factors – almost all parts are unique (if they share properties, they generally become subroutines), it is often asked to conform to existing institutions, and it is often forced to change by new users or hardware. Considered as a group, these factors suggest no two software projects will be the same. To meet such unpredictable challenges over and over again, a manager must lead with some basic principles in mind.
First is to design the team’s work process in a way to encourage rather than inhibit creativity. A sure approach is to encourage growing a system one component at a time rather than trying to build a complex system in one major push. The key is to always have working code that the team can add to and build on.
A modular approach helps teams grow systems and products. If each section exists independently, the team can isolate maintenance issues so long as they work within the specifications ensuring the front and back end of each module fits into the neighboring pieces of the larger system.
Teams that become used to solving problems will develop an element of hustle. They will chase after lost causes and not be afraid of trying new things. A hustling team moves a little faster than necessary and creates the cushions needed to handle unforeseen events in their work process. When work is defined in small chunks that lead to frequent success, teams will become accustomed to victories and work a little harder in pursuit of the next win.
First is to design the team’s work process in a way to encourage rather than inhibit creativity. A sure approach is to encourage growing a system one component at a time rather than trying to build a complex system in one major push. The key is to always have working code that the team can add to and build on.
A modular approach helps teams grow systems and products. If each section exists independently, the team can isolate maintenance issues so long as they work within the specifications ensuring the front and back end of each module fits into the neighboring pieces of the larger system.
Teams that become used to solving problems will develop an element of hustle. They will chase after lost causes and not be afraid of trying new things. A hustling team moves a little faster than necessary and creates the cushions needed to handle unforeseen events in their work process. When work is defined in small chunks that lead to frequent success, teams will become accustomed to victories and work a little harder in pursuit of the next win.
Thursday, June 14, 2018
leftovers: mythical man month - some thoughts on scheduling
No matter what precautions, safeguards, or techniques a manager uses to put together a project schedule, slips and errors are inevitable. A good rule of thumb to use for building the appropriate slack into the overall schedule is to devote the least amount of time to the most easily estimated parts of the project. (In software projects, coding time is easier to estimate than debugging time, for example.)
Schedules that slip a few minutes at a time tempt managers to drop everything and make up the schedule slip right away. A good manager will leave these little ‘catch-up’ exercises to the team, however, because the overall impact on the schedule is negligible if a schedule disaster strikes in the meantime that affects the timeline by hours or even days. The manager's job isn't to make up for lost time, the manager's job is to use foresight to prevent time from being lost in the first place.
One method to prevent against surprise schedule setbacks is to implement a strict quality control system. Without proper quality measures, projects may move forward with defective components. If these turn out to disrupt the efforts of subsequent project steps, it may require the redoing of several portions of the project. Poor quality could also cause especially large projects to bog down during the debugging step because larger projects tend to involve more test users and the number of bugs tends to correlate to the number of users.
It is vital to ensure enough time is scheduled for testing. Any delays at this stage are particularly costly because the project is likely fully staffed at this point yet there is little defined work for each member to complete. The temptation in such situations to skip quality control steps (like rerunning test cases) must be avoided, however, because failures at the testing step are handed directly to the consumer and this will turn out to be far more costly than a delayed release.
Schedules that slip a few minutes at a time tempt managers to drop everything and make up the schedule slip right away. A good manager will leave these little ‘catch-up’ exercises to the team, however, because the overall impact on the schedule is negligible if a schedule disaster strikes in the meantime that affects the timeline by hours or even days. The manager's job isn't to make up for lost time, the manager's job is to use foresight to prevent time from being lost in the first place.
One method to prevent against surprise schedule setbacks is to implement a strict quality control system. Without proper quality measures, projects may move forward with defective components. If these turn out to disrupt the efforts of subsequent project steps, it may require the redoing of several portions of the project. Poor quality could also cause especially large projects to bog down during the debugging step because larger projects tend to involve more test users and the number of bugs tends to correlate to the number of users.
It is vital to ensure enough time is scheduled for testing. Any delays at this stage are particularly costly because the project is likely fully staffed at this point yet there is little defined work for each member to complete. The temptation in such situations to skip quality control steps (like rerunning test cases) must be avoided, however, because failures at the testing step are handed directly to the consumer and this will turn out to be far more costly than a delayed release.
Sunday, March 18, 2018
the bb book club: the mythical man-month, part two
Hello all,
Welcome to the final installment of the combined three-part review for The Mythical Man-Month. Why waste your time with further introductions? Let’s just jump right into it, reader.
Signed,
The Business Bro
Thoughts on scheduling and efficiency
The nature of error accumulation is for delays to add up at the back end. Think about it like a train. If the train is two minutes late getting to the first stop, it isn’t going to be on time to the second stop. With some extra effort, perhaps the train eventually gets back on schedule. But if there is another delay or two, the schedule becomes as useful as termites in a pencil factory.
This general truth isn’t necessarily a bad thing. It might not even be avoidable – if something could get done in half the time, the schedule would probably shrink to reflect it. It will likely just keep shrinking until something runs late. There is only so much slack that can be built into a schedule before the schedule itself will be required to shrink, probably because your boss said so (reader, meet square one - square one, reader). So, what’s the program manager to do?
One strategy is to make sure otherwise independent tasks are not unnecessarily linked together. If the project is organized like an assembly line, each interruption upstream delays the start time of a subsequent step. Dividing the portions of the design into separate sections ensures that teams can start and finish without depending on another step to be completed first.
The danger of local optimization
When a project is broken up and portions are assigned to different teams, one of the biggest threats to overall success is sub-optimization at the team level. By nature, teams will always want to do their very best work. If the communication structure keeps each team in its own bubble, the naturally motivated team might complete technically outstanding components that do not fit together with the other features of the project.
The project leader’s role is to make sure the project is optimized. This will mean some of the sub-components are not optimized. Sometimes, the sub-components will be completely inefficient. The leader's role is to make sure teams understand their role in the overall project. This work is best done behind the scene by eliminating any incentives that might tempt a team to go for their own goals rather than commit to making the project a success.
The point of the organizational chart
The organizational chart defines the process of communicating information. Its sole purpose is to reduce the communication and coordination efforts necessary to execute a plan. A well-defined communication structure means decision makers get the information they need at the right time. Any organization that seeks to produce flexible products must itself be prepared to change.
Organizations that do not understand the nature of a communication framework often become rigid. Despite the talk of flexibility and adaptation, red tape and bureaucracy become the norm and process begins to crystallize. If too many people without decision-making authority require information or key decision-makers cannot access needed information, it’s a sure sign that the organization’s communication structure is broken.
The most subtle managerial skill
The managerial role is very much like a gardener. The goal is not to make people work but instead to make it possible for people to work.
There is also an investor’s mentality required to manage successfully. Just as a long-term investor bets money today for returns tomorrow, a manager who wants to build a strong team must find a way to front-load costs for future benefits.
The critical managerial skill many first-time leaders lack is a willingness to wait for something to grow. This is especially challenging for high-achievers promoted due to their success at solving problems. These people are used to dropping everything to resolve an issue or doing whatever it takes to fix what is broken. The mentality is commendable and the approach often leads to great short-term results.
But managers expecting this mentality to continue serving them well at higher levels of an organization are shortsighted. One problem with this approach is how it will discourage team members. They will grow accustomed to others solving problems for them and will take less initiative over assignments. A manager must be disciplined and wait for as long as possible before stepping in - the key is to strike the right balance between allowing team members to continue learning from mistakes without allowing them to become discouraged from repeated failures or errors.
Another good example of such a challenge comes when bad news is shared during a regularly scheduled status report. The manager must never act immediately. Otherwise, subordinates will start waiting until the status report to share bad news. Instead of misusing the existing framework of a status report to gather urgent information, the manager must create a communication structure so that bad news is shared right away.
Finally, managers who demand full disclosure from their teams must discipline themselves. If they respond to every bit of negative news, team members will become more likely to withhold information. Good gardeners don’t look for weeds every hour and good investors don’t juggle their portfolio every time the market moves – new managers must recognize bad news as part of the growth process and trust their teams to work on continuously building up a successful team.
Welcome to the final installment of the combined three-part review for The Mythical Man-Month. Why waste your time with further introductions? Let’s just jump right into it, reader.
Signed,
The Business Bro
Thoughts on scheduling and efficiency
The nature of error accumulation is for delays to add up at the back end. Think about it like a train. If the train is two minutes late getting to the first stop, it isn’t going to be on time to the second stop. With some extra effort, perhaps the train eventually gets back on schedule. But if there is another delay or two, the schedule becomes as useful as termites in a pencil factory.
This general truth isn’t necessarily a bad thing. It might not even be avoidable – if something could get done in half the time, the schedule would probably shrink to reflect it. It will likely just keep shrinking until something runs late. There is only so much slack that can be built into a schedule before the schedule itself will be required to shrink, probably because your boss said so (reader, meet square one - square one, reader). So, what’s the program manager to do?
One strategy is to make sure otherwise independent tasks are not unnecessarily linked together. If the project is organized like an assembly line, each interruption upstream delays the start time of a subsequent step. Dividing the portions of the design into separate sections ensures that teams can start and finish without depending on another step to be completed first.
The danger of local optimization
When a project is broken up and portions are assigned to different teams, one of the biggest threats to overall success is sub-optimization at the team level. By nature, teams will always want to do their very best work. If the communication structure keeps each team in its own bubble, the naturally motivated team might complete technically outstanding components that do not fit together with the other features of the project.
The project leader’s role is to make sure the project is optimized. This will mean some of the sub-components are not optimized. Sometimes, the sub-components will be completely inefficient. The leader's role is to make sure teams understand their role in the overall project. This work is best done behind the scene by eliminating any incentives that might tempt a team to go for their own goals rather than commit to making the project a success.
The point of the organizational chart
The organizational chart defines the process of communicating information. Its sole purpose is to reduce the communication and coordination efforts necessary to execute a plan. A well-defined communication structure means decision makers get the information they need at the right time. Any organization that seeks to produce flexible products must itself be prepared to change.
Organizations that do not understand the nature of a communication framework often become rigid. Despite the talk of flexibility and adaptation, red tape and bureaucracy become the norm and process begins to crystallize. If too many people without decision-making authority require information or key decision-makers cannot access needed information, it’s a sure sign that the organization’s communication structure is broken.
The most subtle managerial skill
The managerial role is very much like a gardener. The goal is not to make people work but instead to make it possible for people to work.
There is also an investor’s mentality required to manage successfully. Just as a long-term investor bets money today for returns tomorrow, a manager who wants to build a strong team must find a way to front-load costs for future benefits.
The critical managerial skill many first-time leaders lack is a willingness to wait for something to grow. This is especially challenging for high-achievers promoted due to their success at solving problems. These people are used to dropping everything to resolve an issue or doing whatever it takes to fix what is broken. The mentality is commendable and the approach often leads to great short-term results.
But managers expecting this mentality to continue serving them well at higher levels of an organization are shortsighted. One problem with this approach is how it will discourage team members. They will grow accustomed to others solving problems for them and will take less initiative over assignments. A manager must be disciplined and wait for as long as possible before stepping in - the key is to strike the right balance between allowing team members to continue learning from mistakes without allowing them to become discouraged from repeated failures or errors.
Another good example of such a challenge comes when bad news is shared during a regularly scheduled status report. The manager must never act immediately. Otherwise, subordinates will start waiting until the status report to share bad news. Instead of misusing the existing framework of a status report to gather urgent information, the manager must create a communication structure so that bad news is shared right away.
Finally, managers who demand full disclosure from their teams must discipline themselves. If they respond to every bit of negative news, team members will become more likely to withhold information. Good gardeners don’t look for weeds every hour and good investors don’t juggle their portfolio every time the market moves – new managers must recognize bad news as part of the growth process and trust their teams to work on continuously building up a successful team.
Sunday, February 25, 2018
reading review: the mythical man-month
A few weeks ago, the Business Bro and I got together to discuss this book. Longtime readers, I’m sure, were not surprised to see this effort go up in smoke. My apologies, reader, for all the time wasted.
It occurred to me recently, though, that our conversation was a microcosm of the book’s larger point. As new members are added to a project team, the communication burden will increase. In these cases, the challenge for leaders is to structure the work so the benefit of added manpower is not offset by the increase in communication cost.
This sounds like a simple enough job, I thought, but there are a number of reasons why software development projects struggle to maintain this balance. One reason is the way management demands a skill set entirely different from programming. Software engineers of any value are perfectionists. Otherwise, the programs they write will never run correctly and all their time will go to debugging!
On the other hand, management is work that does not suit the perfectionist. A good manager must constantly make decisions about trade-offs. By definition, the manager’s job is to choose the best set of decisions from a set of imperfect options. Software project mangers who are promoted into the job after excelling as engineers are at a disadvantage because the perfectionism they relied on to reach maximum performance in the programmer role is going to hurt their performance in the manager role.
A specific area where these ‘perfectionist managers’ struggle is when designing the ‘second system’. Often, the second system is intended to replace a no-frills first version. The idea of a second system is exciting for architects because it is an opportunity to include the many ideas for neat designs, features, or capabilities they stored away during the initial design. (By reducing the complexity of the first design, the project was more likely to come in on time or under budget.)
However, overloading the second system with these features is likely to lead to delays in testing. It will also leave less room for other engineers to contribute their own ideas or follow creative tangents during the design process. In many ways, an architect must exercise more self-restraint in the second system than was exercised in the first system. For managers who were promoted into the wrong role, the second system often reveals how far removed the new job is from the career path they would actually find more rewarding.
One up: I liked the many nuggets Brooks sprinkles throughout this book. These insights drew on repeated themes from the history of computer science to explain common errors or make predictions about the future of the field.
A common idea was how bad managers often revealed their ineptitude through their excitement for The Next Big Thing. One common mistake such managers tend to make is to overestimate the long-term effects of a major work process shift. A transition to a higher-level language might initially bring strong returns. But over time, it becomes evident that the first problems solved after the change were also the ones with the most value. The remaining problems are likely to return less and less value over time. At some point, another big shift will make it possible to pursue more high-value projects. But here, the cycle starts anew. At some point, the practice of making shift after shift will compromise the long-term potential of the team.
The predictions Brooks made about voice technology intrigued me. In the early days of the Alexa Age, it seems to me like there is a lot left to figure out. Brooks, however, came off to me as fairly certain in how he expected voice technology to work with computers. His thoughts were based on simple logic: since the number of objects available to a computer is theoretically infinite while the number of actions a computer can take on a given object is limited to a set of defined functionalities, voice technology will eventually replace functional commands while pointing will remain the norm for identifying objects.
Of course, Brooks’s prediction is likely to apply for either novice or expert users. As he himself points out, most systems are designed with parallel functional features catering to each type of user. In today’s version of Excel, for example, the mouse allows the novice to do everything an expert can do on the keyboard. The future of voice technology might work the same way: a novice user will have the option for voice technology to identify as well as act on objects while the expert will remain content to use the keyboard to more quickly specify objects (examples here including difficult to pronounce objects, those with homonym names, etc).
One down: I got a little lost in some of the technical details here. Brooks seems down on the flowchart concept and suggests that a more reliable way to understand a system is to study the table structures. Why the hate for flowcharts? How else would a lay user know where the data came from?
He also points out how strategic breakthroughs derive almost exclusively from new algorithms and recommends redoing representations of data or tables in order to find these. Huh?
He also makes reference to certain methods for reducing the demands on debugging. Specifically, he suggests using syntax such as IF/THEN/ELSE, LOOP WHILE, or CASE to break up a program into a more easily controlled structure. Again, I could make neither heads nor tails of these ideas.
I was surprised to find such technically detailed writing in a book I was told focused strictly on project management. But then again, I was told these things by The Business Bro - I assume he has no idea what these things mean, either.
Just saying: I got the sense that programmers often worked late at – or perhaps all the way through – the night. Brooks points out how this mentality reflects the efficiency of thinking for a long, unbroken spell. He also notes how programmers generally report that, on average, half a workday is wasted by various non-programming responsibilities such as meetings or documentation.
Putting these two observations together reminded me of what I learned when I studied the various routines of famous writers. Most seemed capable of writing for between two and four hours a day. However, almost all of them did this in one block of time. It wasn’t like Hemingway wrote chapters of The Old Man and The Sea in the five-minutes spaces between his daily errands, you know? He just stood there, had his drink, and went on and on about the Great DiMaggio until he was done…
If the general lesson is true for programming, a good manager would structure the workday so that the administrative demands of the job came at times entirely separate from a daily stretch of long, unbroken time set aside solely for focused programming work.
It occurred to me recently, though, that our conversation was a microcosm of the book’s larger point. As new members are added to a project team, the communication burden will increase. In these cases, the challenge for leaders is to structure the work so the benefit of added manpower is not offset by the increase in communication cost.
This sounds like a simple enough job, I thought, but there are a number of reasons why software development projects struggle to maintain this balance. One reason is the way management demands a skill set entirely different from programming. Software engineers of any value are perfectionists. Otherwise, the programs they write will never run correctly and all their time will go to debugging!
On the other hand, management is work that does not suit the perfectionist. A good manager must constantly make decisions about trade-offs. By definition, the manager’s job is to choose the best set of decisions from a set of imperfect options. Software project mangers who are promoted into the job after excelling as engineers are at a disadvantage because the perfectionism they relied on to reach maximum performance in the programmer role is going to hurt their performance in the manager role.
A specific area where these ‘perfectionist managers’ struggle is when designing the ‘second system’. Often, the second system is intended to replace a no-frills first version. The idea of a second system is exciting for architects because it is an opportunity to include the many ideas for neat designs, features, or capabilities they stored away during the initial design. (By reducing the complexity of the first design, the project was more likely to come in on time or under budget.)
However, overloading the second system with these features is likely to lead to delays in testing. It will also leave less room for other engineers to contribute their own ideas or follow creative tangents during the design process. In many ways, an architect must exercise more self-restraint in the second system than was exercised in the first system. For managers who were promoted into the wrong role, the second system often reveals how far removed the new job is from the career path they would actually find more rewarding.
One up: I liked the many nuggets Brooks sprinkles throughout this book. These insights drew on repeated themes from the history of computer science to explain common errors or make predictions about the future of the field.
A common idea was how bad managers often revealed their ineptitude through their excitement for The Next Big Thing. One common mistake such managers tend to make is to overestimate the long-term effects of a major work process shift. A transition to a higher-level language might initially bring strong returns. But over time, it becomes evident that the first problems solved after the change were also the ones with the most value. The remaining problems are likely to return less and less value over time. At some point, another big shift will make it possible to pursue more high-value projects. But here, the cycle starts anew. At some point, the practice of making shift after shift will compromise the long-term potential of the team.
The predictions Brooks made about voice technology intrigued me. In the early days of the Alexa Age, it seems to me like there is a lot left to figure out. Brooks, however, came off to me as fairly certain in how he expected voice technology to work with computers. His thoughts were based on simple logic: since the number of objects available to a computer is theoretically infinite while the number of actions a computer can take on a given object is limited to a set of defined functionalities, voice technology will eventually replace functional commands while pointing will remain the norm for identifying objects.
Of course, Brooks’s prediction is likely to apply for either novice or expert users. As he himself points out, most systems are designed with parallel functional features catering to each type of user. In today’s version of Excel, for example, the mouse allows the novice to do everything an expert can do on the keyboard. The future of voice technology might work the same way: a novice user will have the option for voice technology to identify as well as act on objects while the expert will remain content to use the keyboard to more quickly specify objects (examples here including difficult to pronounce objects, those with homonym names, etc).
One down: I got a little lost in some of the technical details here. Brooks seems down on the flowchart concept and suggests that a more reliable way to understand a system is to study the table structures. Why the hate for flowcharts? How else would a lay user know where the data came from?
He also points out how strategic breakthroughs derive almost exclusively from new algorithms and recommends redoing representations of data or tables in order to find these. Huh?
He also makes reference to certain methods for reducing the demands on debugging. Specifically, he suggests using syntax such as IF/THEN/ELSE, LOOP WHILE, or CASE to break up a program into a more easily controlled structure. Again, I could make neither heads nor tails of these ideas.
I was surprised to find such technically detailed writing in a book I was told focused strictly on project management. But then again, I was told these things by The Business Bro - I assume he has no idea what these things mean, either.
Just saying: I got the sense that programmers often worked late at – or perhaps all the way through – the night. Brooks points out how this mentality reflects the efficiency of thinking for a long, unbroken spell. He also notes how programmers generally report that, on average, half a workday is wasted by various non-programming responsibilities such as meetings or documentation.
Putting these two observations together reminded me of what I learned when I studied the various routines of famous writers. Most seemed capable of writing for between two and four hours a day. However, almost all of them did this in one block of time. It wasn’t like Hemingway wrote chapters of The Old Man and The Sea in the five-minutes spaces between his daily errands, you know? He just stood there, had his drink, and went on and on about the Great DiMaggio until he was done…
If the general lesson is true for programming, a good manager would structure the workday so that the administrative demands of the job came at times entirely separate from a daily stretch of long, unbroken time set aside solely for focused programming work.
Sunday, January 28, 2018
the bb book club: the mythical man-month
The Mythical Man-Month by Frederick P. Brooks (August 2017)
Good morning,
Welcome back for another round of the Business Bro Book Club. Today’s feature is The Mythical Man-Month by Frederick P. Brooks.
The last time I rolled out the book club concept, my counterpart here got all sniffy about my initiative. For some bosses, I guess 'coming up with a good idea' really means coming up with a good idea they would have come up with.
So, for this week, I invited him over in the spirit of a book club to have a conversation. Hopefully, no feelings get hurt in the process. Please enjoy our TOA-BB collaboration below.
Signed,
The Business Bro
*********
TOA: So, want to summarize the point of this book for the readers?
BB: What, no hello? No how you doin', how you beens?
TOA: I thought you'd prefer to get straight to business? Well, in that case, I've actually been kind of bored, you see-
BB: Ah, no, you had it right the first time, my mistake. Anyway, specifically, Brooks writes for managers of large-scale software development projects.
TOA: Right. Well, having never held such a position myself, I can only speculate on the book’s value for these managers. And since I know you've never-
BB: Quiet, right, I had a good feeling about it. The reviews from other readers were consistently glowing and a lot of what Brooks wrote matched up with my own intuitive sense of the topic. I am comfortable suggesting this book is required reading for those looking to deepen their understanding of this particular role and a decent bet for anyone who wants to learn more about running a project.
TOA: I see. What makes you suggest this book will have appeal beyond just a software project manager?
BB: Well, I think a lot of what Brooks covers is applicable to managers in general. He gets into concepts like growing rather than building a team, for example, which will appeal to anyone with an eye on the long-term challenges of leadership.
TOA: That’s surprising to hear about a book focused on project management.
BB: Why are you surprised?
TOA: Well, I kind of assumed project management was a short-term thing, at least in terms of teams. Once the project is over, everyone goes to do something else.
BB: Wait, well, I’ll get back to that, but I meant why are you surprised to learn this? Didn’t you read the book?
TOA: Why would I read the book?
BB: This is a book club, man, you’re supposed to read the book!
TOA: Still with the book club? Sundays are for reading reviews, I told you to stop with this book club nonsense.
BB: So what did you think the point of coming over was?
TOA: I thought you were gonna talk about the book.
BB: I was, with you!
TOA: Hmmm, I was expecting more like a business meeting, where we talk in clichés and generalities and analogies-
BB: Right, analogies, like how half your posts are written, in analogy, so you can pretend to know what you are talking about.
TOA: Interesting to hear that from you! Actually, not knowing what you are talking about is the only thing you might have any expertise in-
BB: OK, well, whatever, we can have it your way, it's too bad though, since you missed out on some pretty good analogies Brooks was kind enough to include for the clueless reader.
TOA: Why would anything for a clueless reader interest me?
BB: Ha, I see, well, better to never read at all than be clueless, eh? Well, anyway, I was referring to how software projects are prone to being scheduled by your demographic and therefore-
TOA: What demographic?
BB: Clueless customers, clueless workers, cluessless people, clueless. Stop interrupting.
TOA: Whatever.
BB: As I was saying, it’s a lot like going into a seafood restaurant and asking for the meal right away. The chef can tell you to wait or the chef can serve it up raw. A software manager might hem and haw and even arrange a meeting to talk it over with the most sociable guy in engineering.
TOA: Fine with me, I like sushi.
BB: Yeah, right. People like you with no technical savvy don’t get the distinction. Two months later, guess who comes back to complain about a shoddy product?
TOA: That was a stupid analogy. People like you with more suits than knowledge should know better than to serve up a raw meal. If a chef ever screwed up like that, he’d end up fired.
BB: Well, the point is that people who don’t understand the natural schedule shouldn’t try to change the timelines. It’s like how it takes nine months to bear a child. Assigning more women to the job doesn’t bring the baby along any faster.
TOA: That’s the dumbest analogy yet. Only a business bro would even think of using the expression ‘assigning women’ in the context of childbirth.
BB: Whatever-
TOA: Plus, doesn’t that contradict the whole ‘both of us read the book for book club?’ idea? It isn't like if the two of us read it at the same time, it's gonna get read any quicker-
BB: The point is that software projects suffer whenever leaders assume time and manpower are interchangeable. New hires don’t necessarily make the project finish any faster.
TOA: Why would that not be the case?
BB: It’s the nature of software projects, especially large ones. Adding people to the team might reduce the time spent on one part of the assignment. But the new people will have to communicate with the rest of the team. It’s the increased communication burden that slows down the project.
TOA: You don’t need to tell me.
BB: What?
TOA: Never mind.
BB: Right, well as I was saying, if the scope of the project is large enough, the higher communication cost will offset the positive gains from adding manpower.
TOA: Huh. So it’s like having too many cooks in the kitchen?
BB: Sort of, I suppose.
TOA: As long as they don’t serve up raw meals?
BB: Maybe.
TOA: Maybe?
BB: Well, it’s not a bad understanding coming from...an illiterate...
TOA: Excuse me?
BB: I mean, what's the difference if you don't read? Why even know how?
TOA: Oh please, like you ever bother-
BB: Never mind, this is going on too long, anyway, but the problem, I mean, is that cooks generally get involved early in the process. What Brooks really looks at is toward the end. Maybe too many servers at the tables is the better comparison.
TOA: Your analogies need work because you take them too literally.
BB: Your analogies need work because you don’t understand the comparisons.
TOA: You need work.
BB: You can say that again.
TOA: You need work.
BB: Are we done here?
TOA: Wait one second, I did actually want to clarify something else. So this book then is saying - don’t add anyone to projects? Seems simplistic, and a recipe to get sacked.
BB: No.
TOA: But that’s what you said.
BB: I didn’t say that.
TOA: You did.
BB: I said adding people can cause the communication burden to go up.
TOA: That’s the same thing.
BB: What?
TOA: It’s the opposite of the other side, which makes it the same thing.
BB: No, it isn’t. You’re working with a false duality. This is a continuum.
TOA: False duality? Continuum? Are those your words of the day?
BB: I’m saying it’s not like you do the opposite of adding people, what you do is structure the project so it can accommodate more people later.
TOA: And how would you do that, you old business bro, you?
BB: I’m getting there. One way is to add people only to parts of a project where the task is divisible without extra communication.
TOA: That’s obvious.
BB: Right, obvious. I’m stunned by how many concepts you dismiss as ‘obvious’ despite never coming up with any ideas yourself.
TOA: But all you are saying is less talk, more walk?
BB: Well…
TOA: Then it’s obvious.
BB: I think it’s about time you walked.
TOA: Yeah, I’m thinking along those lines, enough talk for now. Same time next week?
BB: What?
TOA: I’ll read the book and come back, I promise.
BB: Oh, don’t bother. I’m going to write my own thing about this book.
TOA: Hmmm, sounds almost like an application of this book.
BB: How?
TOA: Well, by not communicating anymore about it, it’s easier for you to get more ideas across.
BB: Yeah, maybe that’s true, but it's irrelevant.
TOA: I mean, it’s what you just said.
BB: There’s no substitute for the reading.
TOA: OK, fine. I’m gonna do my own review when I finish reading.
BB: That sounds good. We'll need content in 2023.
TOA: How should we split up the topics?
BB: Doesn’t matter to me.
TOA: Well, how about I write my post and you just cover the rest?
BB: You’re the boss, boss.
TOA: OK, then, until next time.
BB: See you later.
Good morning,
Welcome back for another round of the Business Bro Book Club. Today’s feature is The Mythical Man-Month by Frederick P. Brooks.
The last time I rolled out the book club concept, my counterpart here got all sniffy about my initiative. For some bosses, I guess 'coming up with a good idea' really means coming up with a good idea they would have come up with.
So, for this week, I invited him over in the spirit of a book club to have a conversation. Hopefully, no feelings get hurt in the process. Please enjoy our TOA-BB collaboration below.
Signed,
The Business Bro
*********
TOA: So, want to summarize the point of this book for the readers?
BB: What, no hello? No how you doin', how you beens?
TOA: I thought you'd prefer to get straight to business? Well, in that case, I've actually been kind of bored, you see-
BB: Ah, no, you had it right the first time, my mistake. Anyway, specifically, Brooks writes for managers of large-scale software development projects.
TOA: Right. Well, having never held such a position myself, I can only speculate on the book’s value for these managers. And since I know you've never-
BB: Quiet, right, I had a good feeling about it. The reviews from other readers were consistently glowing and a lot of what Brooks wrote matched up with my own intuitive sense of the topic. I am comfortable suggesting this book is required reading for those looking to deepen their understanding of this particular role and a decent bet for anyone who wants to learn more about running a project.
TOA: I see. What makes you suggest this book will have appeal beyond just a software project manager?
BB: Well, I think a lot of what Brooks covers is applicable to managers in general. He gets into concepts like growing rather than building a team, for example, which will appeal to anyone with an eye on the long-term challenges of leadership.
TOA: That’s surprising to hear about a book focused on project management.
BB: Why are you surprised?
TOA: Well, I kind of assumed project management was a short-term thing, at least in terms of teams. Once the project is over, everyone goes to do something else.
BB: Wait, well, I’ll get back to that, but I meant why are you surprised to learn this? Didn’t you read the book?
TOA: Why would I read the book?
BB: This is a book club, man, you’re supposed to read the book!
TOA: Still with the book club? Sundays are for reading reviews, I told you to stop with this book club nonsense.
BB: So what did you think the point of coming over was?
TOA: I thought you were gonna talk about the book.
BB: I was, with you!
TOA: Hmmm, I was expecting more like a business meeting, where we talk in clichés and generalities and analogies-
BB: Right, analogies, like how half your posts are written, in analogy, so you can pretend to know what you are talking about.
TOA: Interesting to hear that from you! Actually, not knowing what you are talking about is the only thing you might have any expertise in-
BB: OK, well, whatever, we can have it your way, it's too bad though, since you missed out on some pretty good analogies Brooks was kind enough to include for the clueless reader.
TOA: Why would anything for a clueless reader interest me?
BB: Ha, I see, well, better to never read at all than be clueless, eh? Well, anyway, I was referring to how software projects are prone to being scheduled by your demographic and therefore-
TOA: What demographic?
BB: Clueless customers, clueless workers, cluessless people, clueless. Stop interrupting.
TOA: Whatever.
BB: As I was saying, it’s a lot like going into a seafood restaurant and asking for the meal right away. The chef can tell you to wait or the chef can serve it up raw. A software manager might hem and haw and even arrange a meeting to talk it over with the most sociable guy in engineering.
TOA: Fine with me, I like sushi.
BB: Yeah, right. People like you with no technical savvy don’t get the distinction. Two months later, guess who comes back to complain about a shoddy product?
TOA: That was a stupid analogy. People like you with more suits than knowledge should know better than to serve up a raw meal. If a chef ever screwed up like that, he’d end up fired.
BB: Well, the point is that people who don’t understand the natural schedule shouldn’t try to change the timelines. It’s like how it takes nine months to bear a child. Assigning more women to the job doesn’t bring the baby along any faster.
TOA: That’s the dumbest analogy yet. Only a business bro would even think of using the expression ‘assigning women’ in the context of childbirth.
BB: Whatever-
TOA: Plus, doesn’t that contradict the whole ‘both of us read the book for book club?’ idea? It isn't like if the two of us read it at the same time, it's gonna get read any quicker-
BB: The point is that software projects suffer whenever leaders assume time and manpower are interchangeable. New hires don’t necessarily make the project finish any faster.
TOA: Why would that not be the case?
BB: It’s the nature of software projects, especially large ones. Adding people to the team might reduce the time spent on one part of the assignment. But the new people will have to communicate with the rest of the team. It’s the increased communication burden that slows down the project.
TOA: You don’t need to tell me.
BB: What?
TOA: Never mind.
BB: Right, well as I was saying, if the scope of the project is large enough, the higher communication cost will offset the positive gains from adding manpower.
TOA: Huh. So it’s like having too many cooks in the kitchen?
BB: Sort of, I suppose.
TOA: As long as they don’t serve up raw meals?
BB: Maybe.
TOA: Maybe?
BB: Well, it’s not a bad understanding coming from...an illiterate...
TOA: Excuse me?
BB: I mean, what's the difference if you don't read? Why even know how?
TOA: Oh please, like you ever bother-
BB: Never mind, this is going on too long, anyway, but the problem, I mean, is that cooks generally get involved early in the process. What Brooks really looks at is toward the end. Maybe too many servers at the tables is the better comparison.
TOA: Your analogies need work because you take them too literally.
BB: Your analogies need work because you don’t understand the comparisons.
TOA: You need work.
BB: You can say that again.
TOA: You need work.
BB: Are we done here?
TOA: Wait one second, I did actually want to clarify something else. So this book then is saying - don’t add anyone to projects? Seems simplistic, and a recipe to get sacked.
BB: No.
TOA: But that’s what you said.
BB: I didn’t say that.
TOA: You did.
BB: I said adding people can cause the communication burden to go up.
TOA: That’s the same thing.
BB: What?
TOA: It’s the opposite of the other side, which makes it the same thing.
BB: No, it isn’t. You’re working with a false duality. This is a continuum.
TOA: False duality? Continuum? Are those your words of the day?
BB: I’m saying it’s not like you do the opposite of adding people, what you do is structure the project so it can accommodate more people later.
TOA: And how would you do that, you old business bro, you?
BB: I’m getting there. One way is to add people only to parts of a project where the task is divisible without extra communication.
TOA: That’s obvious.
BB: Right, obvious. I’m stunned by how many concepts you dismiss as ‘obvious’ despite never coming up with any ideas yourself.
TOA: But all you are saying is less talk, more walk?
BB: Well…
TOA: Then it’s obvious.
BB: I think it’s about time you walked.
TOA: Yeah, I’m thinking along those lines, enough talk for now. Same time next week?
BB: What?
TOA: I’ll read the book and come back, I promise.
BB: Oh, don’t bother. I’m going to write my own thing about this book.
TOA: Hmmm, sounds almost like an application of this book.
BB: How?
TOA: Well, by not communicating anymore about it, it’s easier for you to get more ideas across.
BB: Yeah, maybe that’s true, but it's irrelevant.
TOA: I mean, it’s what you just said.
BB: There’s no substitute for the reading.
TOA: OK, fine. I’m gonna do my own review when I finish reading.
BB: That sounds good. We'll need content in 2023.
TOA: How should we split up the topics?
BB: Doesn’t matter to me.
TOA: Well, how about I write my post and you just cover the rest?
BB: You’re the boss, boss.
TOA: OK, then, until next time.
BB: See you later.
Subscribe to:
Comments (Atom)