Init

Career/Resources/The Mythical Man Month/Ch 1. The Tarpit.md

@@ -0,0 +1 @@
+Not much to say.

Career/Resources/The Mythical Man Month/Ch 10. The Documentary Hypothesis.md

@@ -0,0 +1,9 @@
+Critical documents for building a software product include:
+
+- Objectives: This document outlines the specific needs to be met, along with goals, constraints, and priorities.
+- Specifications: This document includes both the manual and performance specifications. It is typically one of the first documents generated and one of the last to be finalized.
+- Schedule
+- Budget: This document not only serves as a constraint but also acts as a tool to drive decision-making and the creation and management of policies.
+- Organization Chart: This document defines the hierarchical structure of the project team, highlighting the roles and responsibilities of each member.
+- Space Allocations: This document determines how physical or virtual spaces will be allocated for different project activities and resources.
+- Estimate, forecast, prices.

Career/Resources/The Mythical Man Month/Ch 11. Plan to Throw One Away.md

@@ -0,0 +1,11 @@
+In most projects, the first system build is barely useable. The question is not weither to build this pilot system, you will anyway. The question is weither or not to expose the customer to this system. Doing so wil result in distractions to the builder while they redesign and a bad reputation. So plan to throw pilots away, you will anyhow.
+
+Change will happen and thus should be embrassed. To do this the ability to change should be build in the system. And in the team.
+
+The last reason to throw away is that as a system is used, fixed, maintanced and expanded. Entropy will increase ountill the system devolves into unmaintanable obsulasence
+
+In most projects, the initial system build is often not fully functional. The decision to build this pilot system is not a question, as it is usually necessary. However, the important consideration is whether or not to expose the customer to this system. Doing so can result in distractions for the builders as they work on redesigning. Also this will lead to a negative reputation. So plan to throw pilots away, you will anyhow.
+
+Change is an inherent part of any project, and it should be embraced. It is crucial to incorporate the ability to adapt and accommodate changes both in the system itself and within the team.
+
+Another compelling reason to dispose of systems is that over time, as the system is used, fixed, maintained, and expanded, entropy increases. This gradual increase in disorder and complexity can render the system obsolete and extremely challenging to maintain.

Career/Resources/The Mythical Man Month/Ch 12. Sharp Tools.md

@@ -0,0 +1 @@
+Is about the need for good tools and examples from decade ago.

Career/Resources/The Mythical Man Month/Ch 14. Hatching a Catastrophe.md

@@ -0,0 +1 @@
+Schedule slippage is not typically caused by large events, as those events often prompt immediate action. It is the accumulation of unnoticed small issues that leads to delays. Hence, the implementation of milestones becomes essential.

Career/Resources/The Mythical Man Month/Ch 15. The Other Face.md

@@ -0,0 +1,16 @@
+User-facing documentation should include the following;
+
+1. How to use a program:
+    - Purpose: Clearly state the main function of the program.
+    - Environment: Specify the necessary hardware and configurations.
+    - Domain and Range: Define the input and output parameters.
+    - Implemented Functions and Algorithms: Explain the precise workings of the program.
+    - Options: Outline available customization or settings.
+    - Running Time: Provide information on the program's performance.
+    - Accuracy and Checking: Describe the program's reliability and verification methods.
+2. How to validate a program: Present a brief demonstration to prove the system's functionality, including:
+    - The main use case.
+    - An edge case where the system barely functions.
+    - An alternative edge case to show the system's capabilities.
+3. How to modify a program:
+    - Provide instructions on making changes or updates to the program.

Career/Resources/The Mythical Man Month/Ch 2. The Mythical Man Month.md

