Define Project Goals and Purpose

[leoafarias]

Why does this project exist or should this project even exist?

As we go forward to define what this project is. I thought it would be important for us to break this down into some high-level pain points which we are trying to solve.

The technology landscape is getting more and more complex. However, I believe that we are in a great moment in which things can be simplified in many ways. One of the reasons the landscape is so complicated is due to the fact that we have so many build targets. Server, Web, Mobile, Desktop, and we continue to see even more use cases.

However, there has been a push for consolidation but in many ways, I feel were never fulfilled to its promise. For many reasons the technology industry has followed what some people have referenced as HDD, Hype Driven Development.

This has created a cycle which very few tech companies especially the ones that are outside the Top 100 big names have been able to solve. In my opinion agencies, startups, and smaller business suffer the most, as they are stuck implementing solutions that are not mature by the time they go live, or maybe never mature at all.

This project is an acknowledgement of the following:

• A lot of problems we faced today have been solved already. However, there is a cycle that happens that is frustrating which can be seen as an example on the microservices vs. monolith discussions.
• Our industry tends to throw away all these proven concepts and following a rabbit hole just to find out that there were reasons for some decisions in which were made. The proof is that in my opinion, the best software engineering books are decades old. The Pragmatic Programmer, The Mythical Man-Month, Code Complete 2, Clean Code, Clean Architecture and many others.
• We are creating an industry in which code and software are disposable.
• It has become almost an impossible task to onboard and train junior developers. We are building an industry of amateurs since these concepts are not being passed forward.
• Even though the software landscape has become more complex there has been a lot of consolidation. I will not get on a debate about the pros and cons which I am sure you can find them easily on Google. This project does reflect a specific opinion about how this consolidation could be beneficial, but I do not see many people or projects interested in this specific problem. I am willing to be corrected on this

What this project is not pushing for

• One stack to rule them all or limiting developers to only one language. I do believe the best developers are polyglot and are not intimidated by new stacks and languages. They do see them however with different lenses that go against the hype.
• That this stack is the ultimate and best stack and all problems can be solved with it.
• There are multiple ways of doing things, and debates happen and should about new technology and processes. However, in order for us to build long term software and onboard new people in our industry I do believe there needs to be some consolidation of shared knowledge and concepts.

What this project does believe in is at the following

PS. At any point, we might lose track of these priorities and get caught up. It's important we keep this in mind as we move forward.

• Software should be able to last for a long time (decades, or a lifetime, you can debate below).
• Multiple people and teams to work together.
• Knowledge about the project can not live with only one person
• Junior developers need to be able to be productive.
• Code needs to be maintainable, extensible without the endless loop of technical debt.
• We want to go deep on the stack and not stay shallow
• We need to be fast, and agile. Every decision we make it's because we believe in the long term increases velocity (maybe not short term).
• We are building monoliths, microservices, serverless, APIs, CLIs, IoT, mobile, web, and desktop apps. We need to share knowledge between those implementations.
• It needs to be adaptable. New databases, third party services, APIs, or new use cases. The foundation needs to be shared but should allow for high adaptability.
• Documentation and Dev Experience are critical.
• We change our minds when better evidence is presented.

Foundational Concepts and Infrastructure

• DDD / Clean Architecture
• Separation of concerns and layers
• Best practices for coding. Clean Code / SOLID
• Agile Process
• Tests should always be a requirement
• Code standards are always applied and verified.

I will probably continue to edit this issue as new items come up. Also, new issues will be created to address project architecture and organization.

[MrMaz]

I am a big fan of the "Contract" concept when it comes to solving the separation of concerns problem that you have outlined in great detail. It's easy to separate the concerns, but immediately after separating, now you have to define the boundaries and rules of interaction between those concerns. You must define those boundaries and rules with a contract, or chaos ensues.

Contracts are generally tedious and contentious negotiations. The bigger the deal, the bigger the contract, the longer the negotiation. In technology, it is easy to skip this step and start writing code. The challenge, I believe, is to find a way to make this contract negotiation as painless as possible, to prevent the team, especially the developers, from skipping this crucial step.

Just like in many areas of personal and professional lives, once a contract is complete, the real work can begin, with all parties involved having had their opportunity to fight for what is important to them, and compromise where necessary to get the deal done.

Types, classes, interface, schemas, signatures... all of these programming concepts are a form of contract between developers and their code and between applications and their local or remote resources. Defining and configuring these can present the team with considerable overhead and makes this step susceptible to being skipped. It can come in the form of pressure to deliver, laziness, tediousness, etc.

Overcoming the pressure to deliver functionality early, and allowing the technical "contracts" to develop can pay huge dividends almost immediately, most of which are outlined in the original post.

[leoafarias]

@MrMaz I think you are hitting on some very important things. The contract piece if implemented correctly creates a lot of room for value add. From scaffolding to validation and error logging.

I already have a plan to tackle this initial piece. Will probably be using JSON Schema for it. draft-08 or it is currently renamed 2019-09. I have read that this is supposed to be the final draft until a 1.0 version. More format support and could really help with validation which would be great.

Also, I have explored auto-generated documentation for that. I think it's a fine line, that we will have to walk on this, so the tool does not become the handicap of a project.

I will be opening a new issue to talk about particulars fo the project.