3 ms·

How we store our documents; how we structure our work: This is a constant background channel of communication to the entire team, working tirelessly every momen

How we store our documents; how we structure our work: This is a constant background channel of communication to the entire team, working tirelessly every moment of every day. It strongly influences how we think about our work, and is one of the best ways we have of influencing the engineering culture of our organisation. Melvin Conway: "Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." The way that we organise our filing system is nothing less than the (asynchronous) communications structure of the organisation, and needs to be architected with the same care and attention to detail. By the same token, no single scheme will fit all organisations, and each team should seek to find a way of structuring their work that plays to their strengths and gives them a unique competitive advantage. Here are my thoughts from over the years: https://softwareengineering.stackexchange.com/questions/14582/how-do-you-organize-your-projects-folders/128383#128383 https://softwareengineering.stackexchange.com/questions/1458... https://softwareengineering.stackexchange.com/questions/81899/how-should-i-organize-my-source-tree/123184#123184 https://softwareengineering.stackexchange.com/questions/8189... https://github.com/wtpayne/hiai/tree/master/a3_src https://github.com/wtpayne/hiai/tree/master/a3_src

w_t_payne 8y ago
Whenever we impose a structure onto a set of objects, we also impose our values. Nowhere is this clearer than when the structure is hierarchical. Divisions close to the root of the tree implicitly carry a greater weight of importance than those close to the leaves. This property means that it is difficult to find compromise within a single hierarchy; a driving force behind the prevalence of flat 'tagging' mechanisms. In spite these drawbacks, the very rigidity of hierarchies offers us an unparalleled communications opportunity: The distinctions that we make at the root of the tree are highly visible and send a clear message about the divisions and items that we consider important. Is it important that tests be kept separate from product logic? Is it important that projects be kept distinct from one another? Is it important that each component or service be kept isolated? How about maturity? Is it important that research code be kept distinct from production code? We have the opportunity to form a strong opinion, to make a lasting choice, and to shape the culture and the attitudes of those who follow.

w_t_payne 8y ago

Whenever we impose a structure onto a set of objects, we also impose our values. Nowhere is this clearer than when the structure is hierarchical. Divisions close to the root of the tree implicitly carry a greater weight of importance than those close to the leaves. This property means that it is difficult to find compromise within a single hierarchy; a driving force behind the prevalence of flat 'tagging' mechanisms. In spite these drawbacks, the very rigidity of hierarchies offers us an unparalleled communications opportunity: The distinctions that we make at the root of the tree are highly visible and send a clear message about the divisions and items that we consider important. Is it important that tests be kept separate from product logic? Is it important that projects be kept distinct from one another? Is it important that each component or service be kept isolated? How about maturity? Is it important that research code be kept distinct from production code? We have the opportunity to form a strong opinion, to make a lasting choice, and to shape the culture and the attitudes of those who follow.