We use cookies to ensure that we give you the best experience on our website. For more information please read our privacy policy by pressing the "More" button.

  • +40 728 840 309
  • +40 727 776 787
  • This email address is being protected from spambots. You need JavaScript enabled to view it.
Pragmatism in the Software World

Pragmatism in the Software World

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active
 

What is the place of pragmatism in the virtual world of software and technology? How can this concept, which deals almost exclusively in reality and results, in the “hardware” of life, be applied in the abstract domain of software? How can “pragmatic” be an attribute of any part of a domain such as software where it is acceptable to say that projects consistently run grossly over the originally estimated time and budget?

I believe we, as software engineers, have been misled into believing that since software is a field of engineering and since we attend engineering schools, then software development can be approached the same as any of the other branches of engineering. The big difference is that in most other branches, what we build is very real, constrained by the physical realities of our world, and feedback is almost immediate.

Software does not suffer those physical constraints because it lives in the digital world, not the real one, and as such feedback and results are almost a mirage, a construct of the mind, an issue of perception, not pragmatism. Like looking at an abstract painting on a wall.

In other words, software engineering requires the definition of a lot of rules to constrain and govern the digital world where it lives. To be pragmatic, software needs to be grounded. Most other products of engineering are naturally grounded because they are material. Software is not. It needs explicit grounding.

Grounding Software Products

The most natural way to ground software is to attach it to something physical – historically the hardware it runs on – to devices or “things” as we like to call them in the past years as our minds attempt to warn us of the gap between the “non-things” we build and the material world. This mindset is what I would summarize with Alan Kay’s words: “People who are really serious about software should make their own hardware.”

Still, imagine having a smartphone for each of the apps you regularly use instead of a single physical device that can run all of them. That does not scale. We need more ways of grounding software. This is where the discipline of Software Architecture comes into place.

Whichever definition of Software Architecture you prefer, the common denominator is that the outcome of designing your software product’s architecture is a set of constraints and rules to govern the project of building the software and the world it will be born and live into.

Whether it takes the shape of diagrams, documents, confluence articles, slide decks, drawings made in several meetings, is a matter of preference. What is critical is for the architecture of your software product to take a physical, explicit shape. Architecture is not a conversation; it is not code; it is not a technology; it is a set of laws defined for the new digital world you are about to create.

And for it to be any good grounding your software, it needs a real, material, explicit, ideally even physical form.

Want to Learn or Apply Software Architecture in Your Projects?

I’ve been developing and teaching what I believe are the only Software Architect hands-on learning programs in Romania for several years, teaching a variant of SEI’s Architecture Trade-off Analysis Method (ATAM), adapted and redesigned by me based on my practical software architecture and technical management consultancy experience.

It is not an off-the-shelf, one-size-fits-all training. It is more like a mentorship or apprenticeship. As such I have no links or slide decks to share. If you are interested in such a learning program for yourself or for the people in your organization, don’t hesitate to contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. and we’ll help you find the best way to train you in the ways of Pragmatic Software Architecture.

If you need some help starting off a new software project or need help evaluating, upgrading, or redesigning an existing product, please contact us. ProgSquad’s consultants can be your strategic partner for every step of the way, offering quality, trust and pragmatic results on all change management, product management or technical management capabilities required for your projects. Read more about ProgSquad Consultancy Services on our dedicated website.

Looking forward to the challenge of your unique journey!


 PS: This reminds me of one of the talks I did at Agile Tour Vilnius about Software Architecture as the Secret Sauce of Sustainable Agility. Check it out if you're interested in a little more perspective on Software Architecture in the context of Agile Development.