Code contains knowledge about the application and not only the commands to execute that application, this is a thing that is a bit unknown.
Meaningful names for classes/methods, etc… will expose the knowledge buried in the code better to a person working with that code. When you are changing the behavior of a method or a class it is a good policy to also change its name in order to expose the behavior of that class better.
The knowledge of an application should not be encapsulated only in UML diagrams or PowerPoint documents, it should be encapsulated into the code itself because easier to read code translates into a better application.

I have become interested lately into knowledge management. It is a pretty interesting field that applies pretty well to software development.

Later Edit: In the ideal case a person could learn a bit about the domain by going over the APIs, in such an environment you could say that the domain knowledge is pretty well encapsulated in the code. Of course, this would not mean that the domain knowledge should only exist in the code, only that it is a desirable to have the code reflect the domain.

I was listening to this presentation by some people at ThoughtWorks about designing an application when I was struck by this quote which goes roughly like this:
I keep thinking of clever designs to push the technology out of the picture so that changes in the business domain can be implemented more easily.

Very clever quote. The business domain keeps changing a lot more frequently these days, I think due to an increase of the number of stakeholders which increases the variety of requirements, so it is imperative to be able to make those domains changes easily. Being unable to make these domain changes because of technological reasons carries a pretty big cost.
This is why the technology should take a back seat to the domain. Ideally it would be abstracted so that it is decoupled from the domain.

Another quote that I liked was: you are given a domain when you start working on a project, you are not making this domain up and that your implementation should reflect very well that domain. The job of the domain modeler is to find out that domain and then represent it as faithfully as possible. The domain will change, but it not change in a radical fashion because this would imply that the underlying business changes radically and this doesn’t happen that often.
As I was saying before, the domain changes more frequently these days so it is better to have your application very well aligned with the domain so that changes in the domain can be translated into changes in the application very easily. If you cannot add a new feature because some framework doesn’t allow you to then you have a pretty big problem.

Another big theme in this panel was how to defer decisions till the last possible moment, which is a pretty neat things: it pays off to make decisions later when you probably have more information to base your decisions on.

All in all, a pretty interesting presentation.

Most of the social network operators depend on creating network externalities, the relationships between people using the same social network make leaving a social network more costly.
It is interesting to see the effects of Open Social, essentially a cross-corporation platform for hosting social-network widgets on Facebook. I am not arguing whether Open Social is better than the Facebook platform, I don’t know much about any of them. But think about a widget with some social capabilities deployed both on Facebook platform as well as on a social networking implementing Open Social (such as Ning) (such a widget will obviously be exposed thru 2 different APIs: Facebook’s platform API and Open Social). This widget would establish cross-corporations connections and would create cross-corporation network externalities. This widget would effectively lower the cost of leaving Facebook: all the connections handled by this widget will work if you leave Facebook and join a different social network. Facebook will fade into the background as well as this widget is concerned. If more and more social functionality got created in widgets the network externalities would become cross-corporations to the point where the hosting platform (Ning, Facebook, Orkut) becomes irrelevant. A social network hosting these widgets will probably become more atuned to its members to the point where a member will probably navigate between multiple social networks, each connected by the widgets. The social networks which are not well defined (MySpace, etc…) will probably grows less than social networks that define their users.

It is interesting to see how will Facebook react to Open Social. Putting a widget both on an Open Social site and on Facebook is not extremely hard, you decouple the interaction between the widget and the host system from the services of the widget and you code 2 interactions: one for Open Social and Facebook (the fact that you have to code to only 2 different APIs which are quite simple helps a lot). Also, from what I understand you are basically coding to a container API, which probably doesn’t require a very complex interaction. Due to the low cost of creating cross-corporation widgets via Open Social Facebook doesn’t have a big room to maneuver, it cannot take the widgets developers hostage as Microsoft and various telcos have done it (the high cost of developing to a particular platform prevented developers from creating applications that would work both on Windows as well as on Linux). Sooner or later Facebook will have to face the facts and drop its platform altogether because it will become just a redundancy.
One smart thing that Open Social has done is to create an API which is very simple. When they created a API competing with Facebooks they have created opportunity costs for coding to Facebook. The fact that this competing API comes with a low cost of development means that coding to Facebook carries a low opportunity cost which means further that these APIs are not competing for developemnt resources (coders, managers, etc…), a very important thing if you want to gain mind and market share.

