February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox
March 22 - 25 - Tutorial on Modular Architecture
June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture
July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.
Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29
The opinions expressed on this site are my own, and not necessarily those of my employer.
I’ve always been obssessed with (or tormented by) portability and mobility. I want my information with me, accessible, all the time. This obsession began over 10 years ago.
It’s very common for teams to use averages to communicate a measurement. The average number of lines of code per method or the average number of features delivered per iteration are simple examples. Most of the time, the average represents the mean, which is the arithmetic average of all samples from a chosen population. But average can also be used to refer to the median (the middle value in a series) and mode (the most frequently occurring value in a series). This can be misleading, and the result is metriculation.
Software development teams often use cyclomatic complexity (CCN) to measure the complexity of their code. Using a well-chosen average, it’s easy to misinterpret, or miscommunicate, the results. Let’s say we want to calculate the average CCN for a system. Consider seven methods with the following CCN:
Method 1: 3 Method 2: 3 Method 3: 3 Method 4: 12 Method 5: 120 Method 6: 85 Method 7: 15
Using this sample, the mean CCN is 34, the median is 12, and the mode is 3. While average CCN typically uses the mean, in this situation, the mean provides a false positive indicating poor code quality. Given a different sample, the results could be skewed in the opposite direction - providing a false positive indicating high quality.
Combining mean with median and mode may serve as a warning indicator. With a mode of 3 and a mean of 34, we might suspect a wide range of values. Another way to determine if the mean is an accurate representation of the sample is to calculate the standard deviation or variance. These represent the how spread out a distribution is. In this case, the standard deviation is almost 48. A number way to high for the mean CCN to provide an accurate representation of code quality.
The point here is that we have to be careful with how we use metrics as a measurement. Sometimes, additional analysis is required before we make a decision in how to proceed. While this example uses CCN, it would be easy to imagine other examples where this form of metriculation - the well-chosen average - might take place.
Metriculation is derived from statisticulation, a term introduced in How to Lie with Statistics.
This past week, I was glancing at a few older articles I’d written that have never reach publication. The first was titled The Typeless Parameter, which was a design pattern I’d authored in 1997 with the intent of submitting it to the PLoP conference. I recall participating in the shepherding process, but never submitted the final piece.
The second was titled Grass Roots Agile, which was written more recently, in 2007, for the 2nd edition of NoFluffJustStuff Anthology Vol. II. Since I was a bit late to the game, the piece was never included. In fact, it’s never been published, so I’ve decided to share the piece here. I doubt my thoughts have changed significantly, though I’m sure they’ve evolved over the past two years. Keep in mind the paper has not be copy edited, nor professionally proofed as you’d typically expect when published. Just me dumping my thoughts through the keyboard.
Metrics can be used to garner a lot of feedback that’s valuable to the software development team. And they can also be used as a convincing argument to push an agenda. You have to be careful that metrics are used legitimately, and avoid metriculation. Metriculation is a term I use to describe how metrics can lie. One form of metriculation is the faulty assumption.
A faulty assumption occurs when we draw some conclusion based on the occurrence of simultaneous events, but have no substantive evidence correlating the events. Faulty assumptions are based on the logical fallacy of correlation proves causation. In software development, we have to be very careful not to make decisions based on faulty assumptions. Let’s take a couple of simple examples.
On any software development team, the number of developers who eat lunch while working at their desks may be related to the number of developers that get stuck in the elevator. The conclusion then is that you should not eat lunch at your desk if you want to avoid getting stuck on the elevator. Even the less than astute individual recognizes the absurdity of that conclusion.
But what about this more plausable scenario? The number of developers using Fancy Framework X is related to the number of developers with fewer defects in their code. Our conclusion now is that if we want to reduce software defects, then all developers should use Fancy Framework X. Possibly. But is there a causal relationship between using Fancy Framework X and code with fewer defects? Or have we falsely assumed that there is?
Proving causal relationships is difficult, if not impossible. The slightest possibility that there may not be a causal relationship means the conclusion can always be challenged. Proving causality requires statistical analysis, which may not always be feasible. Sometimes the best we can do is apply inductive reasoning to arrive at our conclusion based on the likelihood of causality. The moral here is that we should not be awestruck by metrics. Nor should we be naive. Instead, leveraging metrics requires critical thinking.
“If we are interested in maximizing the welfare of our citizens, the way to do that is to maximize individual freedom. “
He goes on to state that the way to maximize freedom is to maximize choice. The more choice we have, the more freedom we have, the more welfare we have.
That resonates with me. But how little I understand the human psyche was quickly revealed.
Mr. Schwartz continues by illustrating how all this wonderful choice we’ve been given has a paradoxical affect. We find it incredibly difficult to make a decision because the choice has a paralyzing affect as we strenuously evaluate our options. Once we are lucky enough to make the decision, we wind up less satisfied with our final choice. He calls this the opportunity cost of choice. Whenever we make a choice to do one thing, we are also making a choice not to do another. And if in the end we are not completely satisfied, we imagine another choice would have brought us greater happiness or pleasure. The opportunity cost of choice detracts from our satisfaction as we cannot resist the urge to think about the alternative options.
He drives that point home further by explaining that with so much choice, our expectations are artificially inflated. From all that choice, we expect perfection. On the contrary, when presented with only a single choice, our expectations are much lower. Now here’s the punchline! When given only a single choice, dissatisfaction is not our fault because we had no choice. But when given multiple options, if not completely satisfied, we tend to blame ourselves. Choice, believed to lead to happiness, in fact leads in the other direction. That’s paradoxical, no?
He concludes, perhaps jokingly, that the secret sauce to happiness is low expectations and that everything was better back when everything was worse. Or perhaps he wasn’t joking! Closer to the end of the talk, he told a simple story about his trip to the department store for a pair of jeans. The shopkeeper asked him if he wanted slim fit, easy fit, or relaxed fit? Button fly or zipper? Stone washed or acid washed? Boot cut or tapered leg? His reply?
“I want the kind that used to be the only kind.”
Now that resonates with me. I’d encourage you to listen to the talk. I’m sure I’ve missed a few points. It’s just under 20 minutes and is time well spent.
Apologies. This entry has little to do with technology. Or does it?
BTW, the image was not created by me. I snagged it from the talk.
I took the liberty of running JarAnalyzer on the OSGi bundles deployed as part of Spring 2.5.6. These are the JAR files found in the /dist/modules directory. Click the image at right to reveal the relationships between JAR files.
It’s interesting to see the dependency relationships and layering of the framework. Note that there are no cycles. I have always felt a significant advantage of Spring is the way development teams can incrementally adopt the framework. Start using core for basic dependency injection and move up the stack to JDBC and declarative transactions, ORM integration, and integration with your favorite web framework. It’s the flexible architecture of Spring that allows this. I’m guessing that when the Spring team went about modularizing the framework around OSGi, the architectural flexibility already embodied in previous versions of Spring made their job easier.
For those of you who want the more detailed information, you can view the JarAnalyzer html report for Spring 2.5.6 showing a variety of metrics related to design quality.
I just got off the phone with Capers Jones, founder of SPR. We had a great conversation on software metrics, and he definitely gave me some interesting bits to chew on. One aspect of metrics that I’ve been particularly interested in is how IT can use metrics to show their value to the business. He was pretty crisp in his response when he stated that it isn’t IT’s job to measure their value to the business.
This sent me swirling for a moment, and I’m sure the depth of the conversation that followed shortly thereafter was lost on me. His point was that IT doesn’t really know how to measure their value. Instead, it’s the business people who understand what value they hope to get from the software, so it must be the business people that measure that value. I think Caper’s point is this. If I spend $100 on a product, it’s my responsibility to ensure I’ve gotten $100 worth of value out of that product. The company I purchased the product from has no way of measuring the value I received from the product.
But I’ll take that one step further. The company does have the ability to measure the perceived value, and there are a lot of ways to do that. They can follow-up with me directly to obtain qualitative measurements on my satisfaction with the product. They can also monitor various sales channels to obtain quantitative measurements. They can combine this qualitative and quantitative data to create meaningful measurements that allows them to gauge the value of their product to the consumer. And really, as value goes up, so to do sales.
This translates to IT. IT does have the ability to gather qualitative data from their customers. They also have the ability to obtain loads of quantitative information. The key is that IT cannot measure their value to the business without working closely with their business partners who will provide them with the information they need to make those measurements.
Capers went on to say that IT must be able to demonstrate competency in the products and services they deliver, and that there is business value in that. Examples included showing that my productivity rates exceed those of my outsourcing counterparts, that I’m able to build software with fewer defects, or that I can deliver software that isn’t vulnerable to security breach.
I sum it up like this. If I’m able to increase my internal efficiencies and also able to measure and improve my effectiveness, that translates into my advantage because I’m able to deliver higher quality products and services more quickly than my competitors. And that’s an advantage to my customers, which keeps them coming back to me. The key is that I must be able to measure it.
A post on the Burton Group APS blog about how metrics can be used to push an agenda from a specific perspective. Metriculation is a term I introduce, derived from Statisticulation, where metrics are made to lie.
In early December, I spoke at SpringOne Americas and delivered a session on OSGi. Whenever I speak about application design or architecture, I always ask the audience three questions at the beginning of the session. In this session, I had about 40 or 50 folks in attendance, and here’s a rough breakdown of the hands shown after each of the questions.
These are common responses. Most development teams spend time designing classes, but few spend time designing JAR files. That’s unfortunate, because failing to design JAR files inhibits reusability and hinders maintenance. Even the most flexible class design is severely compromised if all classes are packaged and bundled into the same module.
When designing software systems, more effort should be devoted to designing the granularity of JAR files and managing the relationships between JAR files. When designing classes, more effort should be devoted to designing classes whose relationships span JAR files, with less effort devoted to classes whose relationships are encapsulated within a JAR file. Why? Classes whose relationships are encapsulated within a JAR file are isolated from the rest of the application, and can be more easily refactored because the ripple effect of change is constrained to the JAR file. Packages, as the intermediary logical concept, are important in helping bring greater internal design resiliency to a JAR file.
And, of course, design is a evolutionary activity involving many tasks, including a combination of modeling, coding, and testing.
The Agile 2009 CFP is open. This year, I’m the stage producer for Developer Jam. As you can see, Developer Jam has an impressive review committee. We’re hopeful that 2009 will be as successful as 2008.
Once again, we’re planning to run a series of clinics. They’ll be hands-on, instructor led exercises that will teach attendees something practical. If you have an idea, write up a submission, but don’t wait until the submission deadline of February 15th. Doing it sooner ensures increased visibility with the group of reviewers, and that means greater likelihood that the session is accepted. Of course, there are no guarantees. As a bit of additional incentive, be sure to check out the speaker compensation rates.