nomorefools

Agility has nothing to do with software quality.

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.

Did you bring an Android phone?

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.

Hope this helps

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.

Sorry for my bad english.

The perception about an SaaS product's price might depend on how customers value them.

I want to mention SiftScience as the example. Note that it's a B2B SaaS product. The company I am working for is running an eCommerce business. They utilize SiftScience to fight credit card frauds. They paid them around $50K/mo for detecting frauds out of 1 million transactions/mo. At the first time, I think it's expensive enough, because credit card fraud is one of hundreds problem in the company and it is not the only payment options for buying the products. The company can just hire skilled programmers to build only fraud detection for less than $50K/mo salary.

Not until I know their future plan that they are going to jump into financial industry. The money will move very fast. Credit cards will dominate the payments and the chance is there will be more credit card frauds too. The company wants to build the customers' trust before the product starts to launch in order to attract many users. So, we need to reduce fraud cases as much as we can. Using SiftScience sounds like outsourcing the fraud detection works to other. With it, we can increase how many transactions will be monitored instantly. Hiring high skilled programmers might be a late choice here, but we can do it in the future if the product is successful. With that case, I can say that SiftScience fraud detection product's price is worth it.