A Software Problem (and a maybe-solution)
0 likes478 views
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
![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](https://image.slidesharecdn.com/asoftwareproblem-solution-150616203105-lva1-app6891/85/A-Software-Problem-and-a-maybe-solution-15-320.jpg)
A Software Problem (and a maybe-solution)
- 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