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.


Join SMstudy and Earn free PDUs

Got this from a mail and found useful. Hope this will be useful for you too.

Join SMstudy and Earn 20 SCRUMstudy RCUs,
20 PMI PDUs for free

SMstudy, a brand of VMEdu, is the global accreditation body for Sales and Marketing certifications. SMstudy Free Associate Level Certification courses are approved by SCRUMstudy to offer RCUs and by PMI for PDUs.

If you haven’t already, what should you do to get a free certification in Sales and Marketing, earn 20 free SCRUMstudy RCUs, and 20 PMI PDUs? It’s easy – just follow the two easy steps mentioned below.

Step 1: Join the SMstudy LinkedIn Group to engage in discussions about Sales & Marketing.

As a member of SMstudy’s LinkedIn group you can refer to articles, news, updates; and participate in exciting discussions in world of Sales & Marketing.

Step 2: Get the Free Associate Level Certifications in Marketing Strategy and Digital Marketing from SMstudy.com.
  • Understand the fundamentals of Marketing Strategy and Digital Marketing
  • Complete within 10 hours of study
  • Get Free Certification Credential that will look great on your resume and LinkedIn profile
  • Earn 10 SCRUMstudy RCUs and 10 PMI PDUs on completing each of the Marketing Strategy and Digital Marketing Free Associate Level certifications.

Difference between a Manager and a Leader

Have you noticed the managers or leaders who you admire are mostly at the top of the ladder and their promotions are faster than others? Well, I have witnessed many.

Around 13 years back, I joined a company in Trivandrum Technopark and after three months I was struck with a database problem. Someone called me on the phone and I still feel bad that I told him “I am a bit busy with another module so let us talk later”. Next day he called me again in the Morning in the same time, around 11:00 AM and we had discussed about the issue and I got the solution in five minutes which I was struggling for 2-3 days. It took more than one month for me to realize it was the CEO of the company and he was in United States an official trip. He did not show his power that time even though it was his company and I was yet to cross the probation period.

My first ever manager was like a friend, who is again a CEO and Director of the company and I reported directly to him because it was a small company of approx. 15 employees. From US, everyday he used to ping me on Yahoo Messenger and say “Good Morning Praveen, whats up?”. Whenever he comes to the office on vacation, we used to sit and used to talk about websites, UI design etc. I was recruited as a “System Administrator” but with his encouragement and freedom, I was able to learn more about technology and was able to get a title of “Software Developer” and redesigned company’s logo and website, that too with private secure file-transfer facilities since the company’s main revenue stream was medical transcription. I have developed a voice player also that time and I was very glad to see all the transcriptionists quickly changed their ordinary voice player with my innovation 🙂

My second manager, again a CEO of a small incubator company in Technopark , used to force me to read “IBM Red Books” which helped me to start the habit of reading and writing. I still remember his words in a team meeting – “If you don’t work and still get paid, I don’t mind because I will get that money from some other sources even without me knowing. But what you are doing will be an injustice to yourself”.

Ok, now… what made me write this blog now? A recent incident…

One Manager: You should come now! I have another meeting so you take a break from your meeting and meet me.

Another Manager: Before you leave, please come to my room. I have something to talk. I can come to first floor.

And this second manager happened to be superior to the first manager. I think I should do a case study why managers/leaders on top of the ladder are always humble, consider others as humans, respect others, do not use strong words, do not hurt with words or actions, guide and mentor, giving not only feedback but also suggestions to overcome etc.


Project Management and split personality


A Project Manager must possess “multiple personality” especially when coming to the requirements. He should jump into the shoes of all the stakeholders and domain to get the correct picture of “what customer want”. Sometimes customer may not be knowing the exact requirements so project manager or a BA (business analyst)’s help is required to build the initial requirements.

The workers, say Developer of an IT company may be too technical and miss many points of the business cases. But to find out what all things he might have missed, PM should be able to think from his side too.

When thinking about issues outside the job, PM must understand the feelings of the team. If the requirement is not clear, employees will not be able to execute the job correctly and at the end it will be just guess work. Don’t assume everybody understand the requirements even if it is a very simple one. Sit with them and discuss all the issues including their out-of-work stuff. Discussing out-of-work matters will give them confidence that you are supporting them in all the aspects. Communication with stakeholders is very important even if it is a Yes or No subject.

Project Manager is the glue to co-ordinate all the stakeholders in single virtual place. Business communications must be transparent to avoid end-of-day surprises. PM should turn to a BA, Solution Architect, Client Tester, Worker and all the available forms of stakeholder throughout the life of a project for the accuracy of the product or service result.



Some strange rude problem-solving tips

  1. Your experience might tell you not to go with a challenge but listen to new ideas. Others also got experience
  2. Sometimes brain weights more than experience. Give them a chance
  3. Don’t say ‘NO’ straight away. People are different. Some people might explain why it is a ‘YES’ but some people will go silent, thinking ‘don’t argue with a fool’
  4. Nothing is impossible. Brainstorm! you will get plenty of solutions in paper
  5. Look and smile to opponents after any idea-fight. You need them till you resign. Don’t expect them to give you back a smile
  6. Know to whom you are talking to
  7. Silence can bring miracles, but know when to be silent and when to make sound
  8. Defend with positive statements against negative ones but not vice versa
  9. Analyze, analyze, analyze and analyze before projecting a solution. Even your third analysis can be wrong.
  10. Always produce proof/evidence to support. Quantifying will reduce 60% of talks
  11. Pictures and prototypes can talk
  12. Let mirror and a recorder be your draft audience for complex problems. If yourself do not understand the solution, nobody will

Six Sigma at a glance

  • Six Sigma – A systematic methodology for quality management
  • TQM & ISO 9000 are other similar quality management methodologies
  • It uses various theories and tools for process improvement
  • Improves process and tries to reduce time, cost, resource etc.
  • Denoted by , where σ is a Greek symbol
  • Six-Sigma represents the statistical term standard-deviation
  • Standard Deviation is the deviations from average
  • Standard Deviation = unit of measurement of deviation 
  • More deviation from average/mean means more defects
  • A business/product which follows 6σ will have only 3.4 DPMO
  • DPMO = Defects Per Million Opportunities
  • Success rate of Six Sigma is 99.99966%
  • Three key holders of quality = Customer, Employee and Process
  • Six Sigma is not about quick-fix
  • 6σ was first implemented by Motorola Corporation in 1980
  • Traditional 6σ certification levels are:
    • Yellow Belt
    • Green Belt
    • Black Belt
    • Master Black Belt and
    • Champion
  • DMAIC model
    • Define
    • Measure
    • Analyze
    • Improve
    • Control
  • PDCA
    • Plan
    • Do
    • Check
    • Act
    • Define
    • Measure
    • Analyze
    • Design
    • Verify
  • DFSS = DMADV, also known as Design For Six Sigma