No, not between two people as I'm fairly certain that could not be done in a short blog entry, but between software interfaces. More specifically, the middleware, the business intelligence/logic layer, the service layer-really, anywhere but the front end. Most companies have that legacy app sitting around, written in the stone ages by a developer that invented fire. Most likely, it is poorly documented. Often it is "childish" code. Most likely it sits somewhere in the back end and chugs along nicely, maybe every once in awhile spinning a thread out of control or having an accident and leaks memory, but you simply put on a new Pamper and recycle the app server. Then there's the day it throws a fit-a full blown tantrum! As the baby sitter, you have no choice but to intervene. 1. The first thing to do is to understand the business process. Actually, in hindsight, this can taint the process of fixing it. Why, you ask? Well, because when you ask for the business process, you are asking from the perception of someone who most likely did not do the initial describing of the business process to which the code was written. You have a gap of ,let's just say five years, where no one thought about this functionality, it just worked. The baby was ignored and turned out to be a trouble maker. You you now have this current understanding of a business process and code written to the previous understanding of the business process. 2. Lots and lots of moving parts! Arms flinging, legs flailing, head thrown back screaming. The front end invokes on application which calls another application through APIs which makes a web service request to a vendor which makes another call to another application which... you get the point. You need to understand the steps. More importantly, you need to determine where these applications reside. That seems like it would be an easy thing to do, except that some applications were deployed to app servers, but don't actually run on said app servers, ever confusing the analysis. 3. I despise improper use of variables, methods, etc, etc! There, I said it. I don't really hate them, but I do disagree with using improperly named components for something completely different. Suppose you have a variable named Milk_Bottle on the front end that has a value of '8' that gets passed into a feedBabyMilk(Ounces ounces) method. Then you realize that as your baby gets older, you need to switch to juice. Juice bottles come in milliliters so you create feedBabyJuice(MilliLiters milliliters) but call feedBabyJuice(Milk_Bottle) and convert oz to ml in the feeBabyJuice() method. Maybe this is OK, except that you are describing what is in the bottle, not the measurement of the bottle. Next, you realize that you will never feed the baby milk, so in the front end you change Milk_Bottle to convert to milliliters when it is inputted by a user and deprecate the feedBabyMilk() method, however what you don't realize is that there's another family (application) that has a newborn and still uses feedBabyMilk() thus breaking the method since you are now sending milliliters instead of ounces. I like feedBaby(Bottle bottle). 4. Duct tape vs. refactoring vs extending vs warm blanket and a soothing lullaby. When time is of the essence, what do you choose? Most of this depends on how long you end up spending researching what is happening. Mission critical says if you are crippled for 2 hours, then do what ever it takes to come back online. This means coming online could potentially involve a "fix" that might be unethical. 5. When do you give up? Thing is, you can't, you're the baby sitter. It is your responsibility to see this tantrum through. This means burning the midnight oil. Seeing the sunrise without sleep. Submitting eighty hour time sheets. 6. You eventually get argumentative. Why? Because the code appears to do one thing while the business process says it should do something else. Or, there is confusion in explaining what the code is doing and a misunderstanding of the intended functionality. But you are not arguing for arguments sake, you are still just trying to understand what is not happening that should be happening and why it decided to stop working (and wondering what else will break as you fix this). The baby should be sleeping soundly, but she's crying. He should be eating but he's burping. 7. You stop at 3 AM and think about the progress you should have made this week on new functionality, streamlining business processes, more efficient workflows, and you sink into a deep dark state, like some 1970's programmer sitting in a dark closet, closed to society while opening up the world. Where do you go from here? What is the next stage (if we ever get through this one)? 8. There's a light at the end of the tunnel. 9. Eventually you calm the beast. Slithering down into the couch and cranking up the jazz. The rhythms ease your mind-the scotch helps, too. You are the baby sitter, and the lion sleeps tonight. 10. In the end, we will always need to support the code, and if it was written last week, it just might be legacy by today. You never now how long your code will last. You never know who will need to debug it. You never know who's code you will need to debug. You never know what you will have to support. You never know when the interface will throw a tantrum.