Later edit: I think I rushed ahead when saying that Facebook will have to drop its platform. Currently there is not much difference between the Facebook platform and Open Social, both basically let you deploy your application within a social network. Currently both of them are basically containers. But this could change in the future. One potential important difference is how these containers will give an application access to members using the social network on which it is deployed (users, advertisers, etc…). Access to members within a social network could be what would split the organizations backing Open Social (hi5, Orkut, Ning, etc…) because a social network is all about access and different social networks would need different access between members. Anyway, I will end this here.

Later edit 2: It looks like there is an explosion of social network platforms. It is interesting to see how this will unfold: as far as I know the costs of coding to a particular social network API are pretty low if the application is well designed (you are simply coding to a container API with whom your application has a pretty simple interaction) so it is conceivable that developers for social network applications will be able to code to multiple social networks at the same time. Or who knows, maybe developing widgets for social networks will go the way of developing mobile applications: a highly fragmented environment where the costs of coding to a mobile device/operator combinations are so high that the developer is taken hostage by that mobile device/operator. Open Social tried to provide an API to make developing to the whole social networking industry easy (an initiative which bears many similarities with Google’s Android BTW), but they may fail.

Various thoughts on one hot buzzword:

One recent development in the IT world is the emergence of the Software as a Service, or of services that are provided to someone running an IT operation. This is due primarily due to the drop in the cost of communication which allowed for closer partnerships.

The most important thing about consuming a service is that it allows you to decompose the interaction with the Service Provider. While previously you needed to purchase a big,fat shrink-wrapped product and then orient your application around it now you can pick from the offerings that a service has and choose the ones that bets suit you from a cost, QoS, etc… perspective. This, obviously, doesn’t prevent the sale of consolidated service stacks. (However, you should be careful when buying a service stack because you are also buying the relationships between these the services in this stack. These relationships will ideally be customizable easily).

The different economics (the fact that you are buying the service thru a subscription rather than with one payment) drives a different interaction: the Service Provider has a big incentive to take you “hostage”. On the other side the consumer of a service wants to minimize the costs of transition from one Service Provider to another in order not to be taken “hostage”.Taking a Service Consumer “hostage” is done thru features, but it can also be done by coupling your application to that service. You should avoid coupling in order to avoid being taken hostage. Features that are not implemented by competing Service Providers will probably be more expensive and will also take you hostage (funny how you actually pay more for being taken hostage).
One type of coupling between a Service Consumer and a Service Provider is thru APIs. The Service Consumer should abstract the interaction with the Service Provider in order to minimize this coupling so that they could switch to a different Service Provider easily if they need to.The service consumers have the upper hand in this game, if the interaction with a service is properly designed switching to a different provider should be easy.

Another type of coupling between your operation and the Service Provider is thru data: you need to keep control over your data so that you can move from one service provider more easily. When you are moving from one service provider to another you should make sure that you keep control over the data so that your data is not taken hostage by your service provider. Providing data to your service provider should be a process that should be very careful organized, you need to keep a tight control over it. You need to keep a very tight control as well over the data produced by your service provider: invoices of the things you have sold thru that Service Provider, the customer records that a CRM service provider has about your customers, etc… A service provider which cannot communicate to you the data that it has produced on your behalf should be considered risky, you may be taken “hostage”.
One particular type of data that you may be interested in is data concerning the service usage. Consider this example: one retailer outsourced its B2C site to a Service Provider. The site was recording a lot of traffic, but very few sales were taking place. Click-path-analysis (which is essentially scanning the data of how the B2C service was used) eventually revelead that the check out process was confusing. The service usage data is vey important, especially if the service is facing ordinary consumers.

The services that are outsourced to an Service Provider are not services which are strategic an operation but rather services that have been commoditized to the point where they don’t differentiate one operation from another. This implies that you should not outsource services that your company counts on for getting ahead of the competition. For example, if the customer experience is at the crux of your operation it doesn’t make much sense to outsource it to salesforce.com, because this would eliminate one important arrow from your quiver. However, if you are building an operation that revolves mainly importing various artifacts from China you may consider salesforce.com for managing your relations with your customers.

