Menu
Software Architect
HOME Contact Robert Zaremba blog

Programming stuff

emacs cheatsheet vim cheatsheet Scala programming manual Go programming patterns

Contract Bridge

Intro & conventions Precision system Precision - Meckwell Lite

IT leadership

Agile rules Agile Workflow Dev Workflow Personal Development Software Architect

Software Architect

Software Architect job covers many aspect of the software engineering life cycle as well as solution design and business analysis. Here I want to cover aspects of this job.

Like in every responsible job, training self reflection and managerial reflection is a key to growth the efficiency of personal work the team work around you. With that in mind, I would like to start with listing the key habits / wisdom which help to be more efficient (in all aspects of life): In my blog post: Essential values for Personal Development I write more about Personal Development activities that improve awareness, skills and develop potential.

Business - Engineering responsibilities

Social aspects

Deliver-ability.

Here we want to ensure that we have right research and development balance with right. The key principle here is the Lean Startup action loop:

Build faster → Measure faster → Learn Faster

Engineering aspects

SOLID principles

Single responsibility
one component should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the component.
Open–closed
Software entities ... should be open for extension, but closed for modification. Don't break interfaces (keep them closed). You can extend them or change components implementing them.
Liskov substitution
Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Interface segregation
Many client-specific interfaces are better than one general-purpose interface.
Dependency inversion
Depend upon abstractions, not concretions.

Cohesion

Cohesion refers to the degree to which the elements inside a module belong together. It is a measure of the strength of relationship between the class's methods and data themselves.

Modules with high cohesion tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.

High cohesion often correlates with loose coupling, and vice versa.

Are all this principles important?

Let's have a look.

If you don't keep SOLID principles:

If you don't synergize and don't kill your ego: