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.
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.