Report Offensive Message
IT Ticket Mangement Approaches produce flawed software.
My observation is that if managers push their people to have fast ticket clearance rates that this will generate flawed unreliable software as a consequence. Even if the programmers concerned are really smart! The manager creates a system within which failures occur, although the subsequent maintenance revenue will increase, and they are able to show the customer they have a systematic approach. Hmmm....
I have yet to come across TDD in the wild, for the reasons Tony mentions.
In the stuff I have refactored: I began by sorting out the naming issues. I then address the structural issues. In the stuff I support: I have been able to split the code into chunks that works out what is required to be done, then gathers the facts of the situation and gets any additional data required and then goes ahead and does what is required. I even write less than optimal code if it improves clarity (Gasp). Each step of the process generates contextually identifiable logging entries. (Interactive debugging is not available with the tools I use. I almost think I am better off without it? I love reading my logs.)
Everytime I have to follow up on something or do a modification, I create test cases, preferably harvesting them off the production system. (This works for me but may not for you. My presentment work occurs after the transactions are finalised.) It does not take long before a decent regression suite is built up, but in my case the tests are not automated (I wish they could be.) So I exercise judgment about when to do a full suite of regression tests. I have segregated the tests by each aspect of the program to make this easier to achieve. I just run the aspect impacted by the change and hope there are no side-effects.
So to summarise: I ensure my work produces software that is understandable. Getting there requires good practices. At each step of the way I have sufficient testing to show I have not stuffed up. In those increasingly rare situations where programs go rogue, I am in a stronger and stronger position to sort them out through good logs and easy to read code.
Tony your experiences reflect some of my own. Mercifully I have often been in a position to do something about them, although I have had to run the risk of the need to move on.
Agreed, none of this is rocket science. "Write as you would be written unto" Kingsley - with mods.
Phil
I have yet to come across TDD in the wild, for the reasons Tony mentions.
In the stuff I have refactored: I began by sorting out the naming issues. I then address the structural issues. In the stuff I support: I have been able to split the code into chunks that works out what is required to be done, then gathers the facts of the situation and gets any additional data required and then goes ahead and does what is required. I even write less than optimal code if it improves clarity (Gasp). Each step of the process generates contextually identifiable logging entries. (Interactive debugging is not available with the tools I use. I almost think I am better off without it? I love reading my logs.)
Everytime I have to follow up on something or do a modification, I create test cases, preferably harvesting them off the production system. (This works for me but may not for you. My presentment work occurs after the transactions are finalised.) It does not take long before a decent regression suite is built up, but in my case the tests are not automated (I wish they could be.) So I exercise judgment about when to do a full suite of regression tests. I have segregated the tests by each aspect of the program to make this easier to achieve. I just run the aspect impacted by the change and hope there are no side-effects.
So to summarise: I ensure my work produces software that is understandable. Getting there requires good practices. At each step of the way I have sufficient testing to show I have not stuffed up. In those increasingly rare situations where programs go rogue, I am in a stronger and stronger position to sort them out through good logs and easy to read code.
Tony your experiences reflect some of my own. Mercifully I have often been in a position to do something about them, although I have had to run the risk of the need to move on.
Agreed, none of this is rocket science. "Write as you would be written unto" Kingsley - with mods.
Phil
Posted by kdf9buff
12th Mar 2012
