Notion of Repeatable processes

From the recent discussion on PragmaticProgrammer Mailing List:

(From Mail from Andrew Hunt)

Here's a side question for ya'll on the notion of repeatable process: I want a formula of how to make a hit movie. Perfectly repeatable, with no consideration of the talent involved. Just turn the crank and rely on the process to work.

Now replace the 'hit movie' with Software Product/Project. I never seen the concept explained with such a simple and thought provocating metaphor.

Craft Of Programming and Mentors

One thing I learned from my experiences in Software Development is 'Software Development' is not 'Computer Science'. Its not a science and its not fully an art also. Sometime back I read an article where the author called it 'Craft'. I really liked the idea. Indeed, programming is a craft and a Good Software Developer is like a Master Craftsman.

As Craftsman you learn the tricks of the trade by doing it many times, mostly under the watchful eye of Master. There are really few Craftsman so gifted that they can learn it on their own. It means early years of Software Developer are very important. Those early years define if you become a average developer, a good developer or a Great Developer. If you are working with a Master Programming Craftsman, you will learn much just by observing how he works. If the Master Programming Craftsman is also a Good Teacher and Mentor, Then You are Very Very Fortunate.

I am fortunate because my initial years were spent with Master Programmers like T.N. Umamaheshwaran, Abhay Tarnekar, Pravin Waghmare, KK George in MSDCAD, Telco. I learned a lot in 1 year at Telco. Afterwards, I learned from the books of other Masters like Brian W. Kernighan, Rob Pike, GoF, Robert Martin, Martin Fowler, Steve McConnell, Herb Sutter, James O. Coplien, and many others.

Here is a my list of Good Books from some these masters which shaped my ideas of software development.

1. C++ Gems series
2. Code Complete
3. The Practice of Programming
4. GoF Design Patterns Book
5. Advanced C++ Programming Styles and Idioms
6. Robert Martin's articles on Design Principles.

Trust your developers (employees) and treat them as Responsible Adults

This is the first lesson I learned when I become a Manager of a software development team. 'Treat your Developers as Responsible Adults and Trust Them'. This simple advice, gave a me big advantage namely Trust and Support of the Development Team. 

Sometimes big benefits start with a simple ideas. Let me give an example to clarify my point.

Scenerio : An Important release of your project/product is coming up and a developer comes to you and asks for a 2 day vacation (leave). What will you do ?

The most common reaction in companies/project groups is to DENY the request. Manager will ask the developer to postpone it or even go to extremes like accusing him of 'not being a team player'.

Saying 'no' is a REALLY BAD IDEA. Does your team know the importance of the release ? Do you trust the judgement of the team members ? Do you treat them as kids to be disciplined or as responsible adults ? If you are treatng them as responsible adults and if the developer knows the importance of release and still asking for vacation, then it must be that important for him. So Don't be a PHB AND say that 'YES, you can take the vacation'.

If my release is stopped because of unavailability of one developer, then actually I am a BAD MANAGER. In Software, people do change companies. So if only one guy knows some part of the project and if he leaves for some reason, I (the Manager) am in major trouble. Its my responsibility to ensure that doesnot happen. I should not pass the blame to the team.

Treating developers as 'responsible adults' has lot of side benefits. You become part of THE TEAM. Lot of times, its team versus Manager (you). Now its Team (you + developers+qa) versus the product/project/deadline/problem. Now you have much better chance of Winning.

You respect the team members for their abilities and they respect you for your abilities. The Team is much more confident to suggest unconventional and innovative solutions to problems at hand.

If I ask the team members to come on weekend (a rare ocurrance in my teams), the team comes in without any complaints. Most of the time I don't even have to ask. If they feel its neccessary work on weekend for some reason, they will come on their own.

The team depends on each other expertise, advice is freely sought and given, the team morale and hence productivity is high.

Its real WIN/WIN for everyone...