 You know they say that one month out of the year you can see manta rays off the north coast of kawaii, but personally I don't believe in a new mythical man In 1975 Fred Brooks published a book titled the mythical man month where he laid out several lessons He learned in his many years as a successful software engineer and project manager Some of these are clearly relics of their time in place like in discussing good practices for documenting code He notes among all tools the one that saves the most labor may well be a computerized text editing system He also thanks one of his colleagues for coding a text editor for his team to use Thanks Fred. I'll get someone on that But a number of his observations have a timeless quality with a few valuable insights about design that can be applied just about anywhere There's also something that feels pragmatic and battle-tested about Brooks's framing of these points as though he's honed his arguments over a Thousand weary meetings with various managers and investors who didn't really get it I think they're useful concepts both for framing thoughts about large design projects and for communicating their intricacies Brooks titled the book after a particularly annoying and persistent misconception That the completion of a task like a large system programming project Could always be accelerated by adding more people that people in time are interchangeable If one programmer could complete a project in one month It seems like two programmers should be able to complete it in half a month That approach works fine for things like folding laundry Manufacturing or taking inventory many hands make light work But Brooks noted that for certain kinds of problems adding more people even bright competent people Might not just be useless but can get you further from your goal The wrinkle is partitioning and coordination If the task you're trying to complete doesn't require any significant planning or communication with others You can just throw manpower at it until it's done But as soon as you need to invest some amount of thought in how to break the work up productively Both by creating discrete tasks and synchronizing information across team members Each additional person you add increases the cost of that overhead for everyone involved combinatorially Add one person to a 10-person project and you just added 10 new ways for a directive to get lost or corrupted in transmission 10 new ways for something to fall through the cracks At some point carefully carving out a new set of subtasks and adding another point of contact for everyone to keep up with Fastly exceeds any additional productivity you might get out of another set of hands and you're ultimately faced with Brooks's law Adding manpower to a late software project Makes it later an interesting corollary of this observation is the tremendous Impact coordination tools have on the ability for a team to work efficiently together You may have had the experience of Repeatedly slogging through some Byzantine set of forms or outmoded software to try to keep your co-workers in the loop Feeling like most of your time was spent on that rather than on actual work It might not have been your imagination with a team that's too large and a tool that's too unwieldy Whether it's time-consuming meetings or a shared database struggling near its capacity It's possible that the best thing you could do to accelerate your team's schedule would be to quit One 1984 edition of info world magazine Posited that to get a project done on time software companies should institute something called the Bermuda plan In which 90% of the coders are put on a boat to Bermuda and the last 10% finish the job With that book titling observation out of the way Brooks advances a compelling case For his philosophy of system design which appropriately pivots on one central idea conceptual integrity the argument goes something like this software or Really any technology exists to enable someone to achieve a goal But there's always some amount of figuring out how to go about using the tool to achieve that goal The best designs make that process instantaneous by harnessing enormous power and making it effortless to wield So the user can grasp them immediately and use them to complete complex tasks with little training or specialized know-how Both parts of that equation are necessary a tool. That's easy to use But doesn't do much is just as useless as a tool. That's incredibly powerful and totally opaque Brooks posits that the key to creating that sort of harmony between function and understanding is a single crystal-clear vision for how the tool should work One concept instantiated in every element of the design that when fully grasped by the user Allows them to interface with it exactly as the designer intended without thinking about it Every deviation or dilution of that unified vision whether due to miscommunication technical limitations errors competing ideas whatever will compromise the conceptual Cohesion of the technology which will disrupt the user's ability to internalize and employ it of course thinking of good design as a direct result of high conceptual integrity is something of a simplification anyone who's seen ridiculous failures of auteur art can tell you that the most authentic execution of a crap idea is still crap But considering Brooks's difficulties with the eponymous man month fallacy It's not hard to see why he might make a big deal about clarity of vision as the sole measure of successful implementation Just as one might imagine adding more hands to a project would necessarily make it finish faster So too might want to imagine that having a diversity of ideas of what would make the best possible program Would improve the final result It's an easy mistake to make and it's been the kiss of death for many projects a diversity of ideas often leads to Design by committee which invariably results in a muddled set of half-hearted features Compromises and bizarrely conflicting specifications one person thought it should be quick and lightweight one person thought it should be rich with features So it's neither User controls live in all sorts of different and bewildering places depending on where the myriad architects of those features Preferred to place them in every facet of the thing there's a confusing mess of cross purposes leaving the user both helpless to find anything and Powerless to do what they wanted to do in the first place It's interesting to consider design as a process of clarifying and implementing a notion into a real thing Whether it's a piece of software an aesthetic painting or a device I certainly make use of a mental framework that resembles something like Brooks's model when I'm doing design like activities As if I'm trying to crystallize a thought to the point of being wholly unambiguous in what it requires With no internal inconsistencies or vagueness hiding in its details at which point creating it becomes trivial It seems especially well suited to programming as the field can be described as creating layers of abstraction That represent the straightest line from human concepts to the behavior of computers If you have the right idea, you're Basically done coding the mythical man month and conceptual integrity are both useful ways to talk about the unique nature of design and problem Highlighting what makes them different from other sorts of activities and why it's so challenging to scale them up Obviously, it's possible to break problems into chunks and solve them faster with a team Successful organizations do it all the time, but it can be frustrating to explain the additional set of challenges involved in that process And where it can be decidedly anti productive, which is where Brooks's colorful metaphors can be useful Well, it takes one woman nine months to make one baby nine women can't make a baby in one month That's good stuff. Is conceptual integrity a good ideal for designers to aspire to? What do you think of the myth of the man month? Have you ever experienced it? Please leave a comment below and let me know What you think thank you very much for watching. Don't forget to Bob on subscribe while I share and don't stop thunking