The service that you subscribe to should have some latency, the SLA’s regarding latency should be somewhat relaxed. Most of the services will be provided remotely from a different data-center, this should be considered. This would add more weight to the fact that you should not outsource services critical and strategic to your operation. You could mitigate this by delegating coarse-grained services to the Service Provider so that the interactions between your applications and the service you are using are not frequent. This would mean that it pays off to delegate more functionality to the Service Provider, as a result the service they provide should be easy to customize according to your needs.

When you are outsourcing a service to a Service Provider you are also outsourcing the maintenance, operation and the security of that service and its data. You should make sure that the Service Provider’s op team is up to the challenge (this point is so evident I didn’t think it should be stated).
Software as a Service will probably continue to drive the commoditization of various IT operations, SaaS is about outsourcing non-differentiating operations to an entity best equipped to handle them.

A post of various thoughts that I have about Agile development.
Judging from my previous posts you may believe that I am against Agile Development. I am not, as a matter of fact I agree with a few of their ‘practices’:
I agree that you need the team members need to be constantly kept-up-to date with project developments, this way you can delegate tasks more effectively. I agree that you need to test your applications well, this makes your applications easier to change for one thing. I agree that iterations are a good way of developing a project which has a lot of uncertainty in it.
I would say that I agree with quite a few practices championed by Agile developers. What I have trouble agreeing with is the vagueness that pervades most Agile concepts. Most Agile concepts are pretty vague since Agile development aims to encompass all software development (not a small feat is you think about it) with the result that concepts can be stretched into being meaningless (just check out this Agile practitioner definition of developer). Agile practices are so easy to stretch that you would think they were constructed this way in order to avoid blame and reap glorious praise, to be honest sometimes I think this is their chief purpose.

Another problem that I have is with the total lack of structure when it comes to project management. Rather than this thick Agile soup that tries to have an answer to everything we would be a lot better off if we had some IT-management patterns, similar to the GoF design patterns, I am trying to figure out what OOP would have looked like without those design patterns and it is not a nice picture. Who knows, maybe one day some guy will write a book where you could read something along these lines: “we had this team made up of 5 people, 3 junior, 2 senior, we had this project in this environment. We had some conflicts between the 2 seniors which were resolved in this way. We determined that the best way to tackle these problems was to split the tasks in this way, etc…”. This type of book, a collection of effective and widely applicable project management patterns, would serve IT a lot better than the latest iteration of Agile practices.

If you have a homogenous team then Agile process will probably work for you. The moment you run into a team where there are big differences between members and their skill sets you will see a different set of dynamics because you will want to make the most out of each member’s skill set. Unfortunately, Agile development doesn`t have an answer to handle this.

The focus on developers going as far as to declare that you only need developers in order to put thru a successful software project is pretty ludicrous, it’s pretty ludicrous and pompous for developers to say that you only need developers for a software project, it sounds like a second-hand shoe salesman.

Small iterations and continous release sometimes run you into troubles: consider that you are exposing your application to the outside world (in REST or WS or whatever). Let’s say that you make a small change in the way the app gets exposed, like you added a method or changed a signature. The only way you can release this to prod is by creating a new version of the same service so that you don’t break the dependencies on the current service. Well, versions cannot be created very often or you run the risk of developing Versionitis, AKA version management problems. This puts a lid on the number of times you can port to prod, you will be able to port to PROD only rarely in order to avoid going into a versioning nightmare.
Continous release probably applies to projects where you have no or minimal interaction with outside parties or where you have a fair degree of control over their environments.

Agile development is mostly a mirror of various development practices occurring at various development shops which happen to have their a very skilled workforce (think ThoughtWorks and the like). It would be a mistake to believe that all of these practices apply outside of these shops. My opinion is that you should watch Agile Development from a safe distance, pick what you think works for you, try to formalize it in order to get it closer to your needs and move on.

As always I don`t have the time to finish this post, it has been gestating for a while now, so I will release it as it is.