Tradition Vs Innovation - Story of an Ancient War
Here you may find a person trying to convince others that one should stick with the legacies: experience, practices, and legacy patterns, while the other person contradicting as If only innovation and creativity makes a difference.
Or in other words, you learn as you go.
The same quarrel exists in our software engineering field, at least in our local industry as I see.
The Fundamentalist Craftsmen or Blind Followers There are people who have strong belief in old practices.
They always have the same number of documents, same life-cycle, identical design, and unbelievably a single strategy for every project.
The most surprising point for me is that even the failure is unable to make them believe that there's something wrong.
Instead of trying to make some improvements and searching for the shortcoming in their practices and strategy, they start believing that failure is a norm, or it's not failure at all.
For instance, you'll hear them saying "Clients never get satisfied" or "Losing deadlines is a norm in our industry".
Examples -make things easier In a software project, the offshore back-office development team shares the documents reside in their local repository with the the on-site front-office team to let them update the documents.
In absence of their access on offline documents the local team shares the documents via email with the remote team.
Obviously they get frequent version conflicts in documents and when it happens, they arrange a meeting and manually resolve the conflicts in the documents.
For months, they suffer with this problem but avoid change in their practice e.
having an online document repository instead of shareing the documents on email.
The term coined here is Brute Force approach as Steve McConnell called it 2.
The Innovator - or scientist, we can say Away from the above category, the innovators are what most of our new graduates comprise of.
They start with buzzwords like Web 2.
0, cloud computing and believe that legacy practices are obsolete and that the senior folks are not creative at all.
They drive their projects for learning, ignoring the ground realities they neglect the cost and risk of change and avoid exploiting legacies: patterns and practices.
Since they believe that they make things better than they are, it's possible if you see them writing their own DB connection pooling in technologies having built-in connection pooling or writing their own classes from scratch instead of extending the existing one.
They often try to make simple things state-of-the-art and having insufficient knowledge and experience they get lost in the middle.
The term coined here is "Silver Bullet" as Steve McConnell says.
Engineering Mindset: the most needful The moderate mindset - or engineering mindset as I say- tends to utilize and exploit the experience, invested by the lots of great minds avoiding useless reinventions but never shy to address the issues with in the particular scenario, if it doesn't fit with.
The mindset says that understand your objective whether it's build-to-learn or learn-to-build.
It says that to be honest and successful, an engineer shouldn't behave like a scientist who build and destroy just for learning.
And it says that there's always room for improvement since it's a going concern but it's not the ultimate goal of an engineer instead it's to deliver the most optimal and economical.
A single practice may have various out comes when followed with or without reason.
So, if a practice is being followed by majority, most probably there are reasons, try to find them, don't shy asking other followers if you couldn't, but if nobody else knows, you have at least one reason to avoid it.
Better to have your own with reasons instead of following blindly.
Being an engineer, I do not believe that I am right all the way, considering that I've limited amount of skills, knowledge, experience.
Your comments and disagreements will be anticipated hoping they'll help us having a balanced mindset.