tag:blogger.com,1999:blog-17002261.post115941717581478234..comments2008-09-05T19:46:43.192+05:30Comments on I think ... (Tarun Chandel's thoughts): Too much of installation, too less of code!!Tarun Chandelhttp://www.blogger.com/profile/01025188840354820953noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-17002261.post-1165991673105024072006-12-13T12:04:00.000+05:302006-12-13T12:04:00.000+05:302006-12-13T12:04:00.000+05:30"Whereas I see automating installations as a probl...<I>"Whereas I see automating installations as a problem to solve and hence to get motivated, you see it as precondition for people to get motivated."</I><BR/><BR/>No i don't see it as a precondition to get motivated. When does a team get together? A team gets together when there is a problem to solve or a mission to achieve, in Software Development case, when there is a delivery to make. They already have a challenge to take care of. Team's most of energy should be spent on trying to solve the primary problem for which they got together. The primary problem is a good enough to get motivated, but if the team faces problem at every step and keep solving them they will spent that less time on solving the primary problem.<BR/>Processes never make a good team. <B>Alistair Cockburn</B> in his book <B>Crystal Clear</B> mentioned that while researching about which team failed or delivered projects successfully. And he found no correlation between processes being followed with project’s success. According to him a team of adequate people with just enough knowledge can deliver highly complex projects successfully without following much or any process. He also coined a small phrase that, <B><I>“people trump processes”</I></B>. Which is true, if you have a team which can work together rising above pity differences you don’t need all the processes. <BR/><B>Jim Collins</B> in his book, <B>Good to Great</B> mentioned that put right people on the bus and they will decide where to take the bus. In simple words they will make sure that they achieve the goal for which they are on board. Let’s take a scenario, if the team is ready to board the bus and they realize that the bus is not yet arranged. The team will arrange a bus themselves, they are more than capable to do that, they will test the driver’s skill level and whether the bus will be able to last the journey. They will do all these tasks and then the journey will start. If they would have got a good bus with everything done to start with, they would have already been solving the problem on board. Let’s draw this analogy to the original discussion we were having, it’s up to management whether they want the team to install softwares or directly start working on the problem for which the team is there.<BR/>Teams in Software industry does all the installations themselves as a process. It's time to address whether this process is worth following or can a team has it as a prerequisite to the project? Every problem is a challenge and challenges do motivate people ... <BR/>(I will leave it open here)Tarun Chandelhttp://www.blogger.com/profile/01025188840354820953noreply@blogger.comtag:blogger.com,1999:blog-17002261.post-1165829348169947332006-12-11T14:59:00.000+05:302006-12-11T14:59:00.000+05:302006-12-11T14:59:00.000+05:30Whereas I see automating installations as a proble...Whereas I see automating installations as a problem to solve and hence to get motivated, you see it as precondition for people to get motivated. I would say challenges and problems get people motivated and challenges never occur in ideal situations. They occur because things are not ideal and can be improved. Good teams dont need processes (as they create themselves) and bad team can not do anything with best of processes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17002261.post-1165320719220253652006-12-05T17:41:00.000+05:302006-12-05T17:41:00.000+05:302006-12-05T17:41:00.000+05:30I think automating the process of installation is ...I think automating the process of installation is a good solution. But I am not just talking about the solution; I am talking about the process here. <BR/>If the team is provided with a ready script at the time of start of project, their enthusiasm will not fade away. Alistair Cockburn once said that a team of motivated people can deliver any project. The real challenge in any project is people management. <BR/>Let's discuss what is motivation? Rather what is the final result of motivation? The final result of motivation is an enthusiastic person ready to put his/her time and energy towards achieving your goal. So if at the start of the project everyone gets a script that will automate the process of installation, no one will lose their enthusiasm. <BR/>An enthusiastic team ready to crack the problem; that's a good situation to start a project with.Tarun Chandelhttp://www.blogger.com/profile/01025188840354820953noreply@blogger.comtag:blogger.com,1999:blog-17002261.post-1165235022998964512006-12-04T17:53:00.000+05:302006-12-04T17:53:00.000+05:302006-12-04T17:53:00.000+05:30Software development in service industry is moving...Software development in service industry is moving towards "industrialization" and specialization. There are guys who are server admins, clear case admins and tool smiths etc. Then there are designers and architects. Where does that leave a developer? He is like a coolie in whole equation. He is provided tools, enviornments, somebody else designs for him. Architectures and frameworks takes care of complex and critical pieces in software. All he needs to do is fill in the blanks.As a manager I like this. This makes it so managebale. But as as developer I hate it. I want to know how Linux kernle is installed, how LDAP server is installed and configured, how database instances are configured and run and just about everything else. I want to being able to do it if I have to. It makes me whole lot comfortable and I feel in command. Also service industry is moving towards a direction where developers are becoming integrators. You should be able to fix and integrate lots of things to make something work. It can also be quite exciting. <BR/><BR/>And if you are a good developer you would know a rule "Be Lazy". Lazy people are better developers. Since when you are lazy you dont want to do same thing again and agin. So you write better reusable code. And you know when to automate so that next time you are doing anything which is predictive and repetitive, you can automate it. So If I end up installing lots of software and I find it bloody boring, I will think of a way to automate it. May be write a script or something. I will do it outside my project time and then gift it to the team. Anything which can be better"ed" is a problem waiting for a solution.Anonymousnoreply@blogger.com