"Too much salt in food and it will taste bitter, too little and it may taste bland"
The above analogy was given during my code review 10 years back by experienced colleague in context of a real time data collector module made using C Programming Language and pthread. I went on to refactor the module. Simplified the project layout, removed data structures, global state machine based code branching using an array of function pointers, configuration that was making the software difficult to understand in entirety.
Imagine if you have a team of Django/Python developers of 25 with only 3 Developers who are experienced and rest freshers. You choose to build a web application in Python that uses
- Django cookie cutter
- Dockers Containers
- Django Rest Framework based API
- redis for caching
- Ansible scripts for automating deployments
- Over 3 dozen Django Third Party App ( this doesn't include dependencies )
- Custom middleware doing everything from logging, analytics, caching
- Making Django Signals way too many things it shouldn't be doing
- Two NoSQL for storing different type of information.
- Not using Django template but jinja
- Not using Django models
- Used a obscure queuing system because some article was trending on hacker news
Software abstraction is like salt, sprinkle the right amount and what you have is a tasty meal.
What is the right amount ?.
Have good decoupling of your components and clear definition of responsibility of each layer in your architecture.
Understanding of Where to use Data abstraction ? and Where to use Control flow abstraction ?
Introducing more abstraction to solve workflow, execution flow issues due to concurrency / not encapsulating user actions / issues that require correct selection of algorithm/data structure is like rubbing salt on wounds.
Be considerate of the skillset, team composition, training and onboarding required to get everyone on the same page. May be have a consistent hiring policy.