The Effects of Change on a Team
YAT: Yet Another Thesis...
After much tripping over thoughts and ideas, I think I finally have this post straight. There's been A TON of changes in my company over the past year. You name it, we've done it. Not all of the change has been structural. People have changed; whether it's personality, life situation (20s-30s life styles, etc.), or work assignments, everyone within the company - specifically, my group - has changed. However, the most interesting aspect, I feel, is the change in self and team knowledge.
Looking back, one year August 1st let's say, I can say without any reservation that the software we developed then is nowhere the caliber or quality that it is today. No, unfortunately, I can't proclaim 90% or better code-coverage results or even 50% as we have no vehicle by which to collect such data; alas, we are not test-driven. Even without empirical data like unit and functional test results and code coverage analysis, the amount of knowledge that has been gained over the past year, I feel, is quite staggering.
A year ago, I personally, was mildly intrigued by this whole test-driven development "modality". Design Patterns and the-like were fascinating and incomprehensible. None the less, knowledge was gained in these areas. Good teams communicate and facilitate communication amongst members so that new, valuable knowledge is continually transferred and shared with the rest of the team. If anything, this, I feel, is the single largest change that my group has seen.
And for the better.
Such positive changes and experiences, I feel, need to be properly fostered, "pampered", and reinforced to avoid spiraling back into the depths from which we came. It must be realized that, while it may be unavoidable, at times, to keep a foot rooted (temporarily) in past, progress need not be hindered.
Which leads to my question: how do you "manage" the effects of changes that team experiences? For example, the single most difficult experience I have had, post-change, has been working with legacy code. It is, quite possibly, the most depressing experience I have had. The changes I have experienced over the past year cause feelings of panic, anxiety, and near-nausea when looking at and attempting to work on this project. I so badly wish to scrap all code, burn it, and completely rewrite the application top-to-bottom. I won't. I can't. Resources won't allow it. Yet it is against my ethics, as I know I am capable of producing better software, to conform to the current codebase.
How do you manage to prevent the spiral yet still facilitate an efficient work environment?
After much tripping over thoughts and ideas, I think I finally have this post straight. There's been A TON of changes in my company over the past year. You name it, we've done it. Not all of the change has been structural. People have changed; whether it's personality, life situation (20s-30s life styles, etc.), or work assignments, everyone within the company - specifically, my group - has changed. However, the most interesting aspect, I feel, is the change in self and team knowledge.
Looking back, one year August 1st let's say, I can say without any reservation that the software we developed then is nowhere the caliber or quality that it is today. No, unfortunately, I can't proclaim 90% or better code-coverage results or even 50% as we have no vehicle by which to collect such data; alas, we are not test-driven. Even without empirical data like unit and functional test results and code coverage analysis, the amount of knowledge that has been gained over the past year, I feel, is quite staggering.
A year ago, I personally, was mildly intrigued by this whole test-driven development "modality". Design Patterns and the-like were fascinating and incomprehensible. None the less, knowledge was gained in these areas. Good teams communicate and facilitate communication amongst members so that new, valuable knowledge is continually transferred and shared with the rest of the team. If anything, this, I feel, is the single largest change that my group has seen.
And for the better.
Such positive changes and experiences, I feel, need to be properly fostered, "pampered", and reinforced to avoid spiraling back into the depths from which we came. It must be realized that, while it may be unavoidable, at times, to keep a foot rooted (temporarily) in past, progress need not be hindered.
Which leads to my question: how do you "manage" the effects of changes that team experiences? For example, the single most difficult experience I have had, post-change, has been working with legacy code. It is, quite possibly, the most depressing experience I have had. The changes I have experienced over the past year cause feelings of panic, anxiety, and near-nausea when looking at and attempting to work on this project. I so badly wish to scrap all code, burn it, and completely rewrite the application top-to-bottom. I won't. I can't. Resources won't allow it. Yet it is against my ethics, as I know I am capable of producing better software, to conform to the current codebase.
How do you manage to prevent the spiral yet still facilitate an efficient work environment?
posted by Harris at
2:00 AM
0 Comments:
Post a Comment
<< Home