Architecting for HS

Looking at https://github.com/ogt/boxchareditor/issues it is interesting to see how the issues and the source code evolved to make the subsequent HS-ing of the todo list easier - both for the HS programmer as well as to minimize the final merge from me.

Parts of the code that could be extended, were given name (e.g. type), they were pushed out as a separate file (to minimize merge headaches. A normal refactoring of the code following DRY principles would have resulted in a possibly more compact code that attempts to find/understand the shared aspects of the logic between various fonts.  (thin thick type vs single double line).

Even the functionality itself was influenced - ( I was considering "switching on the fly from single to double to thick... as part of the drawing, I gave up after I broke them up independently) 

The interesting thing is that even though originally I thought that the variants(types) are very similar so there is a common underlying logic and just a table that maps fonts for each different type.... that ended up being an incorrect assumption.

Single-double line has a different set of "combination" characters. Many of them overlap - but not all.

This means that the code that handles everyone would need to have the union of all the combination chars, disproportionally raising the complexity of the algorithm and essentially forcing me to think of use cases that don't even exist in practice.

The approach of fully separating each type, allows them to diverge as needed, and while it involves some repetition it results in a smaller/easier to understand function for each type.

As I go through the todo list, I find often these "dimensions" that make very easy to create additional HS tasks if I have already described one. For example "porting" for sublime,eclipse, ACE etc. is another dimension similar to "type".

The other realization is that I was unable to HS the boxchareditor from scratch. I mean I could but I wouldn't get the architecture that would allow me to do the subsequent HS-ing.

In that sense the model we are following is a model whose ideal target (as HS client) is a very strong developer, (a developer with very strong architectural traits). You need to be such a developer to produce both the first version of the code and write the code in such a way that you can subsequently leverage a large number of contributors without spending too much time in education, documentation, merging  etc... 

So this HS is better targeting people that are strong developers that do have budget. That doesn't have a strong overlap with OD's clients or contractors. It might have more overlap with github's network.

On the positive side, creating a system that is targeting/attracting/gives more superpowers to top developers is bound to have good marketing characteristic - would not have to deal with the uphill marketing battle that OD had to face for most of its first years.