How do you call the discipline which consist of making the right choice of language/paradigm/class diagrams? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question

As a physicist, I've learnt programming on my own. But I would like to know the name of the discipline (like algorithmics is the discipline of designing algorithms) which consists of :

• making the right choice of language/paradigm
• designing a class diagram
• organizing the different parts of a code and how they will interact between each other

Answer 1

I believe the term you are looking for is Software Architect.

Here's Wikipedia's definition of Software Architect
And here's SEI's definition of Software Architect

However, the criteria you provided are a bit nebulous.

making the right choice of language/paradigm

It's pretty rare that a project is able to swap out its existing language or overall architecture. Those choices can and do occur with green field projects (aka brand new ones), but it's generally considered a catastrophic change for an existing project.

However, an architect will guide the project in adopting new technologies into the existing stack. That may mean a new framework or development approach, but it's generally an incremental type change. Also keep in mind that the list of potential candidates will be limited by existing language choice and code structure.

designing a class diagram

At the broadest level, this is done by the architect(s) and other team leads / lead developers. It's rare for a single individual to understand all of an application, so major design changes requiring a class diagram would be handled by a team.

Conversely, projects that are small enough that a single individual could understand all of the application generally don't have a dedicated architect. They usually have a lone developer (or two) that knows the product and makes changes as necessary.

organizing the different parts of a code and how they will interact between each other

Your criterion here implies that these things change all the time on an active project. They don't. An approach is laid out, the team sticks with it, and it only changes when sufficient pain causes the need for that change. Structural changes tend to be quite painful and expensive, so they're only done when absolutely necessary.

Even in the rare case of a green field project destined to be "something big", the design team (aka the architects and team leads) will lay out broad areas and start laying out contracts for interactions between the layers. If there's enough work to justify such structural definitions like this, then there needs to be a team that lays out how they are going to interact.

So with all of that explained, let's look at the pertinent quotes from Wikipedia and SEI.

---

From Wikipedia:

The role of software architect generally has certain common traits:
* Architect makes high-level design choices much more often than low-level choices. In addition, the architect may sometimes dictate technical standards, including coding standards, tools, or platforms.
* Software architects may also be engaged in the design of the architecture of the hardware environment, or may focus entirely on the design methodology of the code.
* Architects can use various software architectural models that specialize in communicating architecture.

From SEI:

Crafting the right architecture to solve the problem at hand is only part of architects' responsibilities. They must also
* define, document, and communicate it
* make sure the right modeling is being done, to know that qualities like performance are going to be met
* give input as needed to issues like tool and environment selection
* understand and plan for evolutionary paths
* plan for new technology insertion

---

One final thought -

Many of the primary roles of a Software Architect are a bit nebulous and the feedback cycle in identifying good decisions can get quite extended. There can be a lot of business risk without associated benefit in having dedicated architects who aren't developers. So pure Software Architects are kind of rare in the industry. It's really only the ultra-large projects that can afford to have dedicated architects who work in a team over the major areas of their project.

Many of the criteria you mentioned are handled by team leads and senior developers on most other projects. Often times that's simply because the decision is best made by someone who intimately knows the code that will be impacted. Some development methodologies (such as Agile) naturally preclude having a dedicated architect on the team. There are certainly exceptions to that statement, but Agile focuses on developers driving those decisions based upon business needs.

This blog / article goes into a few more specifics beyond what I touched upon. And SEI's definition of Architecture may be of interest.