Good vs. Bad & Ugly: Comprehensive vs. General Design

Let's assume a simple categorisation of business into trade and manufacturing.
Most of the companies that are active in a category, arrange and manage their processes - despite different fields of business- inspired by a similar and close to optimal pattern.  For example all trade companies share the same processes and concepts such as sales region, sales commission, petty cash and etc.  The pattern is called "best practice".

Good

Now, imagine that you have designed and implemented information software for 25 trade companies so far; naturally resulting in your extensive knowledge of trade firms' processes and requirements -put simply, best practice.  In other words, you do know what the customer wants and needs.

What happens if you decide to design a comprehensive information system for trade firms? As you know their requirements and best practices, supported by the trade business knowledge and understanding which you have already earned during last 25 implementations, you design a model that, with minimum complexity and maximum clarity, covers most of the a typical trade firm' processes. Not only your model but also your user interface are efficient and understandable by the customer.

This is what I call a "Comprehensive Design".

Obviously the model doesn't cover all processes in all trade firms but, those non-covered are a small fraction compared to what the model already covers.  In fact, your model embraces about 80 to 85% of a typical trade firm's processes which leaves you 15 to 20% customisation during an implementation.  The percentages I just mentioned are very famous in ERP world. 

Bad & Ugly

Now, imagine a totally different situation: you have designed and implemented information systems for 2 trade companies so far and all of a sudden you decide to design an information systems for trade firms in general. Let's see how your design is.

Clearly, the knowledge of a typical trade firm requirements and best practices which you've acquired during your 2 implementations -even if both were successful- is not extensive. So when designing you have take care of all the possible requirements -which you're not aware of yet- by designing facilities to easily change the behaviour of the model. This is the key characteristic of your design, happening all over your model since you don't know the real world's requirements and need to prepare for meeting them.

Actually, your model is a "General Design".

It doesn't have a skeleton -the extract of your experience and knowledge- rather it has lots of lots of features that help users customise all the aspects of it and all because you don't know what you'll be facing in a typical trade firm.
There is a design principle stating that "The design and usage complexity of a software is proportional to how much the software is generalised." In other words, the more general your design the more difficult its development and usage.

Because it is complex and doesn't have a real structure, the result is not a software that has a shape but such a flexible set of -sometimes inconsistent- customisation features that it hardly has any shape. Practically, you have to create a new software out of all the customisation features, In every implementation using the general design. 

Conclusion

• Comprehensive design is based on business knowledge, understanding the target market requirements and best practices and experience.
• Comprehensive design is easily grasped by users and it is easy to use.
• General design is based on a considerable technical knowledge, little business knowledge and incomplete understanding of the target market requirements and best practices.
• General design is complicated and not friendly from the user's perspective.

The following statement is a concise and precise summary:

"Do not generalise.  Generalisations are generally wrong." -Butler Lampson

Amailyser - The E-mail Analyser

Recently Ed Daniel (a friend of mine) needed to produce a time analysis report out of his e-mails and asked if I can help him.  Well, obviously I said yes.


I thought to myself, he needs charts and graphs and data querying from many aspects that I may not know.  So to me the best option is to load his e-mail important fields into an RDBMS (such as SQLite or PostgreSQL).  Later he can do whatever he wants with the data using reporting tools such as JasperReports and produce nice charts and graphs as he requires.


That was the motivation to write Amailyser (on GitHub).

• The language is Python 2.x; I could have done it in Perl but I'm learning Python and it seems like a wonderful practice to me. 

• For DB interaction I used SQLAlchemy a nice ORM mapper for Python.

• To read the e-mail messages I used Python standard library mailbox.

After downloading and extracting, you can run the Amailyzer (after you have modified config.py to suite your needs)  in a terminal:

$ cd amailyser/src

$ python main.py


The big picture is to read mailboxes, load each message, extract important fields and persist them in the database.

Below is the structure of the source:

Amailyser source tree

• config.py: This is where you can change the behaviour of Amailyser like which mailboxes to process and type of each of them.
• model.py: This is the model of database described in SQLAlchemy.
• workhorse.py: Contains two calsses MailBox and MailMessage.  MailBox opens a mailbox in mbox or maildir formats and processes each message inside using MailMessage which (optionaly) persists them to the database.
• main.py: Actually as a main is supposed to be, it doesn't anything special.  Just calls model setup routines and iteraties over items in the list of mail boxes, passing each one to MailBox.

To install SQLAlchemy please visit the tutorial on its website.

Talks at foss.ir: How to Promote Open Source In Iran and Role of ADempiere

Today I was at a meeting at foss.ir office. It was my first time and I was kind of surprised when I met the head, Mr. Ebadi; I was expecting a somehow old know-it-all guy but he was young. Later on I realised that it's an advantage that he's young: he's active! No offence to the older ones but it's just the norm, you know!

Before starting the talk another member joined us: Mr. Maddahi; another young motivated person.

