Tuesday, September 27, 2005
Real Options and Software Design
Davide Cesarini asked if it makes sense to apply the technique to evaluate alternative designs for an existing, non-modular system. He also suggested that the Design Structure Matrix could be a useful documentation tool when a new application is being designed.
Overall, I see the biggest value of the article in the approach, method and language used to deal with software design. There is no advocacy about the (usually unjustified) superiority of some language, technique, paradigm. Instead, the authors' goal is to discover the real economic value of each proposal. This, as Davide noticed, does not come for free. In fact, the approach described in the paper is better suited to the comparison of alternative designs for a new application: most likely, the authors opted for an existing "reference problem" to avoid a lengthy explanation of a new problem, to build upon existing knowledge, and possibly to avoid bias in the selection of the problem.
What I see as immediately useful when documenting design decisions (a cornerstone of good design documentation) is the portion of the matrix relating environment parameters and design rules. This is useful even if we don't go on and apply the Net Option Value part.
Even more important, for the designers, is to get the message: delaying decisions can add value; the best modular design adds more value. Even in the absence of formal value calculations, we definitely need to start thinking in this way about software design.
Labels: article reference, design, real options
Monday, September 26, 2005
Ultraviolet, running, and requirements
I'm posting this on Monday, but it's about Sunday. I was too lazy to post it yesterday :-).
Fulvio Esposito, in one of his comments, pointed out an unreadable form used by the Italian Post Office. I've seen that form before, and I was surprised too by the absolute unreadability of the light orange text on a white background. So surprised that I couldn't think of that as completely unjustified. I tried to look at the form under a close fluorescent light, and the contrast was sharper. Even more so under ultraviolet light. So, that choice of colors could be an attempt to optimize the form for some scanner. Also, the form is a forth and back, so maybe this is helping some device telling which is which.
Of course, this is absolutely wrong anyway. Just think of who is going to fill that form. Most likely, someone who is not using email (elders, with high probability), or has some official document to send (concerned, if not worried, with some probability). Optimizing for the machine is not an option. Alternatively, that color could simply be the result of ignorance about humans and perception of colors. Guess I'll never know :-).
The weather was nice and I went for a (short) run. While running, a question I heard in the past three days while teaching OOD popped up in my mind, and I realized I could substantially improve an unrelated :-) course on requirements. I just have to scrap away most of it, and add the new stuff :-). Well, another background activity, just what I needed :-)).
Fulvio Esposito, in one of his comments, pointed out an unreadable form used by the Italian Post Office. I've seen that form before, and I was surprised too by the absolute unreadability of the light orange text on a white background. So surprised that I couldn't think of that as completely unjustified. I tried to look at the form under a close fluorescent light, and the contrast was sharper. Even more so under ultraviolet light. So, that choice of colors could be an attempt to optimize the form for some scanner. Also, the form is a forth and back, so maybe this is helping some device telling which is which.
Of course, this is absolutely wrong anyway. Just think of who is going to fill that form. Most likely, someone who is not using email (elders, with high probability), or has some official document to send (concerned, if not worried, with some probability). Optimizing for the machine is not an option. Alternatively, that color could simply be the result of ignorance about humans and perception of colors. Guess I'll never know :-).
The weather was nice and I went for a (short) run. While running, a question I heard in the past three days while teaching OOD popped up in my mind, and I realized I could substantially improve an unrelated :-) course on requirements. I just have to scrap away most of it, and add the new stuff :-). Well, another background activity, just what I needed :-)).
Monday, September 19, 2005
Writing
Today I've been lucky enough :-) to find some time for my neverending UML 2 Manuale di Stile. I've almost completed the section on deep and shallow history. Tomorrow I'll be traveling for more hours than I'd want to :-), so I should be able to complete this section. However, I'll be busy teaching and consulting for the next few days, so don't expect a new version to be online before Sunday.
Tomorrow, and/or on my travel back home, I'd like to spend some time writing about an interesting idea on using UML as a planning tool. See one of my earliest postings for a few more details.
I'm doing a lot of interesting things, just very, very slowly :-))).
Tomorrow, and/or on my travel back home, I'd like to spend some time writing about an interesting idea on using UML as a planning tool. See one of my earliest postings for a few more details.
I'm doing a lot of interesting things, just very, very slowly :-))).
Sunday, September 18, 2005
Legends
Romano Scuri mentioned the KISS principle on his comment to my post on kicking reuse, and I was about to post a nice related story I heard some time ago. The story goes like this: in the 60's, NASA spent a hefty amount of money to develop a pen that could be used in a vacuum and with no gravity. Faced with the same problem, the Russians used a pencil :-).
Before posting the story here, however, I did a quick check, and it turned out it's probably just another legend :-(. Among the numerous sources explaining that the "space pen" came much later from a private entrepreneur, and that NASA initially used a pencil as well, here is one that provides reasonable background.
Well, it was a nice, almost exemplary story. Too bad it isn't true :-).
Before posting the story here, however, I did a quick check, and it turned out it's probably just another legend :-(. Among the numerous sources explaining that the "space pen" came much later from a private entrepreneur, and that NASA initially used a pencil as well, here is one that provides reasonable background.
Well, it was a nice, almost exemplary story. Too bad it isn't true :-).
Saturday, September 17, 2005
UML 2
I'm using more and more of UML 2 in my daily work as a consultant and software architect, but in most cases I've to "retrofit" the new concepts into UML 1.x tools. An extremely useful (and simple!) concept is the shallow and deep history in state diagrams, which can be easily modeled in UML 1.x as well (unless you want to generate code from the diagrams :-). As soon as I find a little spare time, I'll write down a page or so in my UML 2 Manuale di Stile (in Italian).
Wednesday, September 14, 2005
Kicking reuse in the A$$
We obtained a dramatic improvement in development time (and in my opinion, in product marketability) by moving some features from the PC to the embedded side (!). Another big gain came from kicking a standard protocol out and using a tailored command (within the protocol framework, but still entirely custom); this improved reliability as well. The final, substantial gain came from kicking out a large, reusable infrastructure we built years ago for similar applications, and designing a (much smaller) custom solution.
Now, this is not the kind of suggestion people would expect from me. But reuse is not a value per se. It's a value when it provides an economic advantage. In this case, the initial investment needed to fit the problem inside the large, complex architecture just wouldn't pay off. Besides, the custom solution is not badly designed. We have a clear point where we could theoretically sweep out the custom part and plug a bridge to the more powerful infrastructure. This is, in my opinion, quite sensible design. We have the minimum overengineering needed to move to an higher level later, at low cost, if we ever need this. Meanwhile, the project will sell, and hopefully sustain itself.
Economy 101 :-), or a careful use of Real Options theory? More the first than the latter, but again today, when designing a reporting subsystem, there was a clear separation between what is useful to design now (everything down to an XML document), and what is better (economically better) to postpone until a more careful evaluation of alternatives has been carried out. This is easily explained by Real Options - the option to wait on this part has more economic value than the option of designing it straight away. This (as well as kicking code reuse) is somewhat entangled with the notion of Second Order Ignorance from Armour, but I'll leave this as the dreaded exercise for the reader :-))).
Labels: design, profession, real options
Monday, September 12, 2005
Dropping Features (again)
While discussing the concepts of my previous posting on dropping features with a customer, he promptly asked about how tracking usage can systematically help product evolution. My strategy is quite simple, and is based (like many other simple, effective ideas) on quadrants.
Once we have usage profiles, we can define two metrics:
- The usage frequency of a feature. We can define the frequency as the number of times a feature has been used, divided by the total usage count. We do this for each user, then we take the maximum as the usage frequency of that feature.
- The percentage of customers that used that feature at least once.
We can then define a threshold for each metric, based on a Pareto analysis. We will classify a feature as "low frequency" if its usage frequency is below the threshold (high frequency otherwise), and as "rarely used" if the percentage of users is below the threshold (commonly used otherwise).
Each feature will belong to a quadrant:
1) Low frequency, Rarely used
This feature is definitely a candidate for removal. If we believe in its value, we must improve its usability, or make other significant changes.
2) Low frequency, Commonly used
Lot of people are using this feature, but just once in a while. It could be an unavoidable but unpleasant step in the current application. Is there a way to do without?
3) High frequency, Rarely used
This is probably an extremely valuable feature, but for a small niche! Can we make it more useful for the others? Is it just hidden or unintuitive to the majority of users ("mystery meat" as Krug would say)? Is it in the wrong product? Could it be the seed of a new niche product?
4) High frequency, commonly used
This is the real application core, as seen by the users. Learn from that! Build upon that!
Once we have usage profiles, we can define two metrics:
- The usage frequency of a feature. We can define the frequency as the number of times a feature has been used, divided by the total usage count. We do this for each user, then we take the maximum as the usage frequency of that feature.
- The percentage of customers that used that feature at least once.
We can then define a threshold for each metric, based on a Pareto analysis. We will classify a feature as "low frequency" if its usage frequency is below the threshold (high frequency otherwise), and as "rarely used" if the percentage of users is below the threshold (commonly used otherwise).
Each feature will belong to a quadrant:
1) Low frequency, Rarely used
This feature is definitely a candidate for removal. If we believe in its value, we must improve its usability, or make other significant changes.
2) Low frequency, Commonly used
Lot of people are using this feature, but just once in a while. It could be an unavoidable but unpleasant step in the current application. Is there a way to do without?
3) High frequency, Rarely used
This is probably an extremely valuable feature, but for a small niche! Can we make it more useful for the others? Is it just hidden or unintuitive to the majority of users ("mystery meat" as Krug would say)? Is it in the wrong product? Could it be the seed of a new niche product?
4) High frequency, commonly used
This is the real application core, as seen by the users. Learn from that! Build upon that!
Sunday, September 11, 2005
Natural Form Filler
Here is one of the critical portions (from the arrival record):
and the even worse copy in the departure record:
The biggest issue is that when you initially look at the form, you may (or may not) see the "1. Family Name" label, as it is placed too far from the slots you've to fill (and too close to the thick horizontal line above), while the label "2. First(Given) Name" is just where you would expect the explanation for the first field. Assuming you see the right label, your eyes tend to move right to this part of the form:
Where you don't even have the smallest visual clue to tell you that the birth data has to be written under, and not above, the label itself. The problem is even worse in the departure record, because that's what you see:
The short line seems to indicate that the previous field has finished and a new one started, but again, you have to write your birth date under, not above, the label. Also, the family name label is slightly closer to the thick line than it is in the arrival record.
The problem is obviously easy to fix. Give the right proximity between fields and labels. Avoid those misleading vertical lines. Use some strong visual clue to indicate the end of a field.
Here is a trivial example:
This is not necessarily the best, but is a significant step forward. To make it truly better, a more radical change would be necessary: put the label under the field, not on top of the field. If you put them under, you can make them very close to the field. If you put them above, you have to make them distant in order to leave enough space to actually write something.
As usual, there is a lot software designers can learn by looking around. If you like this kind of stuff, I can warmly suggest "The Design of Everyday Things" from Donald Norman, a nice book to read for everyone involved in designing... anything :-).
Labels: HCI
Saturday, September 10, 2005
Duff's Device
I spent Tuesday to Thursday this week teaching a tailored course on C++, Optimizations and Patterns for Embedded / Real-Time software. The first day I mentioned the Duff's Device as an interesting, non-obvious way of unrolling a loop. The code itself is short but weird - it's not even obvious it should compile properly. It's pure C, no C++ magic. Have a look at this explanation from Tom Duff himself, who invented the technique.
Getting Better
I remember hearing Tom Peters saying something like "if you're not getting better faster than the other guy is getting better, you're actually getting worse". Now, I'm not so sure about speed, but positive about continuous, steady improvement (not necessarily along the same line, just getting better at something each and every day). For no good reasons :-), this also reminds me of my old "critical mass" theory, which stated that learning gets much easier after you've reached a critical mass of knowledge. I still believe in my old little theory :-), but I've also observed that disruptive insights, which can shake your entire value system, may require a huge "knowledge overhauling" effort beyond the critical mass. That's one of the reasons so many "experts" avoid carefully to get in touch with anything misaligned with their beliefs.
Monday, September 05, 2005
The Nerd as a Commodity
I'm still jet-lagged enough :-) to say something extreme: the nerd who simply knows all the in&outs of a specific technology is becoming a commodity. Need a Java guru? Go India or Romania. Need a Linux expert? Go China. If you're any good at screening, you'll find excellent workers, way more motivated than western developers (although somewhat less likely to stay with you for more than a couple of years).
Why aren't nerds a commodity, yet? Because software development is a knowledge acquisition process. Language barriers, and even more so cultural barriers created by implicit, unexpressed knowledge, are still protecting the unaware techies. This is not going to last forever, and even in old-fashioned Italy I've seen more than a handful of people losing their job to equally skilled (and much cheaper) software developers from India.
Now for the bad news: technical excellence alone is not the answer. Sorry. Someone had to say that.
Want to stay out of the pack? Bring together technical excellence and a strong understanding of business. No, I don't mean understanding your business rules or process. I mean Business. Economics, marketing, management, product chain, ROI, real options, negotiation, whatever. Understand how to bring value to business through technical excellence and creativity. Outgrow the nerd. Speak viral marketing one moment, jump into a UML diagram the next, land to nitty-gritty platform details, switch back to business again. You'll find yourself a long, long way from being commoditized :-).
And by the way: what about losing any religious attachment to a language, operating system, technology or tools while leaving the nerd behind?
Why aren't nerds a commodity, yet? Because software development is a knowledge acquisition process. Language barriers, and even more so cultural barriers created by implicit, unexpressed knowledge, are still protecting the unaware techies. This is not going to last forever, and even in old-fashioned Italy I've seen more than a handful of people losing their job to equally skilled (and much cheaper) software developers from India.
Now for the bad news: technical excellence alone is not the answer. Sorry. Someone had to say that.
Want to stay out of the pack? Bring together technical excellence and a strong understanding of business. No, I don't mean understanding your business rules or process. I mean Business. Economics, marketing, management, product chain, ROI, real options, negotiation, whatever. Understand how to bring value to business through technical excellence and creativity. Outgrow the nerd. Speak viral marketing one moment, jump into a UML diagram the next, land to nitty-gritty platform details, switch back to business again. You'll find yourself a long, long way from being commoditized :-).
And by the way: what about losing any religious attachment to a language, operating system, technology or tools while leaving the nerd behind?
Sunday, September 04, 2005
Back to Reality
Holidays are over, but I'm still in Fijian mode :-), so no serious stuff for today.
See you guys tomorrow :-).
See you guys tomorrow :-).
