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.

1. Travel light
2. Full upfront planning/design does not work. Take it as it comes
3. Waterfall model does not suit rapid application development. You do more than one thing at a time
4. Highly motivated, self disciplined and self organized team works. Let team members take up roles and rotate them amongst themselves.
5. Communication is the key to success. Keep talking
6. Team composition – mix of experience levels and skill sets works best
7. No silver bullet – Every team has customized the process to their requirements rather than customizing the team to the process requirements
8. Most of the time you have shortage of good resources. Make the best of what you have
9. Early glimpse of desired results helps keeping things on track. Short releases and demos help
10. Feedback is critical to improve. Listen to the code, client, peers, etc
11. As the team size grows the project gets exponentially complex and difficult to co-ordinate
12. Change is inevitable. Being prepared for change by keeping things flexible helps. Early change can save a lot of money and efforts
13. Be ready to throw away and start all over again
14. 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
15. 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 his or her own decision
16. 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.
17. Trust the team. Encourage open and frank communication
18. Sustainable pace – Don‘t burn out. Take frequent breaks
19. Optimistic attitude helps
20. Keep the whole team on the same page
21. People on the team 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
22. Use quality stuff. Never compromised on quality. Both what you deliver and what you receive. Good chairs, desks, computers, food, etc
23. Start small – Big bang theory does not suit us
24. Practice simplicity. Do the simplest thing first. Also known as KISS - Keep It Simple and Stupid
25. It‘s not just the destination, it‘s the journey too.
26. Live and let live attitude helps. Healthy competition and wiliness to take others along by sharing and seeking helps
27. Retrospectives helps improve constantly
28. Constantly try and improve and optimize things. Try to automate as much as possible
29. Never loose sight of your objectives. Don‘t slip deliverables. Maintain client focus
30. 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.
31. There is always a first time. Don‘t be afraid of failures. It‘s a great learning opportunity
32. Fear and negative energy spread very fast in the team. Do everything possible to keep a check on it
33. We hate wastage. Try to optimize usage of resources
34. It‘s 99% common sense and 1% fluke.
35. If someone things very differently and cannot adjust to the team, it‘s better to ask the person to leave. Helps both the sides
36. United we stand and divided we fall. It‘s all or none. It‘s team and not individuals
37. 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
38. Abstraction helps to keep it simple. Details can be added when needed.
39. Coach philosophy does not really work. If the coach cannot play and demonstrate, you are rolling down the wrong path
40. Change is inevitable, be ready to adapt rather than fighting against change.
41. 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, that is the case. As you gain experience, your instincts become sharper
42. Software development is a craft and software cannot be engineered. Every disciple involves elements of art and science. The science element is missing from software development.
43. 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.

Trekking and software development
1. Planning: No clear roadmap. We just have a high level plan or map. Too upfront design or planning might not work.
2. Travel light: Cannot carry the burden of unwanted or not so important things. We can always get them or create them when we need
3. Adding more people to a late project will only delay the project future. Bigger the team, more complex the project gets. Co-ordination gets exponentially difficult.
4. It‘s not just the destination, it‘s the journey too.
5. Continuous feedback is critical. It‘s not holding the steering in one direction, it‘s about making a lot of small adjustments to stay on the path
6. No two software projects are same, as in the case of treks. Infact, keeping the team and project the same, the second time is always different from the first one. Same holds good for trekking.
7. Team work: It‘s about communication and coordination. One cannot miss a module and continue; similarly one cannot leave a member of the trekking group behind and continue the trek. Everyone on the trek needs to be on the same page.
8. Each team customizes the processes keeping the values or principles as the guiding lighting
9. There is no ultimate way of developing software or trekking. There is always scope for improvement and new ways of doing things. Also, there are many possible ways or paths to reach the destination. At the beginning one might not be able to clearly say which the best path is.
10. It‘s all about making the best of what you have on hand. In software development you don‘t have a great control over the budget, time, people skills, etc. Similarly while trekking you have limited resources and one has to carefully utilize these resources
11. It‘s all about finding your way through an unknown territory, while you just have an overall sense of direction.
12. One cannot rely 100% on measurements and matrices. A lot of things cannot be measured and few other measurements don‘t seem to make any sense at times. It is difficult to gauge where in a software development process you stand. Similarly one cannot be sure where they stand in terms of reaching the destination
13. One cannot carry the burden of ego. People should be ready to do anything that takes to make desired things happen
14. Highly motivated and self disciplined people are the need of the hour
15. Team composition is the key to success. One needs a good mix of people with varying skill sets and experience levels.
16. There is some sense of satisfaction when one gets lost and gets back. There is a feeling of immense learning and exposure on getting lost.
17. You don‘t need to know everything that takes to finish the project or the trek right before you stat. A lot of things can be found-out/learnt on the way and a lot of things become self-explanatory once you get there. There is always someone who would be able to help if required.
18. You don‘t have a clear separation between planning, requirement gathering, designing, development, testing, etc stages. You are doing a mix of these all the time. Similarly, you don‘t have a clear separation between planning, climbing up, climbing down, eating, decision making, etc. You are doing a combination of them.
19. A lot of satisfaction is derived out of exploring the unknown as a team, rather than having a guide or mentor dragging you along.
20. Practice simplicity. In software development you try to get the simplest thing working first. Similarly, in trekking, you try to take the simplest route to begin with. Once you get a hang of the terrain and some confidence, you might choose to try more complicated and difficult route.

Watch out for a white paper on “Software development – The trekker‘s way” soon…