@@ -0,0 +1,13 @@
+The reasons why estimations often go awry are multifaceted. Firstly, estimating techniques are often poor and can fail to accurately predict the time and resources required for a project. Furthermore, these techniques can confuse effort with progress and assume that men and months are interchangeable, which is not always the case.
+
+Another reason why estimations can go wrong is due to uncertainty, which can lead to a lack of stubbornness in adhering to schedules. Additionally, schedules are often not monitored, and schedule slippage is often countered with increased manpower. This can result in a further decrease in productivity due to communication issues and the time it takes for new team members to become familiar with the project.
+
+Programmers are often optimistic, perhaps due to their youth, and assume that there will be little implementation difficulty in their work.
+
+Due to the absence of productivity and bug incidence figures, estimates can be inherently poor. However, in such cases, programmers should stick to their estimations rather than engaging in wishful thinking.
+
+The man-month measure is only useful when no communication is needed between workers. However, communication is necessary for effective project management and can become increasingly difficult as the number of workers increases. The effort of communication must be factored into the estimation process, as training grows linearly with the number of workers and intercommunication grows exponentially.
+
+System tests are the most challenging part of a project and are often done last, resulting in the greatest cost. A recommended schedule for a project would be to allocate one-third of the time to planning, one-sixth to coding, one-quarter to component testing, and one-quarter to system testing.
+
+When faced with schedule slippage, it is important to ask whether the original estimate was too low locally or universally. The cost of adding more men is N times the training, and communication can become exponentially harder. Finally, the number of men required is dependent on the number of individual subtasks.

Career/Resources/The Mythical Man Month/Ch 3. The Surgical Team.md

@@ -0,0 +1,12 @@
+While small teams of 10x developers are preferred, even these teams cannot be as productive as very large teams. However, by dividing large tasks into smaller segments and utilizing teams of specialized people, productivity can be increased.
+
+Mills proposes that large tasks should be divided into smaller segments, each dealt with by a team of specialists, similar to a surgical team. The team should consist of the following roles:
+
+- **The Surgeon (Chief Programmer):** Defines the functional and performance specifications, codes, tests, and writes documentation.
+- **The Copilot:** Works closely with the surgeon and performs similar tasks but with less experimentation.
+- **The Administrator:** Has the final say on personnel, teams, and expenses but should not spend any time dealing with them. This person can serve multiple teams.
+- **The Editor:** Responsible for documentation, takes drafts from the surgeon, and reworks them into a coherent whole.
+- **Secretaries:** Assist the administrator and editor with correspondence and non-product files.
+- **The Program Clerk:** Maintains technical records in a programming product library, ensuring all information is available to the team, and relieves programmers of clerical chores.
+- **The Toolsmith:** Ensures the surgeon has the necessary tools and assists with testing by supplying data and planning test sequences.
+- **The Language Lawyer:** A specialist in language or framework who can serve multiple surgeons.

Career/Resources/The Mythical Man Month/Ch 4. Aristocracy, Democracy, and System Design.md

@@ -0,0 +1,5 @@
+### Conceptual Integrity
+
+According to Brooks, the most crucial factor to consider in system design is to implement a single set of design ideas and to omit anomalous features and improvements, regardless of their quality. To achieve this, a single or a few like-minded individuals should be responsible for the design, which limits the number of people who can work on the system. However, Brooks offers two solutions to this limitation. The first is to separate the architecture from implementation, and the second is to form teams as described in previous chapters.
+
+The system architect's primary responsibility should be to prioritize the user's needs above all other considerations.

Career/Resources/The Mythical Man Month/Ch 5. The Second-System Effect.md

@@ -0,0 +1,3 @@
+An architect's initial work tends to be spare and clean due to their lack of knowledge and experience, which causes them to exercise restraint. However, as they gain more experience and knowledge, they encounter numerous frills and embellishments that they may want to incorporate into their designs in the future. This can lead to the creation of overly complex and risky systems, making the second iteration of a design the most dangerous one.
+
+To avoid this danger, it's important to keep asking yourself whether any additional compute, time, or effort is truly necessary for the system to function effectively. By maintaining a focus on simplicity and avoiding the temptation to add unnecessary features, an architect can create a robust and efficient system that meets the needs of its users without introducing unnecessary complexity or risk.

