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.