On 14 July 2010 10:49, Antoine van Gelder <anto...@g7.org.za> wrote: > Questions such as "how do we define a downward trajectory?" or >"which direction is simple in?" or even "how can we even possibly hope >to measure simple?!"
There is nothing hard about simplification per se. I don't think I've made a significant contribution to any software project that hasn't been net negative in LOC. The problem is that this often doesn't make a significant dent in the overall size (and hence, usually, complexity) of the project. However, you're quite right to point to the difficulties of measuring complexity. What one can intuitively recognise and fix is not necessarily easy to measure. I can imagine automatic measurements of several things that are easy to measure, but I've never seen tools for: average length of function in LOC, average number of function calls per function, number of callees, number of callers. But things can get complicated. For example, a long function with few calls might seem like a classic case of bad programming...or it might be the sort of what I call "narrative code" that is typical in initialisation and shut-down routines, and sometimes pops up elsewhere. In either case, it is unlikely to be complex *in itself* (in the absence of gotos), but if it should have been decomposed, then it's imposing complexity elsewhere. The classic case of a little complexity imposed everywhere is the code base that is too little abstracted. I spent a couple of years working on a proprietary application that consisted of a core of about 30 kLOC, with a plethora of application modules written on top that totalled about 1 MLOC. Reading and writing application code made my head hurt, because doing simple things was hard, but none of the code was actually that complex (the system was basically a database with lots of customised forms). But improving an application was a very small win, as it only improved that one module. My three main efforts over the time I worked on that system were first to make the core portable, largely just a matter of removing #ifdefs and relying on the fact that the systems on which it built had all started supporting the same standards since the code was first written, secondly, to remove dead code (e.g. an old version of a reporting system, because although the new version was an "optional extra" that customers paid for, it was itself almost obsolete, and company records showed that all current customers paid for it), and thirdly to write a scripting language skin for the application system, to make it possible to write applications in much less code (very ill-advised, as it turned out, as I was never given the resources to train other programmers in its use, so when I left the company had not only a useless scripting system with extra build- and run-time dependencies for our system, but an important application (which I wrote) written in a language that no-one else at the company knew). "Insufficient abstraction" may be an extreme example of complexity thati's hard to measure, but even kinds like "duplicate code" are tricky. I recently found, by inspection, a duplicate function that has been lurking in a code base of ~10 kLOC that I've been rewriting for years (the text editor GNU Zile; it started off at ~20 kLOC). It is really only because I'm currently translating the entire application into another language (from C to Lua) that I was a) reading the code and b) had enough context in my head to realise that the code I was looking at was redundant. In fact, I've managed to remove hundreds of lines of C code during this translation project, and that is despite the fact that I had already spent probably months trying refactoring and simplifying the existing code. It is interesting to speculate whether I would have found these simplifications had I not been actually translating rather than simply reading the code. > ps. Make no mistake. Paul is right on the money. Even if no-one wants > to 'fess up most of us _are_ being measured (implicitly) on SLOC. This seems right. In my case, this was expressed as concern that I was not producing enough application code (my assigned work) and was instead spending my time re-engineering the code (what the company actually needed, in my view, but then my view was biased as it was far more interesting). This despite the fact that more than one of my bits of re-engineering saved serious corporate bacon. However, the underlying cause is that the company was directly earning revenue from developments to the product (new applications). I theorise that even sticking with SLOC as a primary productivity measure, had they actually been able to measure my effect on the other programmers' productivity, I might've got away with doing what I did. Our customers had the same problem: easy to say "we need a new app that does this"; much harder to say "we need to improve the way we do that". The cultural factors at work are all too obvious. Since there's an obvious link between new features and SLOC, the latter's tyranny follows. -- http://rrt.sc3d.org _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
