Sun's Future

Rumors on IBM about to acquire Sun has taken Sun's stock up recently. The idea of Sun being acquired were running around already for some months when Sun's stock was dropping to 10$ (e.g. here, from August 2008). Today Sun is traded back at about 8$, after jumping more than 60% in the past two weeks.

When Jonathan Schwartz, Sun's CEO, announced the change of Sun's ticker from SUNW to JAVA, at August 23rd 2007, that was the beginning of the end. The price of the stock was around 19$ then, after visiting 253$ (!!!) seven years earlier. The main problem is that unlike Microsoft or IBM, Sun never succeeded in making money out of software. They had a history of starting software products and then shutting them down, and they never really cashed the success of Java. Sun is a company with technical excellence and innovative spirit, but for the benefit of itself and of the software market, it shall find its place within a company that knows how to cash out these qualities.

-------------
May 2009:
Well, by now we all know that it was Oracle eventually to buy Sun. Still keeping the above relevant. I'm surly wishing all the best for this couple. And for IBM as well of course.
-------------

Software Factories

Before the industrial revolution most of the products were made by hand, crafted. Is software manufacturing today more like a confection (ready made clothing) or more like "haute couture"?

The term "Software Factory" was created for describing the possibility of getting software requirements and sending them into a "factory" for manufecturing. (Do not mix that with a Microsoft technology with a similar name).

The challenge is that with software, customer needs may be very complicated. Can we just send the requirements into a "Software Factory" and get it done? (This in some way contradicts the idea of constant communication embedded in Agile Development.)

Think of airport control system that needs to address all kind of airports and equipment. Think of banking software that shall address different banks and communicate with all sorts of external interfaces. Can we create modules that are generic enough so that customization for specific customer needs can be done by cheap work force and without too much complications and investment?

Most software projects cannot be cloned. There is no customer that resembles another, requirements are different and the "physical" legacy environment is not the same.

Closets are also not all the same. Each customer may have different specific requirements. Nevertheless, most carpenters manage to stay scalable and address specific requirements by setting standards, such as several available sizes (you can order a closet of 2.0 or 2.4 meter height, however, 3.0 meter height would be a special order, would be processed uniquely and priced accordingly) and several available woods.

To achieve the ability of creating software as in "Software Factory", we shall:

1. Narrow the options and alternatives. State clearly what can be built as a standard and what is a special order.
   
2. Externalize a clear API
   
3. Insist on always getting clear requirements before starting (did you see a carpenter starting to work on a closet before having all measurements?)
   
4. Have core modules, easy to customize for very specific needs, with hooks and plug-ins for adding specific functionality
   
5. Create a very strict and close way of customizing the product, allowing it to be done by cheap work force. Always prefer customization techniques which require less thinking. Customization shall not be art, it shall be very technical and strict, preferably with clear instructions.
   
6. Both the core module and the customizable product shall be easily testable, each on its own.

I had a debate recently on whether the preferred technique for rendering raw data into HTML is JSP with Taglibs or XSL. Though XSL is very powerful and can do anything with raw XML at hand, I argue that a set of strict Taglibs with the instruction not to use Java code inside JSP makes it much easier to make this task in the mode of "Software Factory". In oppose to XSL, which is in some way an "art", using a strict set of predefined Taglibs is something that is much more narrowed, cannot handle all cases and special requirements, but can certainly provide most needs and most importantly, can be done by almost anyone, given clear requirements.

We are already in a period in which most organizations cannot afford having their software be "haute couture", they must settle on confection, ready-made, with some adaptations. Most software companies who would still manufecture their organizational software products as "haute couture" would not survive, unless in very specific and unique domains. When software becomes a commodity, like a cheap chip, the only way to produce it is in a "Software Factory" model.

Real Life Architecture

When designing a system one shall think of all possible scenarios and error cases. Ignoring a possible scenario may lead later to all sort of problems, ranging from crashes to logical errors (e.g. fulfilling a financial transaction without finishing the order process, so the customer is debited but would not get any product).

One thing that we shall bear in mind is that listing all possible scenarios does not mean implementing a solution for all possible scenarios. There are error cases that are quite rare or not-so-rare but very difficult to handle, maybe even require a whole different design approach. A possible solution may be to log the problem to a specific database for manual handling, or for a later amending batch operation. Such approach can save a lot of the hassle during all stages: design, implementation and maintenance.

I may rephrase the above rule: listing all possible scenarios is a MUST, however, implementing a solution for all possible scenarios as an integral part of your system is probably not always the best solution.

Usually implementing a fully-blown solution for rare cases doesn't really work, as it is not tested enough for all variants and nuances of the exact scenario, and when the rare cases do happen you see that some modifications shall apply. Taking the treatment of rare special cases outside of the system, to either manual or batch operation may thus be a wise thing to do.

I call this "Real Life Architecture" based on the famous article by Gregor Hohpe Starbucks Does Not Use Two-Phase-Commit, which appears also as a transcript at Joel Spolsky's The Best Software Writing I. Gregor argues that in real life we often use asynchronous messaging without worrying too much about error scenarios, which we do deal with when happen, in somewhat batch way. As an example Gregor goes through the ordering mechanism at Starbucks, its simplicity and efficiency.