Career/Resources/The Mythical Man Month/Ch 6. Passing The Word.md

@@ -0,0 +1,5 @@
+The manual, or written specifications, is an essential tool for the implementation of a system. Any changes made during the implementation should be dated and quantified to ensure that the implementer knows what has changed and which decisions supersede others.
+
+The manual should describe how the user sees and interacts with the system but not the underlying technical details, which is the responsibility of the implementer. However, the architect should be able to provide guidance on the implementation.
+
+When writing the manual, it's important to choose a formal or informal tone and clearly mark any secondary tone. During the implementation, the architecht should keep a log of even minor complaints and questions and resolve them in bulk during a meeting.

Career/Resources/The Mythical Man Month/Ch 7. Why Did the Tower of Babel Fail.md

@@ -0,0 +1,20 @@
+Communication between programs should occur through as many channels as possible.
+
+- Informal communication: Clear definitions of intergroup dependencies can encourage informal communication among teams.
+- Meetings: Regular meetings can be held, where one team or programmer presents technical details. This can help to identify and resolve misunderstandings.
+- Project Workbook: A formal project workbook can be created to document the technical details of the project and serve as a reference for all teams involved.
+
+## Project Workbook
+
+The project workbook should define a structured framework for organizing all documents related to the project. It should include, at a minimum, the following sections:
+
+- Objectives
+- External Specifications
+- Interface Specifications
+- Technical Standards
+- Internal Specifications
+- Administrative Memoranda
+
+One of the challenges of using a project workbook is that it requires everyone involved to read it. Therefore, it should be easily accessible, and users should be able to quickly see any changes made to the document, without having to re-read the entire document.
+
+However, not everyone may be comfortable with this approach, as some may prefer to shield individuals from unnecessary complexity. This approach requires that all interfaces are complete and that the necessary documentation is in place.

Career/Resources/The Mythical Man Month/Ch 8. Calling the shot.md

@@ -0,0 +1 @@
+Not much to say.

Career/Resources/The Mythical Man Month/Ch 9. Ten Pounds in a Five-Pound Sack.md

@@ -0,0 +1 @@
+Deals with space constraints, which is not really a problem any more.

Career/Resources/The Mythical Man Month/The Mythical Man Month.md

@@ -0,0 +1,13 @@
+[[Ch.1 The Tarpit]]
+[[Ch.2 The Mythical Man Month]]
+The chapter discusses the reasons why estimations often go wrong, including poor estimating techniques, confusion between effort and progress, and optimistic assumptions. Uncertainty, lack of schedule monitoring, and adding manpower to counter schedule slippage can further decrease productivity due to communication issues. The man-month measure is only useful when no communication is needed between workers, and the effort of communication must be factored into the estimation process. System tests are the most challenging part of a project and should be allocated one-quarter of the time. When faced with schedule slippage, it is important to determine if the original estimate was too low locally or universally, as adding more men can be costly and communication can become exponentially harder. The number of men required is dependent on the number of individual subtasks.
+> In order to improve the accuracy of our estimations, it is crucial to obtain more reliable and precise productivity figures. Specifically, we should focus on gathering data about the amount of time spent on improvement, adjustment, and debugging as compared to the time spent on building.
+> 
+> So for HGBI we should start labeling ticket correctly.
+
+### [[Ch.3 The Surgical Team]]
+The text discusses Mills' proposal for increasing productivity by dividing large tasks into smaller segments and utilising teams of specialised individuals, similar to a surgical team. The proposed team consists of a surgeon or chief programmer, copilot, administrator, editor, secretaries, program clerk, toolsmith, and language lawyer. The text also notes that while small teams of 10x developers are preferred, even they cannot be as productive as very large teams.
+
+>If we where to do this we would need to split of the secretary and the administrator. Also we need to start having an editor. 
+
+>If we where to do this, we need better communication. Our specialists are being bogged down as they also serve as surgeons or copilots.