In the beginning there was nothing except a business process (some piece of software that made money) and a database for logs and a few configurable values.
The process developers who built and managed the business process read the logs in the database and occasionally modified the configurable values by hand.
As the business grew subject matter experts were brought onboard. I’m going to call these people who need to make changes to the database but whose job description does not include writing code business users. For a short while they sent their requests to the process developers who made the changes on their behalf.
Of course if a process developer is spending time editing the database by hand they can’t be working on new features. And if the business users understand the business process and know what they want to change why not let them do so directly? So someone whips up a piece of interface software giving the business users a way to access the database without going through the process developers.
Since in this case there are limited advantages to understanding both how the business process functions and how to make a good human interface eventually the development team fractures in to two disparate groups, the existing business process developers and the new interface developers (aka “frontend developers”).
The interface developers spend all day writing software that translates questions and commands from the business users in to something the database can understand. The two ways they add value are by
- Allowing business users who do not know how to directly query a database to ask data-driven questions
- Providing the same users a safe way to modify the database.
Eventually a business user is hired who says “I’d really like to use SOME VISUALIZATION TOOL” to help analyze this data—this could be Tableau, PowerBI, R, or even Python. This gets plugged in to the database bypassing the interface software and reduces the first way the interface developers create business value (allowing business users to read the database).
This creates an interesting bubble for the interface developers. The business user’s are responsible for the care and feeding of the business process and the process developers have to understand the intricacies of the business process to improve and expand it. But the interface developers are stuck in the middle. Understanding the details of the business process does not make one better at creating a text box that prevents a business user from accidentally entering garbage input.
Afterthought
This section exists to help me explain what my job is to my family (hi mom!).
I’m an interface developer! The interface software is made up of three parts: the backend, an old frontend (AngularJS), and a new frontend (React). The frontends present data in a human-readable format and validates their commands while the backend understands how to communicate with the database.
The old frontend is not going to break tomorrow but is built with aging technology and we can’t keep it around forever. The new frontend runs in parallel and users will bounce back and forth between the two while we slowly migrate the functionality over piecemeal. The most difficult part is ensuring that the switch between frontends is a pleasant, smooth experience. They shouldn’t be the same (the old frontend is indeed old) but they must be similar enough and must load quickly enough to not break a train of thought as the business users navigate between them.
