The Juice

the juice.png

I was recently asked (paraphrasing) what parts of the work of software engineering do I find “juicy” so I came up with this diagram. Any software engineering task involves both developers (if only me), customers (might be a client), and the processes of design and implementation.

The “external” blue lines are where the customer potentially interacts with the developers, the output of the design, and the implementation phase (you can probably imagine how Agile fits in this.) The “internal” red lines are where the developers interact with the each other and the design and implementation phases.

From a certain perspective, the left side represents the “process” and the right side represents the “results.” Process and results should be balanced – developers may discover they require training in new skills, teams adjust based on where the team is in the process, etc. The process creates results which the developer and customer team review.

The process – results flow iterates with each result. The earlier results are produced, the better for everyone because this is where “education” occurs, for example, the developers learn more about the customer’s requirements, the customer may refine their requirements (or change them!) Both the developers and the customers learn things during iterations which in turn create adjustments in the process.

The list of items within the boxes is basically just all the stuff that I find “juicy” – the more of those items that get checked off for a project, the more excited I typically find myself regarding working on the project.

Why Is It So Hard Finding Programmers To Work On Your Open Source Project?

Code Project recently did a survey “How much time do you spend (on average) working on hobby programming projects?” where “A hobby project means one you’re doing outside of work or school for your own enjoyment / amusement / nefarious ends.”  1289 people responded, with the following results:

survey results.png

While not stated, the survey was intended to be per week.

Also keep in mind that Code Project caters primarily to developers using the Microsoft technology stack, so who knows what these results would be for other technology stacks.

If we consider that a usable number of hours per week on an open source project requires at least 5 hours a week, we see that about 32% of the respondents have the time to commit to “hobby” projects:

5 to 60+ hrs 407 0.315749
Never to 5 hrs 882 0.684251

If we throw out the 30-60+ hours results based on my total conjecture that most people needed for open source projects have full time jobs and are skilled professionals in their industry (here my conjecture is that someone that has 30+ hours doesn’t have a job and/or is not yet qualified as being a “skilled professional”), the numbers are even worse:

5 to 60+ hrs 307 0.2582
Never to 5 hrs 882 0.7418

Only about 26% of programmers spend time on hobby projects.

While this number seems promising, consider:

  1. Most of these programmers are probably spending time on their own projects.
  2. OK, but there are 18.2 million software developers worldwide (source)
  3. In 2012 there were over 5 million FOSS (Free and Open-Source Software) projects (source)
    1. In 2017, this number can only have increased dramatically
    2. And you’re going to attract programmers to your FOSS exactly how???
  4. Let’s say there’s 7 million FOSS projects now (2017) – (I was not able to get a number from Google past 2012)
  5. That leaves roughly 2 programmers per FOSS project.

Let’s look at the 2012 number a bit more.  In 2012, GitHub had around 1/2 million active repositories (source).  In 2014, this number was 2 million.  That’s a 4 fold increase.  The source quoted in item 3 above claimed 4.7M repositories, but according to the GitHut source, only 1/2 million of those were active (about 1/10th.)  So realistically, we should say that at least by 2014, there were 20 million FOSS projects, if we continue this 1:10 ratio of active vs. overall projects.  Again, this number can only have increased by 2017.

Let’s look at it in a different way.  What’s interesting about the GitHut graph is that it essentially shows a linear growth of active repositories between 2012 and 2014.

active repos.png

If we consider this linear trend to remain through 2016, we might expect to see another 4-fold increase by 2016, making for 8 million active repos!

Great, 8 million active repos, 18 million developers, so we still have about 2 developers per active repo to work on my project.  Uh, no.  How many of those know the programming language you use, not to mention all the other tech that your project uses?  A responder to a Quora question on how many C# developers there are (source) uses a WAG of 8 million.

C# projects on GitHub are only about 6.3% (in 2014, GitHut source) or about 140,000 projects.  Let’s say that percentage stays constant, but there’s a four-fold increase in the number of C# projects, to 540,000.

  • 8 million C# devs
  • 25% of them are available to work on FOSS = 2 million
  • 540,000 C# projects

We’re still looking at only 3 developers (ok, 3.7) for a particular project.

So I have two questions:

  1. How in the world are you going to find those 2 to 4 developers to work on your project, assuming they are even interested in your project???
  2. How in the world are you going to attract those 2 to 4 developers to your FOSS project, one out of more than 1/2 million???

Any reason to suspect my analysis is wrong?

What Might a 6GL Look Like, Take II


Article posted on Code Project here.


“DRAKON rules for creating diagrams are cognitively optimized for easy comprehension, making it a tool for intelligence augmentation.” (source) This tool was ultimately replaced with a visual computer-aided software engineering (CASE) tool was developed in 1996 and has been used in major space programs!  Current DRAKON editors support C#, Javascript, Python, etc! 

Classical flowcharting is definitely obsolete, however, in my opinion, a visual way of programming that supports both low-level and higher-level expression of concepts is a path to reduce the translation effort required to take human meaning and convert it into machine meaning.  It also seems to me that such an approach can become a viable mechanism for an AI to actually write original programs, using building blocks that humans (or the AI) has previously written and most importantly, for us humans to visual whatever it is that the AI creates in a way that is comprehensible to us humans.  With virtual reality, we should be able to create programs in a 3 dimensions, and even watch another programmer (or AI) create / modify existing programs.

What Will a 6GL Look Like?

First generation languages (1GL) were closely tied to the hardware, requiring the human operator to physically manipulate toggle switches to enter in the machine language instructions directly.

Second generation languages (2GL) can be loosely categorized as assembly languages.

Third generation languages (3GL) abstracted assembly language into a more human readable syntax.

Fourth generation languages (4GL) are distinguished from 3GH in that they are typically further abstracted from the underlying hardware.

Fifth generation languages (5GL), which abstracts the language itself such that it is based on “”solving problems using constraints given to the program, rather than using an algorithm written by a programmer.”

What will a 6GL look like?

In my opinion, it will look a lot like FlowSharpCode in which programs are written by piecing together the building blocks of smaller pieces of code (“behaviors”) using very visual tools, either a 2D canvas or a 3D virtual surface.


And while we’re at it, a 7GL?

Some may argue that a 6GL will be an AI, but again in my opinion, an AI that truly succeeds at “writing” an original program will do so by building from smaller behaviors.  Expecting an AI to produce “code” in the languages that exist today is, well, a cute but absurd thought.  A successful AI most likely will utilize some kind of “visualization” (whatever that looks like to an AI) for manifesting its “imagination” into concrete behaviors.  And most likely, whatever visualization system the AI uses will most likely be able to be mapped onto a 3D or 4D (including time dimension) surface for us to peruse.