5 ms·

Maybe your code is too complicated? 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 i

by DTrejo 16y ago

Maybe your code is too complicated? 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. Sadly we don't live in an ideal world.

singular 16y ago
I don't think it takes very much complexity before this kind of situation arises (perhaps my example was a little contrived!), maybe it would be clearer to apply this to debugging where it certainly becomes very quickly apparent even with extremely simple code. I don't think what you claim as ideal is possible - the only thing a programming environment can hope to offer is to eliminate as much accidental complexity as possible, leaving you to focus on essential complexity. The real-world problems we try to solve as developers are usually at least somewhat hard (even the seemingly simple ones), no getting away from that. In no way intending to be condescending, I seriously recommend you read 'No Silver Bullet' by Fred Brooks if you haven't already - http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet - an absolute classic (and important too I think).
epochwolf 16y ago
> 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.
- tel 16y ago
  "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.
  - epochwolf 16y ago
    > 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.
  - LeBleu 16y ago
    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.
ColinDabritz 16y ago
What if we looked at it as a competitive advantage? Teamwork is a competitive advantage because a good team can develop more complex systems than a single programmer. Clean and simple code with good architecture is a competitive advantage, because using simpler more appropriate constructs, we can develop more complex systems (or our systems run faster, or take less resources) If we are able to go into super brain mode we are able to deal with and build more complex systems. I like clean code as a competitive advantage, or force multiplier, but I also like the ability to use super brain mode to be able to handle more complex systems. The double edged sword is that you've made a more complex system requiring the focus of super brain mode to work with, but if you use it carefully, sparingly, and wisely, perhaps your system can do things that a constant interruption brain mode system just can't do. It's a dangerous but powerful tool in my opinion. Perhaps working in that space is what separates the good or amazing developers from the code monkeys? Or is it always too much of a liability to have such a system?

by DTrejo 16y ago

singular 16y ago

I don't think it takes very much complexity before this kind of situation arises (perhaps my example was a little contrived!), maybe it would be clearer to apply this to debugging where it certainly becomes very quickly apparent even with extremely simple code. I don't think what you claim as ideal is possible - the only thing a programming environment can hope to offer is to eliminate as much accidental complexity as possible, leaving you to focus on essential complexity. The real-world problems we try to solve as developers are usually at least somewhat hard (even the seemingly simple ones), no getting away from that. In no way intending to be condescending, I seriously recommend you read 'No Silver Bullet' by Fred Brooks if you haven't already - http://en.wikipedia.org/wiki/No_Silver_Bullet http://en.wikipedia.org/wiki/No_Silver_Bullet - an absolute classic (and important too I think).

epochwolf 16y ago

> 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.

tel 16y ago
"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.
- epochwolf 16y ago
  > 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.
- LeBleu 16y ago
  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.

ColinDabritz 16y ago

What if we looked at it as a competitive advantage? Teamwork is a competitive advantage because a good team can develop more complex systems than a single programmer. Clean and simple code with good architecture is a competitive advantage, because using simpler more appropriate constructs, we can develop more complex systems (or our systems run faster, or take less resources) If we are able to go into super brain mode we are able to deal with and build more complex systems. I like clean code as a competitive advantage, or force multiplier, but I also like the ability to use super brain mode to be able to handle more complex systems. The double edged sword is that you've made a more complex system requiring the focus of super brain mode to work with, but if you use it carefully, sparingly, and wisely, perhaps your system can do things that a constant interruption brain mode system just can't do. It's a dangerous but powerful tool in my opinion. Perhaps working in that space is what separates the good or amazing developers from the code monkeys? Or is it always too much of a liability to have such a system?