XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Software development – A trekker’s way

I have been trekking for almost the same time as developing software. I have, always been surprised with the similarity I find in these two diverse activities. I have successfully used examples from trekking to explain some process or approach in software development.

The objective of this article is to bring out a few things I have learnt from trekking, which helped me in software development. Right now, I just plan to mention the points here. I would be providing supporting evidence a bit later.

  • Travel light
  • Full upfront planning/design does not work. Take it as it comes
  • Waterfall model does not suit rapid application development. You do more than one thing at a time
  • Highly motivated, self disciplined and self organized team works. Let team members take up roles and rotate them amongst themselves.
  • Communication is the key to success. Keep talking
  • Team composition – mix of experience levels and skill sets works best
  • Diversity is fun and a great learning opportunity 
  • No silver bullet – Every team has customized the process to their requirements rather than customizing the team to the process requirements
  • Most of the time you have shortage of good resources (people, machines, tools, time, etc). Make the best of what you have
  • Early glimpse of desired results helps keeping things on track. Short releases and demos help
  • Feedback is critical to improve. Listen to the code, client, peers, etc
  • As the team size grows the project gets exponentially complex and difficult to co-ordinate
  • Change is inevitable. Being prepared for change by keeping things flexible helps. Early change can save a lot of money and efforts
  • Be ready to throw away and start all over again
  • You cannot freeze on the requirements early, only once the client sees something working, that‘s when they can actually give you the complete requirements
  • The whole team takes decisions and not just the leader. In cases of discrepancies, the leader helps the team to resolve it, rather than taking her own decision
  • Clean up the path from harmful things as you trek. This helps to keep the nature clean, beautiful and maintainable for many years. Refactoring the plans, design, code and test-cases helps keeping things intact.
  • Trust the team. Encourage open and frank communication
  • Sustainable pace – Don‘t burn out. Take frequent breaks
  • Optimistic attitude helps
  • Keep the whole team on the same page
  • Team members should be ready to do different things. Ego has no place. We like specialists who can do other things and also help others learn what they know by pairing and sharing
  • Use quality stuff. Never compromise on quality. Both what you deliver and what you receive. Good chairs, desks, computers, food, etc
  • Start small – Big bang theory does not suit us
  • Practice simplicity. Do the simplest thing first. Also known as KISS – Keep It Simple and Stupid
  • It‘s not just the destination, it‘s the journey too.
  • Live and let live attitude helps. Healthy competition and wiliness to take others along by sharing and seeking helps
  • Retrospectives helps improve constantly
  • Constantly try and improve and optimize things. Try to automate as much as possible
  • Never loose sight of your objectives. Don‘t slip deliverables. Maintain client focus
  • Precaution is better than cure. Have proper safety nets. Be sure before you put your foot down and be extra sure before you lift the other foot.
  • There is always a first time. Don‘t be afraid of failures. It‘s a great learning opportunity
  • Fear and negative energy spread very fast in the team. Do everything possible to keep a check on it
  • We hate wastage. Try to optimize usage of resources
  • It‘s 99% common sense and 1% fluke.
  • If someone thinks very differently and cannot adjust to the team, it‘s better to ask the person to leave. Helps both the sides
  • United we stand and divided we fall. It‘s all or none. It‘s team and not individuals
  • Its people and not the process that makes things happen. Process can only act like the lubricating oil in the engine. Your chances of hitting the bull‘s eye is much higher with smart people than trying to get the best out of average people
  • Abstraction helps to keep it simple. Details can be added when needed.
  • Coaching philosophy does not really work, if the coach cannot play and demonstrate, you are rolling down the wrong path
  • Change is inevitable, be ready to adapt rather than fighting against change.
  • Work with people‘s instincts. When a team member feels that something isn‘t going to work or is inconsistent or it doesn‘t smell right, then there is a good chance that is the case. As you gain experience, your instincts become sharper
  • Software development is a craft and software cannot be engineered. Every disciple involves elements of art and science.
  • Try and be as explicit as possible. Implicit rules trend to be misinterpreted and sometimes misused. Collaboratively develop a list of DO‘s and DON‘T DO‘s. Constantly refactor it and make it part of the company‘s culture.
  

View more Presentations from Naresh Jain.

    Licensed under
Creative Commons License