Le 28 juil. 2011 à 23:16, BGB a écrit : > programmer A can partly turn-off their brain, and spew out a solution to a > problem which is, say, 10 kloc in about a week; > programmer B then goes about thinking about it, and produces a more finely > crafted 250 lines after about a month. > > now, which is better?... > > then, assume sometime later, the original developers are no longer around, > and maintenance is needed (say, because requirements have changed, or new > features were demanded by their superiors). > > one may find that, although bigger, programmer A's code is generally easier > to understand and modify (it just sort of meanders along and does its thing). > > meanwhile, maybe programmer B's code is not so easy to understand, and will > tend to blow up in the face of anyone who dares try to alter it. > > now, which is better?... > > > a partial analogy could be like "entropy" from data compression, which would > roughly correspond to the internal complexity of a system. making code bigger > or smaller may not necessarily change its total complexity, but maybe only > its relative density. > > striving for simplicity can also help, but even simplicity can have costs: > sometimes, simplicity in one place may lead to much higher complexity > somewhere else. > > for example, simplicity at the lower-levels (towards the "leaves" of a > dependency graph) tends to push complexity "up" the tree (towards the "root" > of the tree). > > > for example, a person creates a very simplistic compiler IL, which then > pushes the work onto the compiler upper-end writer; > the compiler writer doesn't want to deal with it, so then it is pushed onto > the programmer; > the programmer is less happy having to worry about all these added edge > cases, and so they want more pay; > ... > > then potentially, many levels of an organization are made less happy, ..., > mostly because someone near the bottom didn't want to add a number of "sugar" > operations, and took it on faith that the level directly above them would > cover for it. > > so, simplification is not necessarily a cure-all either, rather, it is more > necessary to try to figure out best what complexities belong where, in a goal > to find the lowest overall costs. > > > for example: > is Java ByteCode fairly simple? I would say yes. > what about the JVM as a whole? I would say probably not. > > for example, had the JVM used a much more powerful, if likely more complex, > bytecode, it is possible now that its overall architectural complexity would > have been lower. > > but, then one may find that there are many different possibilities with > differing tradeoffs, and possibly there is a lack of any "ideal" front-runner. > > not that simplicity is a bad thing either though, just it is better to try to > find a simple way to handle issues, rather than try to sweep them under the > carpet or try to push them somewhere else. > > or, at least, this is my thinking at the moment...
I agree. I like to think about simplicity as coming up with the right core abstractions and the optimal way to distribute complexity among them to support a large set of use cases. Where optimal means the complexity that is inherent to any system becomes invisible for the envisioned use cases and even unpredicted use cases that are still related to the problem domain. That's quite vague or general I admit, but it does the trick in my case when I'm stuck on tricky design problems ;-) If I have a lot of time on a project (several years), strive for simplicity in this perspective and use an iterative development cycle as described in David Barbour's reply, the line count usually goes down drastically at some point (initially the code base can become bigger though) while remaining easy to read, understand and use. On the complexity vs simplicity topic, a good example is separation of concerns in UI toolkits. For a while (perhaps two decades or more), people have been trying to create UI toolkits where concerns are modularized into reusable and pluggable aspects or components. The problem is that you quickly get in troubles because it's very hard to figure out how these aspects should communicate between them in a way that is simple, predictable yet flexible enough. A clean architectural decomposition involving almost no code duplication is easy to achieve, but you usually end up with messages flying all over the place in a messy way. At first sight, the UI toolkit might seem easy to use because all the classe names are obvious, the class hierarchy is well organized, but when you want to combine several aspects together, there are either too many classes to understand at the same time, too many possibilities to achieve the same thing, unclear communication rules when your use case is a new one etc. Cheers, Quentin. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
