Science Pick
A collection of write-ups that speak for what's trending in science & technology.
Things aspiring Software Engineers should know - XI
As a Software Developer, I started my journey in the Software Industry at Novell from where I moved to Citrix and later to Amazon. Being in this industry for close to 6 years now, I have met and learnt from many wonderful intellectuals and have worked with them on various top class products that directly or indirectly impact billions of lives worldwide.
I have experienced diverse corporate cultures, working environments, software development practices and processes. During this journey where I accomplished some distinguished feats and also committed many silly mistakes, I have learnt lot of things of which I think some should be helpful and of interest to the aspiring Software Engineers. You may check out the points mentioned in the previous articles in this series. Here is another one-
Best method is subject to change
There is no single best methodology that suits all the situations. As mentioned above, I have worked in various environments, teams and cultures. Some process and practice may work in a certain scenario but not in other.
I have experienced diverse corporate cultures, working environments, software development practices and processes. During this journey where I accomplished some distinguished feats and also committed many silly mistakes, I have learnt lot of things of which I think some should be helpful and of interest to the aspiring Software Engineers. You may check out the points mentioned in the previous articles in this series. Here is another one-
Best method is subject to change
There is no single best methodology that suits all the situations. As mentioned above, I have worked in various environments, teams and cultures. Some process and practice may work in a certain scenario but not in other.
For example, I have worked on systems where we would use weeks to come up with best possible design and them start working on implementing it. Before releasing the software, we would make sure that it is almost bug-free and only pending things are enhancements that would be evaluated for and may go in next release.
I also have worked in scenarios where for whole process of designing, developing, testing and releasing needs to be completed in couple of weeks. We know that the software going out will contain bugs. We quickly learn which ones are important to be fixed and which ones can be lived with, fix the important ones and again make a release in couple of days.
Similarly, I also have worked on projects following practices like daily scrum as well as those where such methods were not followed. For one project, we decided to not have daily update meetings as they were not turning out to be dull and not quite helpful because in that project every day though you do a lot of work but not much of a different update would be there.
One really cant say which process is best. It depends a lot of factors like what kind of product is being created, kind of expectations that are set, kind of risks we are willing to take, what is preferred by team and so on.
My sincere suggestion is that many people waste a lot of time arguing and trying to figure out the best way, one-solution-that-works-for-all. Please don't do that as there is no universal best practice or process. Instead, figure out what works best in the scenario, helps you do your job in a better way and just follow that.
This is one of the things that I seriously think an aspiring Software Engineer should know. If you think some point should be added to this topic or some topic deserves to be added to this series, do post a comment and let me know. Keep watching for more. If you are keen on learning more about the better software development practices you can start following right from the college days, do get a copy of my first book "Hello World - Student to Software Professional" published by Partridge (A Penguin Random House Company). Now available worldwide on all the MAJOR ONLINE Stores - Amazon, Google Play, Flipkart, Barnes & Noble and many others.
I also have worked in scenarios where for whole process of designing, developing, testing and releasing needs to be completed in couple of weeks. We know that the software going out will contain bugs. We quickly learn which ones are important to be fixed and which ones can be lived with, fix the important ones and again make a release in couple of days.
Similarly, I also have worked on projects following practices like daily scrum as well as those where such methods were not followed. For one project, we decided to not have daily update meetings as they were not turning out to be dull and not quite helpful because in that project every day though you do a lot of work but not much of a different update would be there.
One really cant say which process is best. It depends a lot of factors like what kind of product is being created, kind of expectations that are set, kind of risks we are willing to take, what is preferred by team and so on.
My sincere suggestion is that many people waste a lot of time arguing and trying to figure out the best way, one-solution-that-works-for-all. Please don't do that as there is no universal best practice or process. Instead, figure out what works best in the scenario, helps you do your job in a better way and just follow that.
This is one of the things that I seriously think an aspiring Software Engineer should know. If you think some point should be added to this topic or some topic deserves to be added to this series, do post a comment and let me know. Keep watching for more. If you are keen on learning more about the better software development practices you can start following right from the college days, do get a copy of my first book "Hello World - Student to Software Professional" published by Partridge (A Penguin Random House Company). Now available worldwide on all the MAJOR ONLINE Stores - Amazon, Google Play, Flipkart, Barnes & Noble and many others.
Copyrights © 2024 Inspiration Unlimited eMagazine
Any facts, figures or references stated here are made by the author & don't reflect the endorsement of iU at all times unless otherwise drafted by official staff at iU. This article was first published here on 14th May 2014.
Wish to simply drop a comment / share an inspiring story / chat with us:
