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.

Be proud of your code!

I'm usually quite proud of my code. If I'm not, I keep polishing it. When I review code of my guys, one of the things I insist of is to have the person's name on his code. Like on Dexter Horton Building.

If the guy says: "but all I did here is just to add this one little function".
"Well," I say to him, "so add your name above the function".

If the guy says: "but all I did was to fix this line. I didn't really added any new line of code".
"Well," I say to him, "so add your name above the line that you fixed, with a date and explanation of the fix".

But if the guy says: "hmmm, I'm not sure I'd like to put my name here. I'm not sure it works so well". Then I jump and say "haha! this is exactly why I insist on having your name there. Not initials. Not your nick name. A name that we can trace back when you will be a big manager at IBM, so you better don't leave any bug there."



The building above is real. I took this picture myself (I won't let you know where it's located. If you're curious you would probably google it.) I use this picture when I talk about code review and my insistence on having the developer's name on his or her code. Alex from mistralzonline, already documented this picture as part of his talk on present and represent, at his blog "On Everything And Nothing In Particular".