Skip to content

Commit 22afa3c

Browse files
committed
Updated practices to follow common format
1 parent b395e74 commit 22afa3c

35 files changed

+273
-201
lines changed

docs/practices/Development-And-Coding/Coding.md

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -36,9 +36,15 @@ practice:
3636
3737
Coding is a core activity in software development, involving the translation of requirements and designs into functional code. High-quality coding practices are essential for creating reliable, maintainable, and efficient software. This involves writing clear, well-structured, and documented code that adheres to established standards and best practices.
3838

39-
See:
39+
## Variations
4040

41-
- [Time/Reality Tradeoff](/thinking/Cadence#time--reality-trade-off)
41+
| **Coding Style** | **Description** | **Reference** |
42+
|---------------------------|---------------------------------------------------------------------------------------------------|---------------|
43+
| **Test-Driven Development** | Writing tests before code to guide implementation and ensure coverage. | [Test-Driven Development, Wikipedia](https://en.wikipedia.org/wiki/Test-driven_development) |
44+
| **Behaviour-Driven Development** | Writing code based on expected behaviour described in natural language. | [Behaviour-Driven Development, Wikipedia](https://en.wikipedia.org/wiki/Behavior-driven_development) |
45+
| **Literate Programming** | Embedding code within documentation to explain logic alongside implementation. | [Literate Programming, Wikipedia](https://en.wikipedia.org/wiki/Literate_programming) |
46+
47+
See also: [Time/Reality Tradeoff](/thinking/Cadence#time--reality-trade-off)
4248

4349
## Used By
4450

docs/practices/Development-And-Coding/Debugging.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -36,6 +36,13 @@ practice:
3636
3737
Debugging in software development involves identifying, analyzing, and fixing defects or issues within the software. This practice is crucial for ensuring that the software operates correctly and efficiently, improving its reliability and stability. Effective debugging helps in maintaining the overall quality of the software and minimizing the risk of operational failures.
3838

39+
## Variations
40+
41+
| **Debugging Approach** | **Description** | **Reference** |
42+
| ------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
43+
| **Print Debugging** | Inserting print statements to trace program execution and variable values. | [Debugging, Wikipedia](https://en.wikipedia.org/wiki/Debugging#Techniques) |
44+
| **Interactive Debugging** | Using a debugger tool to step through code, set breakpoints, and inspect state. | [Debugger, Wikipedia](https://en.wikipedia.org/wiki/Debugger) |
45+
3946
## Used By
4047

4148
<MethodList tag="Debugging" />

docs/practices/Development-And-Coding/Dependency-Adoption.md

Lines changed: 12 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -38,14 +38,20 @@ practice:
3838

3939
## Description
4040

41-
Making use of third-party libraries or services in your code.
41+
> "In software engineering, a software library is a collection of code that can be reused across different programs to provide commonly needed functionality." - [Library, _Wikipedia_](<https://en.wikipedia.org/wiki/Library_(computing)>)
4242
43-
See:
43+
Making use of third-party libraries or services in your code can dramatically reduce development time and leverage battle-tested solutions.
4444

45-
- [Languages and Dependencies](/risks/Kolmogorov-Complexity#languages-and-dependencies)
46-
- [Software Libraries (On Software Dependencies)](/risks/On-Software-Dependencies#2-software-libraries)
47-
- [Software-as-a-Service (On Software Dependencies)](/risks/On-Software-Dependencies#3--software-as-a-service)
45+
## Variations
46+
47+
| **Dependency Type** | **Description** | **Reference** |
48+
| ------------------------- | ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
49+
| **Software Library** | Reusable code packages that provide specific functionality (e.g., React, Lodash). | [Library, Wikipedia](<https://en.wikipedia.org/wiki/Library_(computing)>) |
50+
| **Framework** | A larger structure that provides scaffolding and dictates application architecture. | [Software Framework, Wikipedia](https://en.wikipedia.org/wiki/Software_framework) |
51+
| **Software-as-a-Service** | External services accessed via APIs (e.g., Stripe, AWS). | [Software as a Service, Wikipedia](https://en.wikipedia.org/wiki/Software_as_a_service) |
52+
53+
See also: [Languages and Dependencies](/risks/Kolmogorov-Complexity#languages-and-dependencies), [Software Libraries](/risks/On-Software-Dependencies#2-software-libraries), [Software-as-a-Service](/risks/On-Software-Dependencies#3--software-as-a-service)
4854

4955
## Used By
5056

51-
<MethodList tag="Library Adoption" />
57+
<MethodList tag="Dependency Adoption" />

docs/practices/Development-And-Coding/Pair-Programming.md

Lines changed: 8 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -44,9 +44,15 @@ practice:
4444
4545
Pair Programming involves two developers working together on the same code. One developer writes the code while the other reviews each line in real-time, providing instant feedback and suggestions. This practice not only improves code quality but also facilitates knowledge sharing and collaboration between team members.
4646

47-
See:
47+
## Variations
4848

49-
- [Crisis Mode](/thinking/Crisis-Mode)
49+
| **Pairing Style** | **Description** | **Reference** |
50+
| --------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
51+
| **Driver-Navigator** | One developer writes code (driver) while the other reviews and guides (navigator). | [Pair Programming, Wikipedia](https://en.wikipedia.org/wiki/Pair_programming) |
52+
| **Ping-Pong Pairing** | Developers alternate writing tests and implementation code in a TDD style. | [Ping Pong Pair Programming](https://anthonysciamanna.com/2015/04/18/ping-pong-pair-programming.html) |
53+
| **Mob Programming** | The entire team works together on a single task at one computer. | [Mob Programming, Wikipedia](https://en.wikipedia.org/wiki/Mob_programming) |
54+
55+
See also: [Crisis Mode](/thinking/Crisis-Mode)
5056

5157
## Used By
5258

docs/practices/Development-And-Coding/Prototyping.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -38,6 +38,14 @@ practice:
3838
3939
Prototyping in software development involves creating early models or mockups of the software to test concepts and gather feedback. This practice helps in validating design choices, identifying potential issues, and ensuring that the final product meets the users' needs and expectations.
4040

41+
## Variations
42+
43+
| **Prototype Type** | **Description** | **Reference** |
44+
| -------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
45+
| **Throwaway Prototype** | A quick model built to explore ideas, then discarded once requirements are clear. | [Throwaway Prototyping, Wikipedia](https://en.wikipedia.org/wiki/Software_prototyping#Throwaway_prototyping) |
46+
| **Evolutionary Prototype** | A working model that is refined iteratively into the final product. | [Evolutionary Prototyping, Wikipedia](https://en.wikipedia.org/wiki/Software_prototyping#Evolutionary_prototyping) |
47+
| **Wireframe/Mockup** | Low-fidelity visual representations of the UI without functionality. | [Wireframe, Wikipedia](https://en.wikipedia.org/wiki/Website_wireframe) |
48+
4149
## Used By
4250

4351
<MethodList tag="Prototyping" />

docs/practices/Development-And-Coding/Refactoring.md

Lines changed: 3 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -43,21 +43,12 @@ practice:
4343
4444
Refactoring involves revising and restructuring existing code to improve its readability, maintainability, and performance without changing its external behavior. This practice helps in reducing technical debt, enhancing code quality, and making the codebase easier to understand and modify.
4545

46-
## Abstractions
47-
48-
Refactoring is all about ensuring you have the right abstractions.
49-
50-
> "An abstraction" is the outcome of this process—a concept that acts as a common noun for all subordinate concepts and connects any related concepts as a group, field, or category.
51-
52-
See:
46+
## See Also:
5347

5448
- [Refactoring](/risks/Kolmogorov-Complexity#refactoring)
5549
- [Hierarchies and Modularisation](/risks/Connectivity#hierarchies-and-modularisation)
56-
57-
## External References
58-
59-
- [Separation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns) Wikipedia Page.
60-
- [Refactoring](https://martinfowler.com/books/refactoring.html) Book by Martin Fowler.
50+
- [Separation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)
51+
- [Refactoring Book](https://martinfowler.com/books/refactoring.html)
6152

6253
## Used By
6354

docs/practices/Development-And-Coding/Standardisation.md

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -43,7 +43,15 @@ practice:
4343
4444
Standardisation involves creating, implementing, and enforcing standards and guidelines to ensure consistency, compatibility, and quality across software projects. This practice helps in maintaining uniformity, reducing complexity, and improving communication among team members and stakeholders.
4545

46-
See:
46+
## Variations
47+
48+
| **Standard Type** | **Description** | **Reference** |
49+
| ---------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
50+
| **Coding Standards** | Guidelines for code style, naming conventions, and best practices. | [Coding Conventions, Wikipedia](https://en.wikipedia.org/wiki/Coding_conventions) |
51+
| **API Standards** | Specifications for how APIs should be designed and documented. | [OpenAPI, Wikipedia](https://en.wikipedia.org/wiki/OpenAPI_Specification) |
52+
| **Industry Standards** | External standards like ISO, W3C, or IETF that software must comply with. | [Technical Standard, Wikipedia](https://en.wikipedia.org/wiki/Technical_standard) |
53+
54+
## See Also
4755

4856
- [Unwritten Software (On Software Dependencies)](/risks/On-Software-Dependencies#unwritten-software)
4957

docs/practices/Development-And-Coding/Tool-Adoption.md

Lines changed: 8 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -40,29 +40,17 @@ practice:
4040

4141
> "Software tools are programs and utilities that help developers create, debug, maintain, or otherwise support software development." - [Software tool, _Wikipedia_](https://en.wikipedia.org/wiki/Software_tool)
4242
43-
Tool Adoption in software development involves implementing and utilizing specific tools to enhance the development process. This includes tools for coding, debugging, testing, and project management. The use of appropriate tools helps in improving efficiency, quality, and collaboration among team members.
43+
Tool Adoption involves implementing and utilizing specific tools to enhance the development process. Unless a problem is _specific to your circumstances_, it's often better to adopt proven tools rather than building from scratch. Tools are worth using if they offer a better risk return than not using them—and some tools (compilers, type systems, garbage collection, build tools) offer such _amazing_ returns that not using them becomes unthinkable.
4444

45-
## Discussion
45+
However, picking new tools should be done **carefully**: you may be stuck with your choices for some time. See [On Software Dependencies](/risks/On-Software-Dependencies) for guidance.
4646

47-
### Tool Use
47+
## Variations
4848

49-
In general, unless the problem is somehow _specific to your circumstances_ it may well be better to skip direct coding and pick up some new tools to help with the job.
50-
51-
Tools in general are _good_ and _worth using_ if they offer you a better risk return than you would have had from not using them.
52-
53-
But, this is a low bar - some tools offer _amazing_ returns on investment:
54-
55-
- Assemblers
56-
- Compilers
57-
- Garbage Collection
58-
- Type Systems
59-
- Libraries
60-
- Build Tools
61-
- etc.
62-
63-
A _really good tool_ offers such advantages that not using it becomes _unthinkable_: Linux is heading towards this point. For Java developers, the JVM is there already.
64-
65-
Picking new tools and libraries should be done **very carefully**: you may be stuck with your choices for some time. Here is a [short guide that might help](/risks/On-Software-Dependencies).
49+
| **Tool Category** | **Description** | **Reference** |
50+
| ----------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- |
51+
| **IDEs** | Integrated Development Environments for writing, debugging, and testing. | [IDE, Wikipedia](https://en.wikipedia.org/wiki/Integrated_development_environment) |
52+
| **Build Tools** | Tools for compiling, packaging, and managing dependencies. | [Build Automation, Wikipedia](https://en.wikipedia.org/wiki/Build_automation) |
53+
| **Collaboration Tools** | Tools for team communication and project tracking. | [Collaborative Software, Wikipedia](https://en.wikipedia.org/wiki/Collaborative_software) |
6654

6755
## Used By
6856

docs/practices/Development-And-Coding/Version-Control.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,14 @@ practice:
3434
3535
Version Control in software development involves using systems that track changes to the codebase over time. This practice allows developers to manage versions, collaborate on code, and revert to previous states if necessary. Version control is essential for maintaining the integrity and history of the project.
3636

37+
## Variations
38+
39+
| **Version Control Type** | **Description** | **Reference** |
40+
|---------------------------|---------------------------------------------------------------------------------------------------|---------------|
41+
| **Distributed VCS** | Every developer has a full copy of the repository (e.g., Git, Mercurial). | [Distributed Version Control, Wikipedia](https://en.wikipedia.org/wiki/Distributed_version_control) |
42+
| **Centralised VCS** | A single central repository that developers commit to (e.g., SVN, CVS). | [Version Control, Wikipedia](https://en.wikipedia.org/wiki/Version_control#Centralized_version_control) |
43+
| **Trunk-Based Development** | All developers work on a single branch with frequent small commits. | [Trunk-Based Development](https://trunkbaseddevelopment.com/) |
44+
3745
## Used By
3846

3947
<MethodList tag="Version Control" />

docs/practices/External-Relations/Analysis.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,14 @@ Analysis in software development involves examining and breaking down the requir
4949

5050
Analysis is also important as a tool to understand the environment that your software will run in. See [Environmental Risks](/tags/Environmental-Risks).
5151

52+
## Variations
53+
54+
| **Analysis Type** | **Description** | **Reference** |
55+
| ------------------------ | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
56+
| **Business Analysis** | Understanding business needs and translating them into requirements. | [Business Analysis, Wikipedia](https://en.wikipedia.org/wiki/Business_analysis) |
57+
| **Systems Analysis** | Examining technical systems to understand their components and interactions. | [Systems Analysis, Wikipedia](https://en.wikipedia.org/wiki/Systems_analysis) |
58+
| **Competitive Analysis** | Studying competitors to understand market positioning and opportunities. | [Competitor Analysis, Wikipedia](https://en.wikipedia.org/wiki/Competitor_analysis) |
59+
5260
## Used By
5361

5462
<MethodList tag="Analysis" />

0 commit comments

Comments
 (0)