The Land of Software Development is quite complex.
After we have a business need and plan, we break it down into its atomic (simplest) form and afterward we can start to implement, write the needed code for it.
This, in a case of a small feature I am working on looks like this:
Business Need
For each Workstation (or production line), for each of its Shift we have to be able to assign a Shift Leader, who can only Manage its own Shift, with all available Management tools.
As Developers / Programmers / Software Engineers, etc. , we assume the existence of the following Objects, like:
1. Workstation
2. Shift
3. User Account
5. Multiple User Interfaces (UI) where you can work with these objects
6. A User Login UI where you can log in successfully, to know who is using the app.
7. Other important development details for Programmers: API-s, documentations, server-architectures, firewall settings, etc.
This is a very simplified description.
After we can check the existence of all of this, we can actually break down the needed feature.
In the needed feature above we have two separate objective:
1.: “For each Workstation (or production line), for each of its Shift we have to be able to assign a Shift Leader”
2. “who can only Manage its own Shift, with all available Management tools”
These features can be implemented by two separate developer (or development teams if justifiable) in the same time, if there is proper communication between them. Be it in documentation, vocal communication, email or any other medium, if they can agree in key points where these tasks depends on each other.
In this case it is something like this:
There shall be a “shiftleader” group, referenced by this key, letter by letter. This has a really important role, since if any team misspell it, even with one character, it will introduce a “bug” and the system won’t work in the expected way.
This is a really long post, but so far we only agreed in the needs on a business level, and we still didn’t write a single command.
Although we probably spent quite a long time with meetings and communication.
But now we are cool and set, so we can start to write code finally
And that has its own stages again.
1. We need a database where we can store the application data, in the needed shape.
2.1. We have to write code for saving and retrieving data in a way that is usable by the application. It is only responsible for that.
2.2. We need code for business logic, that transforms the data above into information and makes changes to it in a way, that will bring value to the business owners and the program users.
3. We need a “web api”, that is responsible for the communication between the server and the user interface (device).
4. We need a user interface, (that is a separate application again), be it a browser/web application, a desktop application, a mobile application, that receives data from the server and sends data back from the users’ device. This is what the user usually interacts with, what it can see. Buttons, text inputs, images, other written content, etc.
I like to think about it like the tip of the iceberg.
Automated Tests
We are still not done yet. If the project funds allows it, we have to write automated tests as well, to make sure the application really does what we intended and we have no major bugs.
This can happen before we would implement the business feature, that would serve as a documentation for developers (TDD – Test Driven Development), or it can happen after the implementation when we are in RD – Rapid Development.
None is better than the other, each of them has its own place in time that is influenced by:
* the size of the project
* how far along it is in development
* the size of the team (Do you have a specialized person for each role, or you have Full-Stack developers instead, also how many people is working simultaneously on the same feature)
* the size of the project fund
We could go much deeper into the rabbit hole but lets keep them for later.
If you are interested and have any question, I will gladly answer them.
See you later,
Botond
