As a business owner my passion is to help organizations create more effective software while increasing their bottom line. This is not an easy task, just saying “change this one thing” doesn’t mean that all that are involved in that change are on the same page. Even just changing one thing will require several attempts to get everyone on board and find the idea that will actually work for the team and the organization.
In order for me to be successful in helping an organization I have to be able to offer up many approaches in hopes of finding the one that will resonate with them and make the change they are looking for. Each idea is a step to the final outcome and not all ideas are successful, some will fail. In order to get to the desired result you have to be willing to fail, and maybe even fail a lot. The only way to be truly successful is by not being afraid to fail, learn, and move on.
By detaching from each approach, but at the same time being passionate about the outcome I am able to easily and unemotionally fail. Finding the right software approach is like chiseling David from the stone, it always existed, you just have to be willing and strong enough to get all the bad approaches out of the way.
Organizations usually suffer from the same inability to detach as the rest of us. Executives are tied to what has always been done, managers are tied to process and afraid of change,
As a software developer, I am also able to accept failure in order to write great software, create effective user experiences, and provide solutions that meet and exceed business objectives . This process is one of evolution; create, test, get feedback, change, rinse and repeat.
Great software can only occur by listening to great feedback and remaining passionate about the final business outcome, not by being passionate about the single piece of code that was written. The fact that I think that a screen looks good or that the code is clean has nothing to do with the actual problem being solved. When the users see it and say looks good but doesn’t do what I need it to then what good have I done? This is the point where detachment is important, by removing the emotion from what you created, actually hearing the feedback, you can be objective in learning what is actually needed.
When working on a team it is even more important to detach so that all can be objective about listening to feedback, issues, and problems. As a detached unemotional team it is way easier to make a change since it’s just a change and nothing personal against anyone. I’ve seen developers get aggravated when someone changes “their” code, I explain to them that it’s not “their” code, it’s the contribution to the bigger whole. Developers are usually very passionate, and sometimes they treat the code as their baby. Addressing these situations usually just requires a more open relationship among developers; paired programming, code reviews, and the removal of single owners from any piece of the puzzle.
When the development process requires that all developers work on all things, the attachment to a single thing is removed and the developers can concentrate on the overall solution.