Just from the top of my head, here are some of my notes. Hope they are in any way helpful
"Is the application architecture correct?" - I think this question should be rewritten as "correct architecture" doesn't mean anything specific, as there is no one correct architecture. What about something like: Does the architecture fit our needs for scaling, maintainability, reliability and further extension of functionality?
As a QA, I would ask:
a) how often serious or blocking issues in production occur and how fast are they handled? Is fixing issues in production delaying new development?
b) are there any manual steps needed to deploy/release the software or fix issues? Similar to this: how long is the tech dept backlog and how fast is it growing or decreasing compared to new development?
c) how often a release date is moved because of delays? In agile: how often work items are dropped or added to an ongoing sprint?
d) how many issues are caught on each stage of SDLC? There should be as little as possible caught after the implementation/code review stage and almost nothing in prod... but if no issues are found after implementation stage, something might not be right as that might mean issues are "hidden" or "swallowed" in the code, especially if users complain but we can't see or reproduce the issues. This is related to logging and monitoring
e) how long does it take to run automation? Are there quality gates setup, example: pre-commit hooks running unit tests and/or code analysis?
I am a hands-on technical consultant w. a focus on cloud application development (specifically AWS) & product development and my goal is to help technical leadership deliver better software.
Location
McLean, VA
Education
BS in Computer Science @ Loyola University Chicago, MS in Computer Science @ Illinois Tech
Work
Consultant Principal Engineer & Senior Software Architect at Coherent Logic Limited
Re 1.) I disagree as there are plenty of wrong architectures and unfortunately once a bad decision at that level has been made it can be very hard to fix. You do get to the meat of the matter though when you said:
"Does the architecture fit our needs for scaling, maintainability, reliability and further extension of functionality?"
which I do agree with. These are good high-level questions but we still need to see what the overall architecture looks like and make sure that it makes sense. In my experience if a project is borked it's going to have a slew of problems, both low-level and likely high-level, including possibly the architecture.
Here's a made-up example conversation to help drive the point home:
"What's this Custom Cache project?"
"Oh we need to scale so we wrote our own caching solution."
This is probably a red flag as caching is a difficult subject and there are plenty of solutions available that do exactly this. Also if management indicates that there's no chance this application will ever need to scale and this custom caching code has tied in all over the app(s) in a way which aren't going to be easy to disable or remove completely, then we likely have an architecture-level problem.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just from the top of my head, here are some of my notes. Hope they are in any way helpful
"Is the application architecture correct?" - I think this question should be rewritten as "correct architecture" doesn't mean anything specific, as there is no one correct architecture. What about something like: Does the architecture fit our needs for scaling, maintainability, reliability and further extension of functionality?
As a QA, I would ask:
a) how often serious or blocking issues in production occur and how fast are they handled? Is fixing issues in production delaying new development?
b) are there any manual steps needed to deploy/release the software or fix issues? Similar to this: how long is the tech dept backlog and how fast is it growing or decreasing compared to new development?
c) how often a release date is moved because of delays? In agile: how often work items are dropped or added to an ongoing sprint?
d) how many issues are caught on each stage of SDLC? There should be as little as possible caught after the implementation/code review stage and almost nothing in prod... but if no issues are found after implementation stage, something might not be right as that might mean issues are "hidden" or "swallowed" in the code, especially if users complain but we can't see or reproduce the issues. This is related to logging and monitoring
e) how long does it take to run automation? Are there quality gates setup, example: pre-commit hooks running unit tests and/or code analysis?
Re 1.) I disagree as there are plenty of wrong architectures and unfortunately once a bad decision at that level has been made it can be very hard to fix. You do get to the meat of the matter though when you said:
"Does the architecture fit our needs for scaling, maintainability, reliability and further extension of functionality?"
which I do agree with. These are good high-level questions but we still need to see what the overall architecture looks like and make sure that it makes sense. In my experience if a project is borked it's going to have a slew of problems, both low-level and likely high-level, including possibly the architecture.
Here's a made-up example conversation to help drive the point home:
"What's this Custom Cache project?"
"Oh we need to scale so we wrote our own caching solution."
This is probably a red flag as caching is a difficult subject and there are plenty of solutions available that do exactly this. Also if management indicates that there's no chance this application will ever need to scale and this custom caching code has tied in all over the app(s) in a way which aren't going to be easy to disable or remove completely, then we likely have an architecture-level problem.