UI and business logic or the chicken and egg problem
Recently I'd faced the challenge of wiring up a newly implemented (by another developer) UI layer of a web application to the application itself. The UI solution was very complex with lots of cross-event dependencies and a fancy labyrinth of nested template references (who knows Angular can definitely relate). The reason why the author hadn't finished up that task himself was apparent: they needed to connect this UI to an already existing feature (out of his pure-UI area of responsibility) and refactor the underlying business logic layer without any domain awareness. The situation was complicated by using dynamic reactive forms for this feature.
So for some reason, the idea of implementing the bare UI solution (HTML+CSS basically, through custom shared UI library) and passing it for further revitalization was considered a good one by our Product Owner. That's how I ended up in front of my IDE in complete frustration.
Long story short, I had finished this tedious mind-blowing chunk of work, and it started to look and function as intended again, but with a new shiny layout and styles.
The predictable aftermaths were:
- extra time spent by the first developer to mock functionality for the newly implemented UI layer
- additional time spent by the second developer (me) to wrap his head around the new contraptions, and their mock data flow
- complication of business logic to adjust it to UI scaffolding
Needless to say, I was angry with all these consequences. This case made me think a lot about the correct and appropriate flow of developing application features, both in general and with Angular in particular.
In my humble opinion, the following summary should be added as a de-facto standard for software development processes. Probably even written down in the corresponding guidelines (documentation) of each specific project.
Okay, to not be like this, let me just suggest it as a good practice for working on existing front-end applications (i.e., refactoring).
So here they are, three simple yet powerful rules of approaching a feature refactoring:
- Always compile detailed business requirements ahead of development to avoid deep rework
- Don't separate work on interconnected layers of a single feature between different developers (unless it's pair programming)
- Start from mechanics, finish with UI, not vice versa
These three rules will allow a project manager (or a team lead, a product owner, or whoever it might be) to shine and their team to be productive, efficient, and fast. Moreover, they prevent burnout and lower blood pressure, it's verified.
Software development should be a mindful process not only as a whole but also in its parts. That's how we put all these separated concerns together.
Cover photo by Daniel Tuttle from Unsplash