Thursday, October 27, 2016

Release Notes

When we ship a software package, we should ship the documentation alone with the software.  Every time when a new release is available, a release note should be available as well.

If it is a Beta release, there should still be a Beta release note.

Friday, October 7, 2016

Software and service companies should work 24x7 like hospital

Actually this is true.  The expectation is high and competition is high.  Nowadays, especially SaaS based service companies, you are expecting the service is never stopped. Here is how we can accomplish:

Thursday, August 18, 2016

Only backport bugs already fixed in the main line

A development organization may need to maintain multiple branches for supporting previous releases and for developing some features that have huge impacts to the stability of the codes.

We should always have a main line that is whether the branches were forked from and will be synchronized with.

A bug fix should be fixed in this main line and then

Wednesday, July 27, 2016

Abbreviations I use

fyi = for your information
np = no problem
ttyl = talk to you later

Thursday, June 30, 2016

No regression bugs

How to ensure that there is no regression bugs while introducing new features?

Here are my thoughts:


1. Knowledge Sharing


Developers need to have the knowledge about the whole product, especially about how the feature he or she is responsible is being used.

No one would intend to make the code broken unless for political reasons, such as avoiding dependencies.  We can argue that the developers are careless.  However, in my experience, most of the cases, lake of the knowledge is the reason.


2. Document the dependencies