http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Single Responsibility Principle - make a class responsible for being complex ;) Joking aside, Its better to have a single area that is complex than to have everything complex. As long as you can avoid leaky abstractions anyways. http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment6http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment6Fri, 31 Aug 2007 14:57:24 GMTI've talked about this before in terms of lowering the "barrier to entry" of a project. The most important thing when considering complexity is to isolate it to the point where it blends into the background. That's essentially the whole idea around .NET and related managed-code systems, hiding the complexity of things like memory management and abstracting others like I/O so we don't have to think about it on a daily basis. However, the counter-argument is that hiding complexity can raise your project's "bus factor". That's a term that we use at work, referring to what would happen if someone on the team got hit by a bus. :) A high "bus factor" means that your project is in danger of failure if one of the team members leaves. (It can also indicate that if you have a bottleneck in the design favoring a single person.) Isolating complexity is good, but the entire team should still be *aware* of it, even if they don't have to interface with it every day. http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment5http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment5Thu, 30 Aug 2007 17:22:36 GMTIt sounds like a "greater good" scenario. You're adding some complexity in one area of code for the greater good of added simplicity throughout the rest of the codebase. Sounds like a win to me. You just have to be careful to ensure that whoever will be maintaining this code understands the principles that are in place here. http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment4http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment4Thu, 30 Aug 2007 15:55:32 GMTOn one project I had a similar situation. We were using Castle Windsor, and the config file grew and got ugly. I showed my team some config sections of interest and how they can be changed for their needs, but that was the extent of it. The config file (and Windsor) were a bit of a black box that really only I understood. In hindsight, I'd say it was a fair trade off. The team had and understanding of what Windsor did, and roughly how to do it, but they didn't need burden themselves with it. So, I'd also vote for certain zones with the label hic sunt dracones. :) http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment3http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment3Thu, 30 Aug 2007 14:52:08 GMTZones of complexity seem fine, particularly if its one type of complexity. http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment2http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment2Thu, 30 Aug 2007 13:42:04 GMTSee Paul Graham's recent "Holding a Program in One's Head" essay. The objective is to fit the whole project in one's head. However, because most projects are too complex (or heads too small), they won't fit in. Enter "zones", a "zone" being a part of the project that may be quite complex--yet fits in one's head. And, seen from the outside, it is simple enough to understand, so that when you use it from another zone, it uses very little of your precious head space. Think about garbage-collecting vs. managing memory allocation locally. The garbage-collector itself is quite complex. Yet what you see when you code it that the whole memory management complexity has been moved into some rather simple concepts. I'd vote for systematically trying to isolate complexity in carefully-designed "complexity zones". Defining the boundaries of a zone can be tricky, though. If it does to little it won't hide enough complexity. If is tries to do too much it will turn into a leaky abstraction--those that seem easy to grasp and then turn into a nightmare. http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment1http://ayende.com/2747/placing-complexity-localized-complexity-zone#comment1Thu, 30 Aug 2007 12:38:27 GMT