This problem is sometimes referred to as communication complexity and can be a problem for teams.\nIt also has implications for systems architecture and probably elsewhere.<\/p>\n\n\n\n
One person by themselves doesn’t have to worry about synchronising their work with anyone.\nThere is no communication overhead.\nOn the other hand, it’s just one person so big tasks will take a long time.<\/p>\n\n\n\n
Growing the team means there are more people to do the work but\nchecks must be made to ensure everything is compatible.<\/p>\n\n\n\n More people means exponentially more checks. More time being “wasted” on coordination.\nOf course is not really wasted but it is<\/em> a cost that comes from having larger teams.<\/p>\n\n\n\n The exact nature of the checks depends on the work that’s being done.\nIt could be one on one conversations between developers.\nIt could be the number of people who have to be involved in code reviews.\nIt could be how many people that are at each team meeting.\nThere are more potential interactions with more people and so more cost.<\/p>\n\n\n\n A small team of, say, 3 or 4 people can work on a tough problem.\nEven if they have to regularly work closely together the cost of those interactions isn’t too high.\nA larger team has to work differently.\nWhether that’s breaking the problem into smaller less connected problems,\nchanging the team structure reduce communication channels, or ideally both.\nA bigger team should work differently from a smaller team.\nThis problem is the basis of the recommended team sizes for Scrum.\nDepending on who you listen to that might be 3-9 members or 5-9 members.<\/p>\n\n\n\n By splitting up teams into smaller groups and combining checks you can reduce overhead.<\/p>\n\n\n\n So with 3 groups of 3 people the checks inside each group will be 3 and the checks between each group will be 3.\nSo that’s 3 * 3 + 3 = 12 checks in total.\nThis is a lot less than the 36 checks to coordinate everyone at once.\nIf you’re working on a bigger project then maybe it will be 5 groups of 5 people or something completely different.\nThe right balance will depend on the exact work your doing.<\/p>\n\n\n\n The same sort of argument can be made about system architectures.\nWith tightly connected modules in a project you have to make checks whenever you make a change.\nThe more modules you have the more checks you need to make.\nAs the number of modules gets higher the specific of the original change matter less and less.\nInstead you spend more and more time to check all the different interactions.<\/p>\n\n\n\n The first step here is to try and break the system up into modules that don’t have to interact much.\nBadly organised modules means interwoven dependencies.\nWell organised modules means each module has it’s own responsibilities and limited connection to others.\nThat means, say, putting the complicities of database access into one module rather than having it everywhere.\nOther modules still have have to interact with the database module but a lot of intricacies are hidden inside it.<\/p>\n\n\n\n The second step might be to organise modules or libraries into layers or tiers.\nHigher layers use lower layers to perform tasks but the lower layers don’t have to care about higher layers.\nSometimes these layers might have official names, e.g. Presentation, Business, Database.\nHowever you can have many more layers for technical reasons.\nUnit tests for each layer could be written assuming that lower layers have already been tested and are working.\nThis reduces the need to duplicate functionality inside tests, you can safe just use code from lower layers.<\/p>\n\n\n\n It’s also important to remember than dependencies between modules can be both explicit and implicit.\nIf two modules both use a constant, People<\/th> Checks<\/th><\/tr><\/thead> 1<\/td> 0<\/td><\/tr> 2<\/td> 1<\/td><\/tr> 3<\/td> 3<\/td><\/tr> 4<\/td> 6<\/td><\/tr> 5<\/td> 10<\/td><\/tr> 6<\/td> 15<\/td><\/tr> 7<\/td> 21<\/td><\/tr> 8<\/td> 28<\/td><\/tr> 9<\/td> 36<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n People<\/th> Groups<\/th> Checks<\/th><\/tr><\/thead> 1<\/td> 1<\/td> 0<\/td><\/tr> 2<\/td> 2<\/td> 1<\/td><\/tr> 3<\/td> 3<\/td> 3<\/td><\/tr> 4<\/td> 2\/2<\/td> 3<\/td><\/tr> 5<\/td> 3\/2<\/td> 5<\/td><\/tr> 6<\/td> 2\/2\/2<\/td> 6<\/td><\/tr> 7<\/td> 3\/2\/2<\/td> 8<\/td><\/tr> 8<\/td> 3\/3\/2<\/td> 10<\/td><\/tr> 9<\/td> 3\/3\/3<\/td> 12<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n System architecture problem<\/h2>\n\n\n\n
const uint32_t MaximumTokenCount = 1024;<\/code>,\nthen they are explicitly linked to that definition.\nHowever if two modules both have their own constant or just use 1024 directly but these have to\nbe in sync then they are still implicitly linked.\nIt’s much better for the compiler to take care of an explicit link than to rely on manually updating\nvalues with an implicit link.<\/p>\n\n\n\nNetwork problem<\/h2>\n\n\n\n