Hello techxperts, mind your choice

This post is about an important aspect which ‘techxperts‘ – the ‘technology experts’, or  ‘Architects’ do sometimes purposefully, but without the intention to harm anyone. I am also an architect, so yes – I did not mean any sarcasm here.

To survive in any industry, in this ever evolving, globalized world, it is important we make sure we are always up-to-date in our field of job. Thankfully, with the help of Internet, especially through social media we get information about any amendment or introduction of a tool or technology within a matter of seconds, from the vendor, neighbourhood watch portals or friends’ tweets.

  • Some experts Read, then blabber
  • Some experts Read and Experiment, then Suggest
  • Some experts Read, Experiment and Analyze, then Guide

I usually get design review requests and it is always shocking for me when developers say the reason for a particular decision to follow an approach or use technology. Let me give you a sample conversation:

Developer: “Mr. ABC asked me to use it… and when I Googled and found this is a best fit”
Me: “Sure I agree, but the library is still in “preview” mode.”
Developer: “hmm… so what? that is from Microsoft! and Mr. ABC is a senior, he cannot be wrong”
Me: {explaining the drawbacks of ‘preview’…}

Considering this scenario, let me list some important points on decision making in a software development scenario:

Do not ever play with a customer’s project

Some people love to apply what they learned somewhere so that they can can tell the world that “I am an expert” and the tool is an addition to the resume. The proverb “A little knowledge is a dangerous thing” here. You can read about the same in book O’Relly’s 97 Things Every Software Architect Should Know1st point by Nitin Borwankar.

Beware of anti-patterns

“An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences.” You might find your decision fit perfectly at first look, but in reality it may be good only for a short term or limited scope. Think from a long term and broad perspective. You might leave the project one day, but don’t let the next person suffer because of your expert design. Example, you might find SQL Sever an easy approach to handle a data analysis problem which will be efficient for couple of Giga Bytes of data which is the current availability. But some Peta Bytes tsunami of data flow might be flowing into the system after some months or years then your architecture breaks in production.  That time you might be working for some other company while your previous company who spent for your daily bread might be suffering.

Use only stable versions of libraries and technologies

A big NO for unstable versions like Alpha, Beta and CTP. These versions might contain bugs, and features that might change or get removed when a stable version is out. These versions usually comes with no support and vendor wont take any responsibility of your loses.

Beware of Open Source

Do more research in the case of open source technologies and tools. There are properly maintained open source projects, as well as poor ones. Do a thorough study whether the project is backed by a strong development and support team. Read their EULA – most Open Source licenses comes with special clauses for use with commercial applications.

Understand requirements

I have seen some architects give instant pain relievers on-the-spot up on hearing the limited scope context on-the-spot. There will be much better solutions you can suggest if you go in detail in requirements. Recently, there was a requirement for one project team to schedule jobs in Azure. One person up on hearing the words – “Azure” and “job” suggested to go with WebJobs (an Azure feature). But in reality, the project uses a DataFactory (another Azure feature) which already includes a facility to schedule jobs. May be this person could have suggested the same if he was patient enough to hear one more word “DataFactory”.

Thank you for reading.


Application Orchestration

Application or service orchestration is the process of integrating two or more applications and/or services together to automate a process, or synchronize data in real-time. Often, point-to-point integration may be used as the path of least resistance. However, point-to-point integration always leads to a complex tangle of application dependencies (often referred to as “spaghetti code”) that is very hard to manage, monitor and maintain. Application orchestration provides a) an approach to integration that decouples applications from each other, b) capabilities for message routing, security, transformation and reliability, and c) most importantly, a way to manage and monitor your integrations centrally.

More reading here: https://www.mulesoft.org/what-application-orchestration


Explain Design/Anti pattern to a Grandma

I usually take the example of Paracitamol when I have to explain the Software Development philosophy – What is Design Pattern and Anti Pattern? – to the audience who are relatively new to the field.

Praveen: When you get fever, what is the first thing you do?

Audience: Paracitamol

Praveen: Yes, we usually consume “Paracitamol tabs” when you get fever or headache. This is a design pattern because we do this regularly which is a pattern.

Praveen: Now, after a long time, due to over consumption of Paracitamol, what will you get?

Audience: hmm… Liver damage?

Praveen: Exactly! So, now that design pattern became an “Anti Pattern”


Architect and mentality towards continuous learning

One of the great quality an architect should have, in my opinion is the habit of keeping updated with latest tools, techniques, technologies and methodologies.

But how do you learn them? Definitely it should not be through applying it on some one else’s bread and butter. i.e, you should not experiment with your customer project. You must find time to experiment and try PoC (proof of concept) at your own expense and once you feel fully comfortable then you can apply it to the real world projects. Customers are paying for what they requested for and not to improve your knowledge. If your new experiment adds value for the project then it will make the customer happy for sure.

It is important to fill an Architect’s resume with fancy buzz words to survive in the corporate battlefield. Gathering more knowledge is a challenging job and if one is able to achieve, it will obviously add feathers to the crown. Putting effort for learning new things will be always appreciated but one should give importance to branding and visibility as well. Publishing whitepapers, blogs, articles etc. are few methods for improving visiblity.

Ref: Don’t put your resume ahead of the requirements


Design guideline: Law of Demeter

It says:

  1. Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
  2. Each unit should only talk to its friends; don’t talk to strangers.
  3. Only talk to your immediate friends.

More reading here.