Remember project management triangle: time, scope, quality.
The more time you put into development or testing, the less bugs you may find.
The less scopes you push into the application, the less bugs you may get.
In agile, you need to decide the least scope with the least time to develop an acceptable quality of working product. New changes introduce a new complexity to the software, and devs need time to formulate the right complexity. You need to make a balance between time or scope, or the complexity of the software will produce either less testable or less readable codes, which leads to more buggy app.
If the agile approach seemed to be cause of it, then the agile process must have been conducted improperly.
I work as an IT guy in a bank. I hate my jobs, and pandemic makes it worse.
I think pandemic has driven the company to change its business. This forces the people to work on anything to save the business. Work more hours for urgent project, conduct different roles.
I see my friends from other companies like ecommerce work more hours too. I think pandemic has made us working more hours, and it makes people unhappy with their jobs.
To deal with it, I need to understand this situation was caused the pandemic and keep sanity and health in check. I don't think changing employers is a choice when expected reasonable working hours to not hate jobs. I know when I change job, I will still work more hours.
Software engineers should be excited about their company's product because they are the only ones who can see how software can solve the customer's problem.
Business people can say AI can help business, but they don't know how AI can solve which problem in the existing process. For example, search engine was once a cranky tool in the web. It is not usable, everyone hated it. A guy should assemble a "coding" for the query to get a good result. Before it was cool, PageRank algorithm was a lab thing in the past, but until Sergey Brin and Larry Page used it for search engine, it
changes how search engine works and everyone finally loves search engine because they don't need to assemble a complex query anymore, but simply throw some keywords. You name that company, Google.
It beats other big names at that time, such as Yahoo, Lycos, etc.
Back to your case, I think the company wants it happen for them, like Google.
Depends. Companies with stronger financial tend to less affected to sentiment. But to beat the market, sentiment is the key that makes the difference in the equation.
My top down approach for writing software design docs:
1. Business objectives
2. Users and use cases
3. Architecture <- design decision, performance expectation, wide picture of the system
4. Infrastructures <- you may mention environment and networks here, like k8, aws or gcp.
5. Application <- ui, flow, activity diagram, algorithm here
6. Data <- now you can place UML here
As for code level documentation, writing readable codes is enough as documentation. If some guys can understand what the codes do by reading the codes, documentation won't be needed. How to write readable codes? A good reference for this is Clean Code book. If documentation is really needed, Java Doc style is worth to follow.
So far domain driven development is relevant to my job. I was working at online travel company, developing backend services. I found this paradigm is useful when deciding where to put codes. Since, the codes are managed by domain, it becomes easy to separate responsibility of the team. Each team can have clear ownership by mastering their own domains. For example, my team owned user related codes, while another team owned flight or hotel related codes. In addition, it becomes easier to determine resources based on the performance of each products, for example when flight product is getting more sales, then the flight team needs to increase their computing resource. It turns out this development approach still works for 8 years for the company.
I also think this approach is still relevant for developing software projects, since it becomes a trend that the organization structure of modern companies follows the structure of its product lines.
Remember project management triangle: time, scope, quality.
The more time you put into development or testing, the less bugs you may find.
The less scopes you push into the application, the less bugs you may get.
In agile, you need to decide the least scope with the least time to develop an acceptable quality of working product. New changes introduce a new complexity to the software, and devs need time to formulate the right complexity. You need to make a balance between time or scope, or the complexity of the software will produce either less testable or less readable codes, which leads to more buggy app.
If the agile approach seemed to be cause of it, then the agile process must have been conducted improperly.