Engineering

Full Stack System Development, a Subjective Overview

Since the beginning of my career as a software engineer, I have always wanted to create all sorts of applications, for learning purposes, for fun, for business (the dream is alive and kicking), etc. I have managed to finish some of them, most not, and later coming back to them, I found everything to be such a mess that is was actually a strenuous activity just to figure out what was going on. Everything was a mess and the project was abandoned. I did this again and again until I came to the realization that I needed a new approach.

But first I needed to have a context to better define my problem, in order to better put the right question and set a clear goal. While writing this, based on my previous working experience, I identify myself as a full stack and mobile developer. So there you go, this is the context. So asking the right question in this context is “what is the best approach to developing a full stack software system?”. The goal is answering the question, the goal is the approach I need.

Well in any approach, you need requirements, coding these requirements, testing and maybe deployment. But still, some question remain, like what is the relationship between all these steps, how does one step influence another, what is the correct order of these steps, why do they help me, how many steps do you need, etc.

What I want to do in this topic is to provide such answers based on my own subjective experience. Consider this an opinion, do some research on your own and decide for yourself if this approach is suited for your own project or you need a custom tailored one.

Also, consider this a work in progress.

So let’s begin.

But first, an overview of the steps I consider a good approach to developing a full stack software system.

 

The overview
  1. Business analysis
  2. System architecture
  3. Mockups
  4. System design
  5. System realization
  6. Testing
  7. Deployment
  8. Marketing

Now, let’s go through all the steps and say a few words.

 

Business analysis

Here is where you define the requirements.

But, remember, business analysis is much broader than requirements engineering. While requirements engineering focuses on developing engineering specifications for a product, the business analysis focuses more on the business value of a product, addressing people, process, and technology. In an Agile world, the business value of a product is more important for a full stack software system.

Obviously, this is a large topic which requires specialization as a business analyst.

As a software engineer, I am only interested in a partial result of the business analysis process, being the non-functional requirements, functional requirements and, if it is the case, a set of detailed wireframes with clearly defined user interactions.

The non-functional requirements judge the operation of the system, and they are used in defining the system architecture.

The functional requirements define specific behavior or functions, and they are used to define the system design.

It is very important to understand that system architecture handles the non-functional requirements and comes before the system design which handles functional requirements. More on system architecture and system design later.

I have also mentioned wireframes. Well if the system has some UI containers (user interface applications in the context of C4 architecture model) I consider them mandatory topics at the business analysis phase.

Wireframes are a graphical representation of the user interface, they are just the blueprint, no artistic design, or product branding is required. I do consider the detailed UX interactions as part of the wireframes, ergo as part of the functional requirements.

So let’s recap, what you, at least, need to get at this step:

  1. non-functional requirements
  2. functional requirements
  3. wireframes with detailed UX interactions

 

System architecture

It is mandatory to understand the architecture is the “what“, while the design is the “how“.

The architecture defines what the system does while the design defines how the system does it. The architecture is the blueprint, the documentation, while the design is the implementation abstraction, the code being the implementation.

From a different perspective, the architecture is on a higher level of abstraction compared to the design.

A software architecture model is a rigorous diagram or a set of diagrams, based on available standards, used to describe a software system.

A software architecture also uses the non-functional requirements in the modeling process.

If you want to read more on the topic in the context of a real example application, consider The C4 Software Architecture Model in Action.

 

Mockups

Mockups are a specialization of wireframes, they show the UX of the final product, they show what the final product should look and behave.

I have pondered a lot where to put the mockups step. This feels like the right place and this step can be done paralleled with the software architecture.

Of course, it is even better to get these mockups while at the business analyses phase, but that depends on the client and project.

For private projects, you can create them either at the business analysis phase or during the system architecture phase, either way, mockups have to be done before the system design phase.

 

System design

This is yet another interesting topic to discuss. Here you select the technologies which will have a big impact on the design.

You define the folders/packages for your source code and resources (consider maven for consistency).

You define the features of the containers (applications that represent your system).  A feature (application component) is an abstraction of some functionality with a high level of cohesion and low coupling. You usually use UML to define the features.

You also consider design patterns.

The branding also goes here, by implementing the user interface accoring to the mockups.

If you want to read more on the topic in the context of a real example application, consider Design Considerations After Architecture Modeling With C4

 

System realization

Finally, it is time to implement the system. This is just translating the design into code.

During actual development consider all OOP principals like:

  • abstraction
  • encapsulation
  • inheritance
  • polymorphism

The SOLID principals:

  • Single responsibility principle
  • Open/closed principle
  • Liskov substitution principle (design by contract)
  • Interface segregation principle
  • Dependency inversion principle

Clean code principals:

  • From the Clean Code Book by Robert Cecil Martin

Also, consider other schools of though in software engineering.

If you want to read more on the topic in the context of a real example application, consider Design Considerations After Architecture Modeling With C4

 

Testing

Testing is a complex topic by itself. We are just going to say a few word about system testing and acceptance testing.

System testing is the process of “black box” testing the complete integrated system to evaluate its compliance with the requirements, normally done by independent testers.

Acceptance testing is the process of “black box” evaluating the system’s compliance with the business requirements and its availability for delivery.

We normally do unit testing and integration testing while developing the system. The order is as follows:

  1. Unit testing
  2. Integration testing
  3. System testing
  4. Acceptance testing

 

Deployment

You can now deploy the system as appropriate.

You can deploy the backend part to a custom server or a cloud solution, the mobile application to a store like Google Play, etc

Again a complex topic by itself.

 

Marketing

And if you are developing a business product, with the intent to make money or reach a target audience, then here comes the marketing phase.

 

Lessons learned

It takes time to plan a project, but once you have a clear idea of what and how you want to do in/a software project, the actual implementation phase almost becomes a routine.

Take enough time to plan the design, it will be well worth it. Without a good design plan you will refactor and refactor until you get a clear picture in your mind of what you want to achieve, and then you refactor again to achieve that goal. You will probably get the same result but with a high cost of, from personal experience, three times as much development time.

It is amazing to see how a good architecture can lead to a good design, which in turn can lead to good code.

There are a plethora of things to consider when doing a complete software project. It takes time to learn all of this stuff, it takes time to understand how to fit everything together, it takes time to easily navigate a project from overview to details and vice versa. Do not get overwhelmed, remember that the more time you invest in something the better you will understand it.

Also, consider everything described here as a school of thought. The field of Information Technology is still young and we still struggle to find a common language between software engineers.

You can design the architecture either at package level or module level. It depends on the context of your application. If you have a small system, I would suggest package level design for clean architecture. For complex projects module is the answer.

Small details can come and bite your ass hard if ignored in the business analysis phase.

If is also a good idea to review these steps often, because it can lead you in finding a different paradigm, better suited for your own needs.

This is only a proposed solution and a work in progress.

Spread the knowledge