Alexander Mikhailian

…but because he is ashamed of your ignorance.

…when none cares what operating system he is using.

Ok, ok… it's just one of the mandatory requirements.

I had this stuck in my head for months, but only now managed to have some time to write it up

Below are two snippets of SQL code that do the same thing, namely extract the number of contact emails per year from a CRM. The result in both cases is something like the following:

+----------+------+
| count(*) | y      |
+----------+------+
|     1142  | 2012|
|     1148  | 2013|
+----------+------+

The first query is written against a heavily customized SugarCRM instance. The second is written against my own home-made CRM

SugarCRM

SELECT count(*), year(email_addresses.date_created) y
  FROM email_addresses LEFT JOIN email_addr_bean_rel
  ON email_addr_bean_rel.email_address_id = email_addresses.id
  WHERE email_addresses.email_address LIKE '%@%'
    AND email_addr_bean_rel.bean_module = 'Contacts'
    AND email_addr_bean_rel.deleted = 0
    AND email_addresses.invalid_email = 0
    AND email_addresses.opt_out = 0
    AND email_addresses.deleted = 0 GROUP BY y;

Custom CRM

SELECT COUNT(*), YEAR(created_at) AS y
FROM clients
WHERE email IS NOT NULL
GROUP by YEAR(created_at);

It should be obvious even for a non-programmer which is easier to understand. What is not obvious for non programmers is the amount of effort one needs to make before SugarCRM starts doing things it was not designed for. I could now start talking about the importance of data structures and how the UI is irrelevant, but this will take more pages than Google can handle.

Here's an example of software project management worfklow that I use daily.

Each project is split into two uneven parts:

• Definition of project scope and objectives
• Project execution and follow-up.

The main difference is that the former is document-based while the later uses a bug issue tracker

For definition of project scope and objectives, we edit a series of documents:

• Personas — a list of different kinds of people that may be using the product, e.g. readers, clients, journalists, etc
• User stories — a description of how these personas would use the product
• Functional requirements — a non-technical list of features induced from user stories
• Technical requirements — a list of technical features, induced from functional requirements
• Budget estimation — based on technical requirements and team skills.

There's also an optional Traceability matrix — a many-to-many mapping between functional requirements and technical requirements.

For project execution and follow-up, we use an issue tracker Assembla to define:

• Milestones — e.g. "Freeze data structures"
• Tickets — for individual tasks, such as "Update the logo"
• Components — to group tickets by origin or subproduct, e.g. "Marketing & Sales requests", "Newsletters"
• Time — estimate and invested time, related to a ticket or not.