Wednesday 13 November 2013

What Software Developers can learn from Sachin Tendulkar's marathon career?

A great career is about to end.  One filled with many many runs that even the best can only dream of.  Yes, we are talking about the one and only Sachin Tendulkar.  As he is retiring, I just thought of how much I learned by just watching him.  That's when I realized why not pass that learning to others as well or at least highlight what we can learn from him. 
 
This post is specifically dedicated to software developers.  But this can be applied for anyone in any field.
 
So what are the things that software developers can learn from this great guy?  Here we go with the list.
 
 
 
 
Passion for the game


One thing that is pretty to hard to beat this guy at a young age or even now is his passion for the game of cricket.  He used to bat, bat and bat without getting tired at the nets day in and day out.  He loved the game so much that he lived it. 

Similarly developers should be passionate about developing great software.  It is the passion that keeps a man going and work never looks like work if you are passionate about it.

 

Natural Talent

Tuesday 5 November 2013

14 Code Refactoring smells you can easily sense and What you can do about it?

This post is specifically intended to Project Managers although developers and testers can also get reasonable inputs from this post.  Generally projects tend to accumulate a lot of technical debt over time if refactoring is not applied and if good coding practices are not followed.  It is imperative that as a Project Manager you should understand this and deal with it effectively.  This is especially true in an Agile Project, where there is constant delivery of features and you would be surprised how quickly code quality can take a beating in if proper measures are not taken.  So what are the signs you can observe that your project’s code needs refactoring and what you can do about it?

·         Team is taking more time than expected to deliver features
o    This is probably the number one smell that a Project Manager can look out for in a project.  As a Project Manager you sense that a certain feature should not take so much time, yet it takes that time.  You talk to the team and they often give you a detailed explanation of how much change the feature needs to undergo and how it affects other features.  That is one of the sure smell that indicates that the code needs refactoring
·         Plenty of bug fixes after delivery
o    On one end, the code delivery is being delayed and at another end, there will be a lot of bugs too after delivery.  If you have observed this, then it is a sure sign that your project’s code needs refactoring.
·         Build Quality is on a decreasing trend
o    This is one of the excellent smells that surely indicate the need for refactoring.  If we try to build on bad code, the code quality will get reduced and this trend continues till we attempt to put a stop to it.  If you observe this as a Project Manager, then you need to put a stop to it.

Tuesday 29 October 2013

Common excuses a Developer makes when a feature doesn't work [And how to avoid them in the future]

I always feel that Developers should have an attitude for development, which I have detailed in the blog post Attitudes of a Great Software Developer.  But generally when it comes to issues, a lot of developers make excuses.  As long they are genuine, it is not a matter of concern however if it is really an Excuse, then it is a cause for concern for the entire team.  I am guilty of a few of those myself however when I saw the big picture, I rectified those and understood why people make those excuses and how we can avoid them in the future.  I am detailing a few in my below post.


1.  It works fine in my machine

Come on guys, this is the number one excuse that developers give.  We often have a feeling that testers or the customers have a magical computer which injects bugs into our code.  But that is far from true.

The only way to avoid this excuse is to be aware of the environments that are used for development, testing and production.  By being aware of those, the first thing you would probably ask is, what sort of configuration/environment it is and get more details about the issue and check if it is really a valid bug.  Another way to avoid this is to have a Continuous Integration environment, where with each and every code check-in, code is compiled and deployed in some test machines.
Image courtesy: cheatcc.com

Tuesday 15 October 2013

How to improve agility of an Agile Team

Often as an Agile Project Manager or an Agile Scrum Master, your very first challenge is to improve the agility of teams.  Before we try to go to the core topic, we will try to define what is Agility?

Wikipedia defines Agility as
"Agility or nimbleness is the ability to change the body's position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, and endurance"
From the definition, it is quite clear that Agility is a function of lot of factors such as Balance, Coordination, Speed, Reflexes, Strength and Endurance.

So in this article, I will try to post my thoughts on how to improve Agility of a Team in my own words of course and out of my experience.
 
 
1.  Change their mindset
Agile is a lot about mindset.  Once someone is into that mindset, obviously he/she will contribute the best to the team's cause and thereby it will increase the speed and also the agility of the team.
 
2.  Change your mindset
Acknowledge the fact that you need a mental conditioning as much as the team.  First of all, try to understand what Agile is all about and how it benefits the different stakeholders in the teams.  Try to understand that Agile is not a miracle game and it takes time, proper execution, support from every team member and support from team as a whole to reap its benefits.
 
 
3.  Improve collaboration
Agile is lot about team working together to complete challenging tasks rather than several team members working in silos.  Emphasize the fact that Agile is a team game.  So Improve the collaboration among the team members, ask them to pair up for some problems and encourage good collaborative team work and make collaboration a habit.

Friday 11 October 2013

Free E-Book - Programmer's Motivation for Beginners

Hello everyone

I am proud to present my first E-Book which I have compiled based on my experience in the Software industry.  This book contains valuable piece of information and learning that will be very useful to those who are starting out their careers and also some intermediates.  This is a very short E-Book (40 pages) and spans across these following chapters.

Chapter 1 – What I learnt from my first real working code
Chapter 2 - How to learn programming
Chapter 3 – Thoughtful quotes for  programmers

Sunday 15 September 2013

Test Like a Villain!!

Welcome to AgileDevTest.  In this post, I am trying to project a Villain's mindset and how it resonates with a Tester's mindset, of course in my own point of view.




Do you have any other points of view? Please let me know.  Comments and critiques welcome!

About the Author

Rajaraman Raghuraman has 8 years of experience in the Information Technology industry focusing on Product Development, R&D, Test Data Management and Automation Testing.  He has architected a TDM product from scratch and currently leads the TDM Product Development team in an IT MNC.  He is passionate about Agile Methodologies and is a huge fan of Product Development, Agile Development and Agile Testing.  He blogs at Test Data Management Blog & Agile Blog.  Connect with him on Google+

Thursday 1 August 2013

Agile is not for you IF

In my previous posts I have tried to put forward my points on What an Agile Project needs for success, 11 areas an Agile Project Manager needs to focus o... and Scrum meeting. Are you kidding me?

In this post I am going to describe in my own words and experiences that Agile is not for you if you are among the following category.

1.  If you are not willing to change your mindset and continue to work the same way, you did before
2.  If as a manager, you think people are resources
3.  If as a developer, you think your job is just to code by specifications
4.  If your organization is run by bureaucrats
5.  If your team is not mature enough to handle changes frequently
6.  If you want to deliver something fixed within a fixed time frame
7.  If you can't have customer or Product Owner inputs on a regular basis
8.  If you have fairly straightforward requirements