The document discusses problems in the software engineering field and proposes solutions. It identifies 4 main problems: 1) unsophisticated users require requirements analysts to create specifications, 2) non-programmers require programmers to develop minimally viable programs from specifications, 3) non-systems engineers require engineers to modify programs for scalability, and 4) a lack of standards leads to inefficient development. The document proposes addressing these by developing: A) a shared data structure, B) a user interface, C) a platform for minimal programs, D) software to generate standards-compliant applications, and E) framework extensions to guide further development. Ultimately, the document argues that vertically integrating software development from startups to enterprises could help solve large

1. Isolating Various Parts of a Bigger Problem: What We Face in the World of Software Engineering
Albeit invoking numerous unnecessary acronyms along the way.
Problem
Human requirements
analysts are
indispensable.
Unsystematic thinkers require
human requirements analysts to
produce minimally systematic
specifications (MSS-es).
Problem
Human minimally-
viable- programmers
are indispensable.
Non-programmers require human
programmers to compile MSS-es
into minimally viable programs
(MVP-s), and to deploy these in
production environments.
Problem
Human systems
engineers are
indispensable.
Non- systems- engineers require
human systems engineers to
modify MVP-s into reasonably
scalable programs (RSP-s).
???
I’m not sure if there is
a fourth stage, or not.
Presumably, until you have a
solution that smashes the first
three problems into oblivion,
getting to “arbitrarily scalable
programs” is an academic
concern.

2. You can probably tell, that this is really bugging me.
Problem
Human requirements
analysts are
indispensable.
Unsystematic thinkers require
human requirements analysts to
produce minimally systematic
specifications (MSS-es).
Problem
Human minimally-
viable- programmers
are indispensable.
Non-programmers require human
programmers to compile MSS-es
into minimally viable programs
(MVP-s), and to deploy these in
production environments.
Problem
Human systems
engineers are
indispensable.
Non- systems- engineers require
human systems engineers to
modify MVP-s into reasonably
scalable programs (RSP-s).
Why must we tolerate this?

3. Here’s how we currently do it.
Problem
Human requirements
analysts are
indispensable.
Unsystematic thinkers require
human requirements analysts to
produce minimally systematic
specifications (MSS-es).
Problem
Human minimally-
viable- programmers
are indispensable.
Non-programmers require human
programmers to compile MSS-es
into minimally viable programs
(MVP-s), and to deploy these in
production environments.
Problem
Human systems
engineers are
indispensable.
Non- systems- engineers require
human systems engineers to
modify MVP-s into reasonably
scalable programs (RSP-s).
“Rapid Application Development” Frameworks
E.g. Rails, Django, Laravel, Spring, .NET

4. Here’s what that leads to.
Unsystematic thinkers require
human requirements analysts to
produce minimally systematic
specifications (MSS-es).
Non-programmers require human
programmers to compile MSS-es
into minimally viable programs
(MVP-s), and to deploy these in
production environments.
Non- systems- engineers require
human systems engineers to
modify MVP-s into reasonably
scalable programs (RSP-s).
Framework X (e.g. Rails) Implemented by Joe.
Now we have framework X.1 “Rails interpreted by Joe.”
“Rails” Implemented by Petra.
Now we have framework X.2 “Rails interpreted by Petra.”
“Rails” Implemented by Chan.
Now we have framework X.3 “Rails interpreted by Chan.”
“Rails” PAINT ME A
Now we have framework X… N RAINBOW
This is
stupid...

5. 1337 Hacker:
“Startups don’t need standards.”
Tired Hacker:
“Well, it's still a waste of founder money.
Because every time they switch freelances, the standards run.
So it's an overhead cost - not interesting.
Have you seen some of these codebases? LOL
The startups die because
the software cost too much to pivot.”

6. 1337 VC:
“Don’t use freelances. Learn to code, or find a technical co-founder.”
Tired Founder:
“Fuck you.”
1337 VC:
“No, YOU’re fucked.”
(I’m sure we can do better than this.)

