> I suppose the ultimate goal is too keep one's code clean and simple enough that one does have to go into super brain mode in order to solve a problem.
Let's drop back into reality for a minute. Just 15 minutes ago I was tracing sql data converted to xml by a rails application which was processed by a perl frontend. Yay legacy code.
It would really be nice for things to be simple but the reality is I'm dealing with multiple erp systems that output mostly similar xml thanks to the people that where here before me. It is not possible to not end up in super brain mode with some of the problems I deal with.
Now my latest project was rather complicated. I took a report that only showed current inventories and converted it to display inventories at any specific day. It was all fine and simple until I encountered a little off by one bug which caused most of the dates to be off by one. Tracing that error through all the layers required a number of hours. I am thankful I was not interrupted with an emergency fix to some production report so it only took hours to fix instead days.
It would be nice if things were simple but not everyone gets to work with clean environments and applications.
This is an appropriate working style for dealing with legacy code. The key is to be able to switch gears when you're writing new code that doesn't integrate so heavily and you aren't so constrained (more typical in a startup). Different environments require different working styles.
"It is not possible to not end up in super brain mode with some of the problems I deal with."
I'll argue that it is possible, just not necessarily preferable. You could rewrite the whole thing. You could also focus on building a number of small functions which brings the whole interface up to a human-digestible level.
The reality of the matter is not the realm of possibility, but instead that you often just want to get it working by whatever super-herculean effort it takes. People are often very interruptible while fighting hydras or stealing golden fleece.
So it's twofold. Ensure that as often as possible you've got the programmatic infrastructure to only consider human-digestible chunks of complexity at any given time and try not to be interrupted whenever that's not possible.
> I'll argue that it is possible, just not necessarily preferable.
No, it's not possible. I do my best to minimize complexity but it's hard.
I don't have access to most of the systems I interface with. This is what I am talking about. The complexity is not just in legacy code but in interfaces I don't have control over. The project I mentioned was a complete rewrite and I'm able to modify most sections of it without tons of brain power. It's just the main report that's confusing as hell due to requirements.
When things external to code are complex you need brain power. You need to create abstractions and your abstractions end up being complex because you can't mask some of the requirements behind simpler code. There is also a problem of lacking tools. I have no ability to use a real debugger on any of the programs I work with. Only one application will run on my laptop, everything else is sitting in a carefully deployed minefield of interconnected dependencies on various linux servers.
I'm amused that you think it is possible to rewrite the whole thing without entering super brain mode. In my experience, generally the only way to reproduce such legacy reports is by reverse engineering how they currently work. (which will require super brain mode based on the above described current complexity) One would think someone in the business would know what the report is supposed to do, but I frequently encounter cases where no one does, they just want the report to work the way the old one did, whatever the heck that was.
I know of no solution not involving time travel to solve that for legacy reports and systems. Obviously going forward one can worry about documentation, etc. but with legacy stuff it is already too late to implement those rules.
Which describes what I was dealing with perfectly. Unfortunately the guy before me was a rather brilliant python programmer writing rails code on an extremely short deadline. I at least had the luxury of having a short in person meeting with the person using the report which allowed me to clean up some misfeatures that had been implemented due to miscommunication over the phone. (Person using the report was out of state)
Let's drop back into reality for a minute. Just 15 minutes ago I was tracing sql data converted to xml by a rails application which was processed by a perl frontend. Yay legacy code.
It would really be nice for things to be simple but the reality is I'm dealing with multiple erp systems that output mostly similar xml thanks to the people that where here before me. It is not possible to not end up in super brain mode with some of the problems I deal with.
Now my latest project was rather complicated. I took a report that only showed current inventories and converted it to display inventories at any specific day. It was all fine and simple until I encountered a little off by one bug which caused most of the dates to be off by one. Tracing that error through all the layers required a number of hours. I am thankful I was not interrupted with an emergency fix to some production report so it only took hours to fix instead days.
It would be nice if things were simple but not everyone gets to work with clean environments and applications.