I was thinking about the good practice of using names for classes and methods which describe what they implement and I came to the conclusion that one benefic side effect of this practice is that it promotes to a certain extent the principle of black-boxes. Meaningful names and clean code discourage a developer from peeking into the black-box (a method on a class for example) to see what it actually does. Methods that only do what their name states (such as authorizeCreditCard which just authorizes a credit card and doesn’t also commits the purchase order) also enforce the black-box mechanism. Transparent development could be regarded as one way to avoid cluttering business logic classes with outside concerns (such as security, transactionality, etc…).
I find that it helps to have meaningful names closer to the business process, in a sense they should be readable by business people. A class which CAN be read by a business person has a bigger chance to be aligned with the process it implements. When the class and method names used in the code start deviating from names used by business analysts it is a good indication that you should re-factor it in order to align it better with the business process.
When dealing with real black-boxes (i.e. interfaces) meaninful names are actually mandatory, bad names will end up obfuscating the process that these interfaces abstract.

P.S. I know I should have dropped this post in the ‘Stating the obvious’ category, but I don’t have such a category ;-).

Large organizations come with large number of people. As you work in such an organization you will interact with many people and it is important that you interact with them efficiently.
Email is the form of communication that you will use the most for interacting with other people. One good thing about email is the fact that it remains on record, once you have received an email you can archive it for further reference. It is important that the archiving process is efficient, you should be able to retrieve a particular message fast if you need to.
Once you start in a project you should determine how to split the messages you receive from your co-workers and put them in multiple bins with meaningful names. You should be able to drop the same message in multiple bins, each bin is essentially an index which should be populated with this message if it fits the purpose. Outlook is a product which is far superior to Lotus Notes from this point of view (at least as far as I see it).
The number of bins should be kept under control, you don’t want to mushroom them. The bin should be regarded as an index which allows you to retrieve information fast, rather than a collection of loosely-related items.

I was talking to Derek about what would open APIs mean for the big corporations providing them. In particular we were talking about the last paragraph in this Jon Udell post:
I don’t think ads are the endgame for Gmail. The real monetizable asset will be the APIs that we’re all going to help them create, and the value-adding services that Google will be able to build on top of them.
Well, I don’t thing that the value adding services will add that much value if the come from Google. One value-adding service currently being developed would be a mash-up of GMail, GOffice and GSpreadsheet (or whatever their names are) which would try to port the behavior of MS Office on-line. Quite frankly, I don’t think that they will get really far, apart from associating some document types with some applications. What would be actually cool would be to take this GApps and create very customized applications which would target a particular business process (as I was suggesting here). The value would be in this mash-up, rather than in the free applications which compose it. But this cannot be done by Google, because they don’t scale in diversity (they don’t scale in terms of developer and customer-relations hours to dedicate to customize their own apps) to target this incredibly fragmented market. Google, at best, can provide templates for various business processes across various business lines, templates which would be used by small entrepreneurs (which could pay a fee for using such a template) and customized ferociusly. Google could turn into a huge repository of business processes templates, but I would be surprised if they do it because the revenues this business would generate would pale in comparison to their search engine’s revenues. They would not be even a drop in the bucket. It would make sense for a small-timer to do this, it would pay off.

Anyway, I am diverging. To get back to what I had in mind: one benefit of open APIs that stands out is reaching niche communities very effectively: Let’s take the group of “Chihuaua owners in the Hamptons” (wouldn’t you like to reach this group ;-)). Someone could pretty easily whip-up a site targetting them which would collect books from Amazon related to chihuauas, which could compare prices for the same book across Barnes&Nobles, Amazon, Chapters, use Google Maps for locating veterinary doctors, search ebay for latest chihuaua items, put together a discussion group on Google Groups, etc… All these APIs are pretty much open and free, what is needed is an entrepreneur that would realize that demand exist for putting all these services together (supposing again that this demand exist) and then sell very targeted solutions to these very small groups. Everybody would profit: the small entrepreneur has a business, ebay gets a cut on the items they sell, the ebay seller sells a product, Amazon sells another book they may not have sold, and Hamptons’s Chiuauas are spoiled rotten ;-). I think in the long run it is this very small entrepreneurs that would take the greatest advantage of these free APIs rather than the giants because they cannot create these applications which are very refined. To a certain extent you could say that the giants “do not scale in diversity” and that they “outsource” peddling their wares (books on Amazon, auctions on eBay, etc…) to niche groups or niche businesses to small-timers. In a very broad sense using small entrepreneurs which with your APIs target niche markets is similar to outsourcing your access to a very fragmented market.
In the example above I was using the community of head-hunters which could benefit from these mash-ups, there are dozens of other business lines that could benefit from these applications delivered with a surgical precision.
I put this posting in the ‘IT in SE Europe’ category. How could it apply to it? Well, for the time being it doesn’t apply this much, it would apply once the ‘giants’ start providing suitable services to SE Europe or when the local corporations (if there are any) start having the scale at which to provide these services reliably. The only big corporation that provides some services is Google with its Google Maps, apparently this application includes some views of the region.
I think a lot more business lies with making custom solutions for niche businesses and selling them for a profit. I am thinking the they would serve pretty well the HR industry which is currently booming in SE Europe thanks to off-shoring. Way too many secretaries are wasting way too much time because of inefficiencies… Probably there are other opportunities as well…

I did one cool thing today: I wrote an interceptor that manipulates a data set in order to create various tests. It is interesting, the interceptor was retrieving data from a live data-feed and changing it according to various patterns which were further tested. I really like the fact that I could take this data-feed and customize it across my test needs rather than getting the guy at the end of the feed to send data in the patterns that I neeed for testing. The interceptor was created in a plug-and-play fashion so that various test patterns could be created and tested easily. One cool thing about it was that I could replicate a scenario which was really time-dependent.
Neat.