I currently work for a great company, in a newly created office and within a young team.
I have been working with technologies that are new to me and I have been enthusiastically discovering and comparing them to what my previous experience (See C# vs Java blog) for a few months now. I have lots of things to learn about our huge system but I already know, with strong belief, that we need to reconsider our software development strategies. I'll get to what I mean by that in a moment.
I am a developer, I love it, and I prefer to remain in this analytic and technical position forever; as I am not really a people's person and so I prefer not to manage others. I prefer to delegate administrative tasks to my manager and his/her assistant. But I also care about my performance, and others' a lot, and this is where my preferences are challenged and I have to go beyond my skill set as a developer and start dealing with a structure (or semi-structure) that involves code and many people writing code into a single system.
It seems that social interaction is very important in making change with all the subtleties involved in human behavior, feelings, motivation and all this psychology-related things that I am not experienced to deal with. People, even many programmers who are supposed to be logic-oriented agents, do not react solely according to their perception of what's right and wrong or what's better for the team or not.
It looks like we are in a loop of hardship. There are tons of work to be done, so there isn't time to reconsider our software development strategies and/or build tools that will allow us to work more efficiently. Of course that's an invalid reason, but instead there are 3 factors for the real reason behind our pretense of the validity of the former: 1- We need to fix the bugs, not create science-fiction-like bug-fixers. (The sense of being overwhelmed by work makes not want to add any burden and i believe it to be agreeable that creating development tools and reconsidering strategies is a tough task) 2-People are used to what they do now. (I surely don't want to get to that point, and it's not going to happen because I constantly reflect on my actions and try to evaluate whether what I am doing could be done by a program) 3-
What I aim for is to capture and automate patterns. And this must be a long term goal for many reasons 1-I am new to the company. 2-There are many people working on this product and they are scattered geographically. 3-The system is huge, sophisticated and the tasks require time to be effectively detected and summarized into a pattern-representation. 4-The inherent nature of many people to resist change and this is a widely talked about topic: everyone knows that if people are comfortable they would feel less comfortable to change how things go.
One very effective way to dealing with this is to delegate the organization of change to managers. They have authority and people are used to listening to them. Cheer-leading in this case is an optional luxury.
There is also the important problem of Bug Loops. I was exposed to many scenarios where a fix of a bug caused side-effects that invalidated a solution to another previous bug. Now people must have checked but also a system must be able to detect of whether a change 'might' affect other bugs and suggest that the the person making changes rechecks that the previous solutions hasn't been affected. In a workplace with lots of work, there should be a automated process assisting developers not to make mistakes, because software developers, just like CEOs are busy and need secretaries. I suggest that these secretaries be customized, business-field oriented, developer tools.