It was almost a long meeting; we talked about 3 hours and the main topic was how to promote open source in Iran. They have alreay been active for about 4 years but mainly concentrating on the open source backbone software specially Linux.

So let's go to the summary:

---

Promoting open source software requires both enough enthusiasts to work on open source projects and enough jobs for them to make their ends meet. So it's a two-way movement: grasping and motivating enthusiasts while convincing and motivating the entrepreneurs to use open source software.

Fortunately there's little problem in finding enough enthusiasts in Iran as the talented young generation always attempts to seek new ways to explore the underlying mechanism of amasing softwares and what would be better for them than the open source world.

But about the entrepreneurs: here -and I think everywhere- they are mostly businessmen or business owners usually with little technical knowledge -they know how to run a business not how to run PostgreSQL on FreeBSD for example- and since the open source movement in Iran is young there's a broad mis-perception about open source for businessmen. When you talk about open source, what comes to their minds is a software with mysterious terminals and lots of weird commands with telegraphic outputs. Thus the first step to motivate them is to correct that wrong perception and that can be carried out by showing them how open source may come to their help and how they can reduce their costs using it: by showing them open source business software.

When it comes to business software, one of the most expensive and most fundamental softwares enterprises need is ERP. Here, each year thousands of USD are spent to just buy the license of a commercial ERP still less implementation and supprt services which are mostly banned by vendors because of the sanctions.

But there's an alternative to commercial ERP: open source ERP. It will be amasing for entrepreneurs if they know that they can reduce their costs and not worry about future customisations, features -specially regarding some weird business processes specific to Iran- and upgrades by using an open source ERP and having local experts for implementation and support contracts.

In order to show them that open source is the way to go, an Iranian community will be formed around the most active open source ERP in the galaxy: ADempiere! This community will work as normal in ADempiere SF and collaborate with others in forums and SVN while trying to concentrate on localisation for local business. By the time, through conferences, meetings and seminars entrepreneurs will know about how advantageous open source will be to their business and start to think about using ADempiere as their ERP of choice and that will be the time when serious open source job opportunities -besides existing Linux administrator ones- will emerge. At that point, entrepreneurs will understand that open source is not only terminals and command lines but an endless ocean of opportunities for business.

But how to do that? It starts by writing some conceptual and introductory articles about ERP and open source alternatives. Then when there is enough understanding about the topic, ADempiere will be introduced. Some workshops and demo sessions will be held to speed up enthusiasts getting familiar with the software. After that there'll be periodic workshops and small conferences to direct the efforts and make collaboration easier. After some progress in localisation, demo sessions to entrepreneurs will start and ...

---

It's a long way, isn't it? But we have to start walking, right now!

Thanks to nice foss.ir guys it was really a productive talk.

Will update upon any further events.

---

IFEM OS	ADempiere

Open Source Communication Tricks or How to Avoid Flame Wars

In open source world, communicating with members or community which is almost always carried out by using mailing lists or forums is crucial to a successful usage or development and it requires few simple but fatal skills/tricks. Usually failing to regard them leads to hot insulting debates a.k.a flame wars.

The most notable fact about such communication is that it's offline and the key to have a successful one is to avoid emotions! Below are some hints out of my own experience in real world:

1. Avoid writing words in all capital letters at all as it rises too much emotions about your message. If you need to place emphasis on a word or phrase it's much better to use _ (underscore) or * (asterisk) characters instead.
   
   For example instead of
   This bug CANNOT be fixed.
   write
   This bug _cannot_ be fixed.
   or
   This bug *cannot* be fixed.
   


2. When criticising someone else's work it's better to use phrases like "in my (humble) opinion" or "I think" to show the reader that it's purely your idea. Although we all know that when someone is writing a post/email she's just expressing her own thoughts -unless mentioned explicitly- we tend to forget this point when reading some idea against our work and start to think that the whole world is against us thus switching to defence mode unconsciously.
   
   For example instead of
   The new file you just added does not address issue X. You have to remove/edit it.
   
   write
   IMO, the new file you just added does not address issue X. I'd suggest you remove/edit it.
   
   
3. Talk directly and frankly in technical terms. Avoid using non-technical terms or words which rise emotions as emotions are difficult to comprehend even when you're talking to someone face to face still less through offline messages. Thus, believe me or not, most of the times your emotions are comprehended falsely so you better forget about them and stick to clear technical terms.
   
   For example instead of
   Your code is garbage!
   
   write
   As far as I understand (AFAIU) your code has 2 major flaws which can be exploited ...
   
   
4. In case you find a post/email insulting or offensive your best first choice is to ignore it. Trust me! An offensive post loses weight and offender feels pissed off if she feels that her post doesn't attract attention. If it happens again you may ask a moderator to warn or shoot her off the list/forum.
   


5. Don't use multiple punctuations in your posts; what good would they do while a single punctuation works? Again it rises emotions, so you better avoid it.
   
   For example instead of
   I'm stuck at this bug!!! How to fix it??!!
   
   write
   I'm stuck at this bug. How to fix it?