Kicking the Can Down the Road
-
We keep our (encrypted) connection strings in (web)config files, and that requires us to create a unique deployment package for each of the eight environments and 12 web apps, seven windows services, and an assortment of in-house tools we have to support. After a meeting about the "problem" on Friday afternoon, I came up with a way to build all of the connection strings on the fly - in code - which will relieve us of the need to create unique deployment packages. Now, we can create a single package and when it passes testing/validation in one environment, we can simply deploy it to the next environment, eventually ending up in production. I developed the actual code for the solution, a proof-of-concept app, and a 6-page document explaining what I did. The code has almost as many lines of comments as there are lines of actual code. The beauty of this solution is that: - it can be used in our web apps AND our desktop apps/windows services - multiple connection strings can be specified for each app/tool/service - the connection strings don't actually exist as connection strings in memory until they're requested - once requested, the connection strings are built and either Base64 encoded or 256-bit encrypted (dev's choice) - it completely eliminates the need to maintain connection stings in config files. Now comes the hard part - convincing management to let us implement it. Honestly? That shouldn't be the hard part.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013First of all, it makes too much sense for them to use, unless you can convince them it was their idea. :laugh: Good show. Generating connection strings that is. I've never liked them and often found myself doing similar, and yes, because of security.
#realJSOP wrote:
The code has almost as many lines of comments as there are lines of actual code.
I hate to say this, but that's a red flag to me. 1. Are you using comments where you should be using documentation? You're perhaps either duplicating effort and creating maintenance issues #2, or you're using comments for where you need documentation - it sounds like in your case it's the former, since you have a 6 page doc. 2. What of maintenance? Is your code not clear enough to stand on its own absent all the comments? If not, why not spend that time refactoring instead? Every line of code is important. A comment is still a line of code. It must be maintained, too. If the source changes, and the comments get out of sync, then they become counterintuitive. Comments should be avoided if possible, for the same reason other lines of code should be. The most bug free, efficient code is the code you never wrote. I break this rule in one place - writing articles for code project with code in them - because comments allow me to describe what I'm doing as I'm doing it, but in normal circumstances, you aren't writing your comments for learners, but for maintainers. /design-hat *ducks*
Real programmers use butterflies
-
First of all, it makes too much sense for them to use, unless you can convince them it was their idea. :laugh: Good show. Generating connection strings that is. I've never liked them and often found myself doing similar, and yes, because of security.
#realJSOP wrote:
The code has almost as many lines of comments as there are lines of actual code.
I hate to say this, but that's a red flag to me. 1. Are you using comments where you should be using documentation? You're perhaps either duplicating effort and creating maintenance issues #2, or you're using comments for where you need documentation - it sounds like in your case it's the former, since you have a 6 page doc. 2. What of maintenance? Is your code not clear enough to stand on its own absent all the comments? If not, why not spend that time refactoring instead? Every line of code is important. A comment is still a line of code. It must be maintained, too. If the source changes, and the comments get out of sync, then they become counterintuitive. Comments should be avoided if possible, for the same reason other lines of code should be. The most bug free, efficient code is the code you never wrote. I break this rule in one place - writing articles for code project with code in them - because comments allow me to describe what I'm doing as I'm doing it, but in normal circumstances, you aren't writing your comments for learners, but for maintainers. /design-hat *ducks*
Real programmers use butterflies
- The reason for the (excessive?) comments is to answer any ecosystem-specific questions that might come up from the other devs on the team. Right now, this is just proposed code in the form of a proof-of-concept console app that encompasses the code in question, and I figured that explaining the what/why of the code in an external document was pointlessly convoluted, and a general pain in the ass. However, I did provide a word doc that explains what's happening, and were/how to integrate the code into our existing web apps. 1) As a general rule, we don't have time to generate meticulous documentation about a given code implementation, much less maintain it when something in the code changes. A programmer is much more apt to update comments than they are to seek out the correct document to update when the code changes. 2) Regardless of how "understandable" code that I wrote is to me, it could turn out to be gibberish to someone else, so comments are important. There is no such thing as code that isn't made better with comments. Why? Because I'm the 26th programmer to work on the code base over the last 13 years. We waste a lot of time trying to figure out what/why the hell is happening because there are virtually no comments in the code. Not even intellisense comments for method and property prototypes. This code base involves hundreds of thousands of lines of c#, javascript, css, and sql. NONE of it had comments before I started. 3) I will never accept or dish out ridicule for commenting code, regardless of how trivial the comment might appear. In fact, over the 40+ years I'be been a programmer, I've only been ridiculed for NOT providing enough code comments, and that only happened one time. The plain and simple fact is that I'm not the first guy to work on this code, and I can guaran-damn-tee you I won't be the last. I don't want to be the subject of name-calling and gnashing of teeth because I didn't to the job the best I could, which includes making it easier for the next guy in the food chain.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
- The reason for the (excessive?) comments is to answer any ecosystem-specific questions that might come up from the other devs on the team. Right now, this is just proposed code in the form of a proof-of-concept console app that encompasses the code in question, and I figured that explaining the what/why of the code in an external document was pointlessly convoluted, and a general pain in the ass. However, I did provide a word doc that explains what's happening, and were/how to integrate the code into our existing web apps. 1) As a general rule, we don't have time to generate meticulous documentation about a given code implementation, much less maintain it when something in the code changes. A programmer is much more apt to update comments than they are to seek out the correct document to update when the code changes. 2) Regardless of how "understandable" code that I wrote is to me, it could turn out to be gibberish to someone else, so comments are important. There is no such thing as code that isn't made better with comments. Why? Because I'm the 26th programmer to work on the code base over the last 13 years. We waste a lot of time trying to figure out what/why the hell is happening because there are virtually no comments in the code. Not even intellisense comments for method and property prototypes. This code base involves hundreds of thousands of lines of c#, javascript, css, and sql. NONE of it had comments before I started. 3) I will never accept or dish out ridicule for commenting code, regardless of how trivial the comment might appear. In fact, over the 40+ years I'be been a programmer, I've only been ridiculed for NOT providing enough code comments, and that only happened one time. The plain and simple fact is that I'm not the first guy to work on this code, and I can guaran-damn-tee you I won't be the last. I don't want to be the subject of name-calling and gnashing of teeth because I didn't to the job the best I could, which includes making it easier for the next guy in the food chain.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I'm not trying to dish or ridicule. I was both trying to understand your rationale and explain why I was even bringing it up, by way of offering what I genuinely felt was constructive criticism. I'm sorry to have offended you, assuming I did that. I think we have different philosophies regarding comment style, which your points illustrate. I can live with that, I just wanted to understand where you were coming from. I'm pretty sure I do now.
Real programmers use butterflies
-
I'm not trying to dish or ridicule. I was both trying to understand your rationale and explain why I was even bringing it up, by way of offering what I genuinely felt was constructive criticism. I'm sorry to have offended you, assuming I did that. I think we have different philosophies regarding comment style, which your points illustrate. I can live with that, I just wanted to understand where you were coming from. I'm pretty sure I do now.
Real programmers use butterflies
If I was tasked with actually implementing a given piece of code, the commenting wouldn't be nearly as heavy as it is in this case. I'd put in intellisense for method/property prototypes and mostly leave it at that, and maybe a sufficiently descriptive narrative comment at the top of the file if the code task involves creating a moderately complex class. This particular code is unique, because it wasn't tasked, or even outright requested. I did it because there was a perceived need (truthfully, I identified the need three years ago), and I like to solve problems with code. I know the kinds of questions the other devs on the team will ask, and I hate having to re-explain stuff verbally, so what/why comments serve that role, and in this case, I actually had to back-up my thought processes. I'm not actually offended, I'm just old and set in my ways. BTW, I also tend to "over-comment" code I write for CP articles. In my most recent one, I actually included the recommended implementation of an interface as a comment block because people using the code may not recall where they got it, and it's nice to have info when you're re-implementing it blind and with no backward reference material.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
We keep our (encrypted) connection strings in (web)config files, and that requires us to create a unique deployment package for each of the eight environments and 12 web apps, seven windows services, and an assortment of in-house tools we have to support. After a meeting about the "problem" on Friday afternoon, I came up with a way to build all of the connection strings on the fly - in code - which will relieve us of the need to create unique deployment packages. Now, we can create a single package and when it passes testing/validation in one environment, we can simply deploy it to the next environment, eventually ending up in production. I developed the actual code for the solution, a proof-of-concept app, and a 6-page document explaining what I did. The code has almost as many lines of comments as there are lines of actual code. The beauty of this solution is that: - it can be used in our web apps AND our desktop apps/windows services - multiple connection strings can be specified for each app/tool/service - the connection strings don't actually exist as connection strings in memory until they're requested - once requested, the connection strings are built and either Base64 encoded or 256-bit encrypted (dev's choice) - it completely eliminates the need to maintain connection stings in config files. Now comes the hard part - convincing management to let us implement it. Honestly? That shouldn't be the hard part.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I once had a boss that was hemming and hawing about a decision. Finally, after I got tired of waiting, I asked, "well, why not?" Since no good reason could be found I was given the OK. Maybe you should take that approach - "Why not?"
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Sounds good John - do I smell an article ? I hope so.
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
Wow, making it general enough for public consumption is going to take some work. We have considerations not normally encountered in the civilian ecosystem, and I have to make the code easy to implement in a way that makes sense to devs that have never been exposed to it before.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
We keep our (encrypted) connection strings in (web)config files, and that requires us to create a unique deployment package for each of the eight environments and 12 web apps, seven windows services, and an assortment of in-house tools we have to support. After a meeting about the "problem" on Friday afternoon, I came up with a way to build all of the connection strings on the fly - in code - which will relieve us of the need to create unique deployment packages. Now, we can create a single package and when it passes testing/validation in one environment, we can simply deploy it to the next environment, eventually ending up in production. I developed the actual code for the solution, a proof-of-concept app, and a 6-page document explaining what I did. The code has almost as many lines of comments as there are lines of actual code. The beauty of this solution is that: - it can be used in our web apps AND our desktop apps/windows services - multiple connection strings can be specified for each app/tool/service - the connection strings don't actually exist as connection strings in memory until they're requested - once requested, the connection strings are built and either Base64 encoded or 256-bit encrypted (dev's choice) - it completely eliminates the need to maintain connection stings in config files. Now comes the hard part - convincing management to let us implement it. Honestly? That shouldn't be the hard part.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I too have an aversion to having to "tweak" anything when moving between environments. I use a method that involves only one line of code, inserting the IIS instance ID into the connection string name. Then I code all the (encrypted) connection strings in config, but with names that include the instance ID. I use a similar method to include a visual cue as to which environment is which on the webpage (e.g. different background colour, and/or a text reminder in top-right of all screens). I was going to include the code to do this but it's the lounge after all. For more, see this tip[^] I wrote a while back. Using it for config strings is exactly the same concept and just as easy. Of course if you're not running under IIS then you need some other unique environment indicator...
-
I once had a boss that was hemming and hawing about a decision. Finally, after I got tired of waiting, I asked, "well, why not?" Since no good reason could be found I was given the OK. Maybe you should take that approach - "Why not?"
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
The main problem is that nobody wants to take on the task of implementing it in the apps they're responsible for. We have four devs on one (web) app, and the remaining six devs split their time among the other 11 apps. I am the lead on the team of four. My team is ready to jump on it, the other guys, not so much, because it means they'd have to actually do some work. The prospect of testing is what turns them off the most, I think, because implementation seems dead easy. In short, despite the need, nobody wants to put in the time. I think another problem is that they feel like I'm making them look bad by taking initiative where they wouldn't. I had a friend way back in the 70's that was in the Marines, who liked to say, "In the absence of other orders, attack." That's how I do it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
If I was tasked with actually implementing a given piece of code, the commenting wouldn't be nearly as heavy as it is in this case. I'd put in intellisense for method/property prototypes and mostly leave it at that, and maybe a sufficiently descriptive narrative comment at the top of the file if the code task involves creating a moderately complex class. This particular code is unique, because it wasn't tasked, or even outright requested. I did it because there was a perceived need (truthfully, I identified the need three years ago), and I like to solve problems with code. I know the kinds of questions the other devs on the team will ask, and I hate having to re-explain stuff verbally, so what/why comments serve that role, and in this case, I actually had to back-up my thought processes. I'm not actually offended, I'm just old and set in my ways. BTW, I also tend to "over-comment" code I write for CP articles. In my most recent one, I actually included the recommended implementation of an interface as a comment block because people using the code may not recall where they got it, and it's nice to have info when you're re-implementing it blind and with no backward reference material.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I'm glad I didn't offend you. I am not trying to change the way you do things, so much as understand them - even poke at them here and there to see if they bite. :laugh:
Real programmers use butterflies
-
The main problem is that nobody wants to take on the task of implementing it in the apps they're responsible for. We have four devs on one (web) app, and the remaining six devs split their time among the other 11 apps. I am the lead on the team of four. My team is ready to jump on it, the other guys, not so much, because it means they'd have to actually do some work. The prospect of testing is what turns them off the most, I think, because implementation seems dead easy. In short, despite the need, nobody wants to put in the time. I think another problem is that they feel like I'm making them look bad by taking initiative where they wouldn't. I had a friend way back in the 70's that was in the Marines, who liked to say, "In the absence of other orders, attack." That's how I do it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Yes, I can see that being a problem. I am the same way - I seem to be much more proactive than others. I think it's mostly because I prefer to address issues before they become problems because there seems to always be enough problems to deal with.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Every time it's requested. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Wow, making it general enough for public consumption is going to take some work. We have considerations not normally encountered in the civilian ecosystem, and I have to make the code easy to implement in a way that makes sense to devs that have never been exposed to it before.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I would like to see how you do this
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
The connectionstring when "at rest" is not assembled into a string. It merely exists in its component parts. When you call the "Get" method to retrieve the connection string, it assembles the parts into a connection string, and either base64 encodes it, or 256-bit encrypts it (programmer's choice) and returns that encoded/encrypted string. When you're ready to access the database, you simply decode/decrypt it when you send it to the SqlConnection object. (We don't use Entity Framework or any other ORM, so this approach is no problem). Any using base64/encryption is optional as well, you can have it return a string as plain text as well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I work for the government in the UK ( at local level ) so it definitely is of interest
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
While staring at the code trying to come up with a way to describe how it works, I actually came up with what I think is a better way to approach some of it, so code introspection is a "good thing" (TM). :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
If I was tasked with actually implementing a given piece of code, the commenting wouldn't be nearly as heavy as it is in this case. I'd put in intellisense for method/property prototypes and mostly leave it at that, and maybe a sufficiently descriptive narrative comment at the top of the file if the code task involves creating a moderately complex class. This particular code is unique, because it wasn't tasked, or even outright requested. I did it because there was a perceived need (truthfully, I identified the need three years ago), and I like to solve problems with code. I know the kinds of questions the other devs on the team will ask, and I hate having to re-explain stuff verbally, so what/why comments serve that role, and in this case, I actually had to back-up my thought processes. I'm not actually offended, I'm just old and set in my ways. BTW, I also tend to "over-comment" code I write for CP articles. In my most recent one, I actually included the recommended implementation of an interface as a comment block because people using the code may not recall where they got it, and it's nice to have info when you're re-implementing it blind and with no backward reference material.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Comments are necessary for one simple reason, "I don't know what you are thinking when you wrote or changed this code". Documentation is removed from the code does not live with the code and can and will be lost. I don't know how many times I have heard, "We don't know what happened to the docs". Still don't think comments are needed? Ok then try this exercise. Write some code to solve a problem you have today. Ok now put the code away and don't look at it for 6 weeks. In 6 weeks go back to the code and make a change, fix a bug do something to it. Time how long it takes you to 'remember' how the code works and what you need to do to make the fix. Still not convinced? Perform the same process, but this time put comment headers in explaining what you were thinking when you wrote the code. Put the code away for 6 weeks and then perform the same test again only this time with the comments. Don't have time for all this process? What to jump to the result? In the first case, it will take you a fair amount of time reading and trying to remember what you were trying to do and how something worked. In the second case, you will find that you can make the update and or fix it in less than a few minutes. Now put yourself in someone else's shoes. If you went through this with your code and you wrote that code imagine how the next developer to pick up your code will feel? Ever wonder why the next devs end up throwing out, refactoring, or reworking lots of code? Guess what it's not as self-documenting as you want to think. I learned this lesson back in the assembler days. I wrote a one-off tool to solve the problem I had at the time. A week later (yes only 1 week) I needed the code again to solve the same problem, but it did not work on this 'slightly' different set of data. No problem I thought, I'll just fix the bug. Two hours later I was finally starting to understand how the tool was supposed to work and where the problems were. That was the last time I ever wrote code that did not have comments.
-
Comments are necessary for one simple reason, "I don't know what you are thinking when you wrote or changed this code". Documentation is removed from the code does not live with the code and can and will be lost. I don't know how many times I have heard, "We don't know what happened to the docs". Still don't think comments are needed? Ok then try this exercise. Write some code to solve a problem you have today. Ok now put the code away and don't look at it for 6 weeks. In 6 weeks go back to the code and make a change, fix a bug do something to it. Time how long it takes you to 'remember' how the code works and what you need to do to make the fix. Still not convinced? Perform the same process, but this time put comment headers in explaining what you were thinking when you wrote the code. Put the code away for 6 weeks and then perform the same test again only this time with the comments. Don't have time for all this process? What to jump to the result? In the first case, it will take you a fair amount of time reading and trying to remember what you were trying to do and how something worked. In the second case, you will find that you can make the update and or fix it in less than a few minutes. Now put yourself in someone else's shoes. If you went through this with your code and you wrote that code imagine how the next developer to pick up your code will feel? Ever wonder why the next devs end up throwing out, refactoring, or reworking lots of code? Guess what it's not as self-documenting as you want to think. I learned this lesson back in the assembler days. I wrote a one-off tool to solve the problem I had at the time. A week later (yes only 1 week) I needed the code again to solve the same problem, but it did not work on this 'slightly' different set of data. No problem I thought, I'll just fix the bug. Two hours later I was finally starting to understand how the tool was supposed to work and where the problems were. That was the last time I ever wrote code that did not have comments.
If I'm heads-down in a project during a coding frenzy, I forget after just a few minutes a lot of times. :) Of course, I'm old, and I have to consciously put brain time toward trying to get to the bathroom in time, so unimportant stuff like what a method that I just wrote does takes a back seat to the more immediate need... :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
If I'm heads-down in a project during a coding frenzy, I forget after just a few minutes a lot of times. :) Of course, I'm old, and I have to consciously put brain time toward trying to get to the bathroom in time, so unimportant stuff like what a method that I just wrote does takes a back seat to the more immediate need... :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Of course, there is the other school of thought I don't subscribe to personally. If the code was hard to write it should be extremely difficult to modify, and impossible change". From time to time get to work with SDEs that think this is the way code should be.
-
I would like to see how you do this
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
The article's been posted: A Connection string manager for multi-environment ecosystems[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
The connectionstring when "at rest" is not assembled into a string. It merely exists in its component parts. When you call the "Get" method to retrieve the connection string, it assembles the parts into a connection string, and either base64 encodes it, or 256-bit encrypts it (programmer's choice) and returns that encoded/encrypted string. When you're ready to access the database, you simply decode/decrypt it when you send it to the SqlConnection object. (We don't use Entity Framework or any other ORM, so this approach is no problem). Any using base64/encryption is optional as well, you can have it return a string as plain text as well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Of course, there is the other school of thought I don't subscribe to personally. If the code was hard to write it should be extremely difficult to modify, and impossible change". From time to time get to work with SDEs that think this is the way code should be.
