How to Differentiate Oneself in Business

Actually, as of September 2010 I don't know a firm answer to that question, but I think that the contemplation that leads to the hypothesis is probably inspiring.

Suppose we compare passenger cars that fit 2 to 5 passengers. Almost all of them have a staring wheel, 4 tyres, they're more or less of the same size and get the passengers from point A to point B. Usually they all get the job done, technically speaking, they're practically all the same, just switch the car on and drive. In an average non-highway commuting route the cars have roughly the same speed. Probably the skills of their development teams are also equal: an engineer from one of the companies can probably move to another company and be able to handle the job after about a year of learning.

However, obviously, there is a very big difference between Fiat, Mercedes, BMV, Toyota and Ferrari, despite the fact that they're all just cars that take roughly the same amount of fuel and get their passengers from point A to point B.

My hypothesis is that one way to differentiate something is to differentiate it in style, bias, not functionality or technically fundamental properties(i.e. a flying car or an amphibious car). There are different ways of achieving the same goal and there's always the matter of taste. It doesn't make sense to argue that apple juice is somehow better, more innovative, more effective, more functional, etc., than pear juice, but the two definitely differ and people have their preferences.

If the hypothesis held, the conclusion for me would be that even though I'm just an "average" software engineer/developer/whatever-nice-name and even though it probably is possible to find some other person that has at least as good or much "better" (whatever that means) skill set than I have, I can differentiate myself by the style of my software. For example, I can create software that solves a common problem that is already solved by my "competitors", but I can target people with certain habits or preferences, just like BMV and Toyota do it with their products.

Actually, it is also extremely simple to come up with totally UNIQUE products, ideas, by taking something that already exists and giving it A BIAS.  On can just pick anything one likes and quite randomly pick some field, let's say, gardening, military, medical aid, etc., and combine the two. Probability that a thing like this already exists on the market, is pretty low or if it's not low enough, combine something existent with 2 biases in stead of 1, etc.

Examples:
scissors -> gardening scissors,
tongs -> nut crackers,
cup -> coffee cup.

What regards to the business success of unique things, then that's probably subject to marketing and trial and error. After all, even the usefulness of cellphones was considered questionable at their early days. At early days of computing very few could imagine, how a house-wife or a teenager uses a computer, a personal one even, or that a granny needs a strong, military grade, cryptography for paying her utility bills from her living room, over a computer network.

For a halve joke I point out that what I've been describing in my current post is in line with the saying that every great scientist stands on the shoulders of giants. (I'm not a scientist, but development work is what software developers do.)


++++++++++++++++++++++++++

Added in May 2013: "Everything has been Done!

About Domain Specific Algorithms and Software Development Labor

The point of this blog post is to claim that by inventing new programming languages it is not possible to eliminate the labour of describing domain specific algorithms.

For example, an assertion that a file that does not exist, can not be written to, holds regardless of programming language. It is possible for the language designer or library author to make sure that the file is automatically created, if it does not exist, but this is already a labour of describing a domain specific algorithm.

Another example is matrix multiplication. A programming language with its semantics determines the notation, i.e. multiply(a,b) or aTIMESb or a.times(b) or whatever, but someone, be it the hardware designer, programming language designer or a library designer, has to describe the essence of the matrix multiplication at least somehow. The various kinds of implementation details and optimizations do not change the fact that someone has to do actual development labour to get the multiplication to work.

In practice it entails that whenever a new programming language is designed, a new "standard library" is created, the very same work of describing the domain specific algorithms has to be done all over again, unless the previous descriptions are reused.

From intuitive point of view, and yes, according to my personal subjective taste and impressions, software development productivity depends a lot on the notation and semantics of the programming language. As of 2010 I believe that the preferences for a programming language (read: preferences for notation and semantics) is subjective and depends on the chooser's background.

By noticing that most programming languages that are in use in 2010, share a subset of common basic data types, namely arrays/vectors, hashtables, whole numbers, rational numbers, boolean values, I have a hypothesis that a probably withstandable, but imperfect, solution to the reuse and the notation-switch problem is to share memory space (the common data structures) between different programming language implementations. A program would start in one language, then, without exiting, switch to another programming language and then switch to whatever other programming language. The programming language switch regions might, probably would, contain data structure mapping code.

A vague, raw, preliminary, syntax example, where a hashtable named "symbolspace" is reserved in all language implementations:

# We'll start in Ruby
s=(4+5).to_s

LANGSWITCH to PHP

$s_output='The answer is'.$symbolspace['s']
echo $s_output

LANGSWITCH to JavaScript

s3="From PHP we've got:"+symbolspace('s_output')
document.write(s3)

I believe that the .NET and Java virtual machines allow that sort of functionality, but it won't work out socially, because Java got acquired by Oracle, .NET runs practically only on Windows (no, in 2010 the Mono won't do) and in the end many projects, like Haskell, Python, Perl, etc., have their mainstream implementations on "bare C or C++", not to mention the extra work that it would take to port them and how a single virtual machine implementation would limit developer creative freedom. May be a solution is a set of automatically inserted, language specific, library calls that dump and load the values of the common data structures to and from something like the Memcached.

I'll update/modify this article, if I have changed my mind on this or made a working implementation of the Memcached biased solution. So, this blog post will probably be modified.

Array Indexing by Separators

In the case of arrays and strings one often needs to extract a sub part of them.

If one uses the indices of the virtual separators between and at the "edges" of the array elements in stead of the indices of the array elements themselves, one can eliminate conditional statements that check indices for critical values at the "edges" of the array.

Explanation by an example:

# Array indices:       0   1   2   3   4
               array=["H","e","l","l","o"]
# Separator indices: 0   1   2   3   4   5


#           0   1   2
GetSubarray(["H","e"],0,0)==[]         # 0-0=0
GetSubarray(["H","e"],0,1)==["H"]      # 1-0=1
GetSubarray(["H","e"],1,1)==[]         # 1-1=0
GetSubarray(["H","e"],1,2)==["e"]      # 2-1=1
GetSubarray(["H","e"],2,2)==[]         # 2-2=0
GetSubarray(["H","e"],0,2)==["H","e"]  # 2-0=2
GetSubarray(["H","e"],2,2)==[]         # 2-2=0


GetSubarray([],0,0)==[]          # 0-0=0

The thing to notice is, how it is possible to mark empty intervals, including the start edge of the string and the end edge of the string, by using the very same 2 indices that describe a substring start and end positions.

A more permanent version of this post resides here.