IDX – Integrated Developer Experience

idx.png

Move aside IDE’s (Integrated Developer Environment) – it’s time for the new kid on the block, the Integrated Developer Experience!

Ok, so the acronym is already taken (Internet Data Exchange, Indonesia Stock Exchange, and probably others) but I’m co-opting it for how to talk about FlowSharpCode.  I’m actually surprised “Integrated Developer Experience” isn’t used somewhere already.  Maybe my google-fu is not up to snuff right now.

FlowSharpCode Gets DRAKON Shapes

drakon1.png

I’ve added some select DRAKON shapes for creating flowcharts.  The Python code in the lower right editor is generated from the flowchart, and the output from the run is shown on the left.

PyLint is also now integrated into FlowSharpCode’s PythonCompilerService.  This really improves the development process as many syntactical errors are detected before even running the code.

Also, the code generator creates an execution tree which independent of the language syntax, which means that support for other languages is easily added.  Now granted, the code itself in each of the DRAKON shapes is Python code, but I have some ideas of how to make that code agnostic as well.

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

stencil-small.png

Article posted on Code Project here.

Excerpt:

“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.