Tuesday, October 31, 2006
Windows CE Device Drivers
Monday, October 30, 2006
Software and Value
We definitely lack a good economic theory for software value. Even worse, we seriously lack even a barebone ability to estimate software value. It is not uncommon to see grizzled marketing guys asking for aggressive estimation for a neverending list of features. Ask the value of each feature, and you'll get a blank stare. The most common answer I get is "I can give you priorities" (which is definitely not the same thing). Sometimes I get a reasonable answer, like "we have 200 sales depending on having that feature". This is a good starting point to quantify value. Note that I'm mostly concerned with software competing in the marketplace. Internal, corporate development has different dynamics.
For a long time, the entire topic of software value has been so neglected that when you read about earned value in literature, what they are usually calculating is incurred cost, which is ridiculous to say the least.
Some people enjoy the sense of freedom of not having any reasonable business model behind, so they can just try whatever seems reasonable and not be held accountable. Still, going by the seat of your pants is not that great in the long run :-)). In this sense, I've appreciated a recent work from Gio Wiederhold ("What is your software worth?", Communications of the ACM, September 2006). Although the model he proposes is mostly useful for long-term planning of pricing, money allocation, and phase-out, and although there are obvious simplification in the model, it's definitely a step in the good direction. If you don't have access to CACM, there is a longer version available online. Gio is a great guy, so the spreadsheet he uses throughout the paper is also available for free on the same page.
For a few small-scale ideas on value, see also an old post of mine.
Sunday, October 22, 2006
BetterEstimate
Anyway, recently I've got back to a paper about the simple math behind my BetterEstimate technique. It's nearly finished now, so it could get online in the next few weeks.
I've also got some interesting experimental results from Magne Jorgensen at the Simula Labs in Norway. I'll have to update the BetterEstimate paper to include these new data, but that will have to wait a little more...
Thursday, October 12, 2006
Cross-cutting concerns are NOT always aspects
OOP is (mainly) built around the principle of information hiding: unstable details must be hidden behind stable interfaces. Of course, structured programming allows information hiding as well. It's just easier in OOP-land. OOP allows for some separation of concerns as well. Often, we can find a concern and encapsulate it neatly inside a class, or a small group of cooperating classes.
Structure emerges as we try to separate concerns and apply information hiding. It as been argued, however, that most contemporary languages (and paradigms) only allow ONE structure to emerge. Within that structure, we have decomposed concepts into finer-grained abstractions, and mapped those abstractions to classes. This is known as the principal decomposition, which is also the only one we have in traditional OO languages. While most authors seem to equate the principal decomposition with the inheritance hierarchy, that's a limiting view. The principal decomposition is the entire class lattice, including aggregation, composition, and so on.
Still, some concerns can't be easily isolated within the principal decomposition. It's not really that you can't - but you have to change the structure, so that those concerns become part of the principal decomposition. In some cases, by doing so, you're forced to move other concerns outside the principal decomposition.
Where do they go? Pretty simple: if they're not part of the principal decomposition, they will be scattered around. Part of a concern will be implemented in method M1 of class C1, part in method M2 of class C2, and so on. The downside, of course, is that understanding the systems gets harder, and maintenance may require more testing, as we lack the so-called "unit of change". The so called "tyranny of the principal decomposition" is what forces a concern to be either encapsulated inside it, or scattered around it.
AOP was born to deal with [some] cross-cutting concerns. It's interesting to note that AOP does not propose to eliminate the principal decomposition (except in the most adventurous hyperspace approaches). In this sense, AOP is not an antagonist paradigm: it can live side by side with existing paradigms, and it usually does. In the beginning, technological cross-cutting concerns were tackled. Logging, transactions, synchronization, contracts, were all considered candidates for cross-cutting concerns in the AOP sense. Nowadays, the focus is switching to consider aspects as a full-fledged design tool, together with classes. There is an interest in defining "early aspects", that is, to find aspects during design, without restricting to implementation-level details like logging.
It is important to understand, however, that not all cross-cutting concerns are aspects, or must be dealt with using aspects. An aspect is a relevant concern that has been left out of the principal decomposition, because modeling that concept inside the principal decomposition would move some other fundamental concepts out. Otherwise, it's just plain bad modeling: we could have easily encapsulated the concern inside the principal decomposition itself.
In this sense, I'm afraid I don't like Jacobson's idea of selling Use Cases as early aspects (see "Aspect-Oriented Software Development with Use Cases", Addison-Wesley).
I guess everybody, at one point or another, has noticed that uses cases didn't map well to an object-oriented view of the problem domain (or solution domain, anyway). Use cases are so much about functions, and so little about classes, that some clash is unavoidable. Now Jacobson is telling us that it's fine: use cases are aspects, so they naturally cross-cut the principal decomposition. Which is a pretty bad idea, for a few reasons:
1) This stuff has already been invented in the 80s by James Martin. It was called Information Engineering and relied on a matrix to model functions cross-cutting data. It didn't work great back then, and won't work great today.
2) This is rationalizing a bad development process, where your class model and the system you want to build upon that model just don't match.
3) Even if you go so far as to consider use cases as aspects, they will match poorly with current AOP languages. A use case is realized mostly a sequence of calls to other objects. There is no natural way to map this into advices and pointcuts. This is because use cases form the main functionality of the system; they're not sideways aspects we want to plug-in. They may cross-cut a class model, but they are not aspects. They're just at odd with the class model.
Where Jacobson may have a slightly stronger point is that Extension Use Cases can be seen as aspects, as they can be modeled as a single concern from one perspective (the use case view) yet often cut across several classes (or methods) in the class view, even after the base use case has been implemented. Still, is any change that requires to (e.g.) subclass more than one class an aspect? I would say no, if that change is about extending the main functionality of the system, as Extension Use Cases usually are...
Wednesday, October 11, 2006
Origins of AOP
Recently, I've been reading a book from Ivar Jacobson and Pan-Wei Ng ("Aspect-Oriented Software Development with Use Cases", Addison-Wesley). I didn't much like the book, but anyway, in the preface Jacobson claims to have invented AOP-like concepts in 1986, maybe in 1981. I didn't read the papers, as the links in Jacobson's site are broken, so there isn't much I can say (right now). However, it strikes me that nobody is giving the proper credit to what was probably the first real programming environment (can't call it a language) supporting AOP-like concepts. It was called WEB, and then became known as CWEB for its C-based instantiation, and was created by Donald Knuth (famous for TeX and for the monumental :-> "The Art of Computer Programming" series) back in 1984 (or so I remember).
CWEB implements Knuth's vision of literate programming, where programs are fragmented, fragments are interleaved with explanations (text, charts) and possibly hyperlinked. In a sense, CWEB starts with a paper explaining the program, and you can use a tool to get the program code. You actually use two tools: CTANGLE, which produces compilable C code from the paper-like description, and CWEAVE, which produces TeX documentation. Guess what, even [en]tangle and weave are now recurring terms in all the AOP literature and languages. A nice feature is that you can show code evolution (e.g. from a simple but inefficient implementation to a complex but highly optimized version) and choose the version you want to merge in the main program.
CWEB never reached a critical mass of adopters, but it's still relatively well-known, having been popularized by Knuth himself on several books. So, in a sense, it's rather weird nobody has seen the root of AOP in there. This is not so unusual, however. I remember, back in the "design pattern" frenzy, how I wondered about the fact that nobody could see (or cared to mention) the strong relationships with the concepts in "The Programmer's Apprentice" by Rich and Waters. Especially those interested in building pattern-based tools. Oh, well... :-).