7. Let’s revisit the root problem.
Unsystematic thinkers require
human requirements analysts to
produce minimally systematic
specifications (MSS-es).
Non-programmers require human
programmers to compile MSS-es
into minimally viable programs
(MVP-s), and to deploy these in
production environments.
Non- systems- engineers require
human systems engineers to
modify MVP-s into reasonably
scalable programs (RSP-s).

8. We lack
- a system, with a user-interface for
non-technical users,
- that can accurately capture their
thoughts,
- and store them in a digital data-
structure.
We lack
- a compiler that transforms the same
data-structure into source-code
which follows the regulations of a
target open-source framework, with
guarantees that the output is both (1)
extensible and (2) scaleable for a low
cost, by a certified team, and
- a certification standard for such a
team.
We lack
- a compiler that transforms this data-
structure into a minimally viable
program that works for a few users in
a production environment,
- quickly (time),
- cheaply (money),
- repeatedly (for agility).
Can we reframe it, thus?

9. We lack
- a system, with a user-interface for
non-technical users,
- that can accurately capture their
thoughts,
- and store them in a digital data-
structure.
We lack
- a compiler that transforms the same
data-structure into source-code
which follows the regulations of a
target open-source framework, with
guarantees that the output is both (1)
extensible and (2) scaleable for a low
cost, by a certified team, and
- a certification standard for such a
team.
We lack
- a compiler that transforms this data-
structure into a minimally viable
program that works for a few users in
a production environment,
- quickly (time),
- cheaply (money),
- repeatedly (for agility).
TL; DR - we need to build...
A. The data-structure.
B. The user-interface.
C. The platform-as-a-service for minimally viable programs.
D. The software-as-a-service for standards-compliant whole-app-generation.
E. The framework extensions / heuristics that guide further manual development.

10. It’s a bit early for this, but if you’re looking for a growth trajectory...
A. The data-structure.
B. The user-interface.
C. The platform-as-a-service for minimally viable programs.
D. The software-as-a-service for standards-compliant whole-app-generation.
E. The framework extensions / heuristics that guide further manual development.
… all you have to do is make this network of services denser:
● your PaaS from C should extend to support the apps generated by D
● E should eventually target many different frameworks
● your UI from B should be the same UI that can be used for quick hacks on E

11. A. The data-structure.
B. The user-interface.
C. The platform-as-a-service for minimally viable programs.
D. The software-as-a-service for standards-compliant whole-app-generation.
E. The framework extensions / heuristics that guide further manual development.
… all you have to do is blur the lines here:
● your PaaS from C should extend to support the apps generated by D
● E should eventually target many different frameworks
● your UI from B should be the same UI that can be used for quick hacks on E
These are
B2B billables.
We’re vertically integrating
Software Development
From Startup-scale
To Enterprise-scale

12. A. The data-structure.
B. The user-interface.
C. The platform-as-a-service for minimally viable programs.
D. The software-as-a-service for standards-compliant whole-app-generation.
E. The framework extensions / heuristics that guide further manual development.
These are non-trivial problems.
Cognitive
Modelling
Human- computer
interaction
PaaS Scale
Enterprise
SaaS SLAs
Meta-systems
Architectures

13. Vacationeering
17 July 2015
Thank heavens for breaks in between paid work. I’d been meaning to work on
this, but hadn’t had time to think about it properly. I started out as a business-
user in 2008, and then tried to learn how to code web applications in order to
build my own projects. But I became dissatisfied with the ecosystem of
software development, in general. These are my current thoughts about a
broader problem in software development.

14. And then?
People keep asking me why I don’t work on my own startup. Well, for starters,
this is the size of problem that typically interests me. I have always thought it
would take many years to gain enough experience to attack problems of this
magnitude, and so here I am chipping away at them.
It’s the first time I’ve had space to consolidate my thoughts on this matter, and
so I haven’t decided which part of the problem to work on next, or if I should just
ask around for VC interest in the problem in general.

15. Later, later.
We’ll leave other problems to another day, and another slide deck.
As indicated at the beginning, there are many problems that concern me, such
as the efficiency of standard mathematical notion, the digitisation of
consciousness, the efficiency of tertiary pedagogies, and the computational
exploration of alternatives to Standard Theory [though perhaps, I should first aim
to properly grasp Standard Theory].
- Jerng