As someone who has been in the ERP programming field for more than a few years, in both maintenance and new programming, I think this is a great article. I couldn't find a single point I disagreed with, and I found a lot of advice that would go a long way toward establishing you as a good programmer where ever you go.
Great read!I've got 1.5 years of Computer Science left. Ego is a big problem when working with people, and some of the most important things I learnt in school were: a) You WILL be wrong sometimes b) Most of your time will be spent planning and debugging c) and when planning aim low and shoot high
No, that is how you: spread bugs, scatter details (brittleness), increase program size (bloat), etcAlso, you increase complexity in a number of ways. Each swatch of code will drift in different directions. Implications are:1. Each bug in that original section of code now has to be found/fixed in N places - not just one.2. Each place where bug occurs will likely now have to be fixed in slightly different ways, meaning almost the same code will have to be read/understood N times. And you might need to come up with N slightly, or very, different solutions to the flaw, depending on how much the code for each has drifted away from the original or each other.3. Making changes - functional improvements, architectural changes, re factoring, doing speed/space/size optimization is going to be made bigger & slower job than it should be.So, you will look forward to such changes like running through two foot snow, instead of a quick spring. Chances are this will deter you from doing almost anything to improve the quality of the system, if at all avoidable.Instead, look at such pieces of code that you are copying, and see if they can be re-used better as methods, functions, classes, polymorphism, macros, etc. This will help your design not simpler and more expressive solution to the fundamental problem/requirements at hand.The result will be that code will be more malleable, less brittle. You will be empowered to resculpt your program slightly when changes are called for, rather than go chipping away all over the place in it and hoping that nothing breaks.If you copy code all over the place, the code quickly becomes highly incoherent, both intrinsically, and in the mind of the reader - any programmer who is trying to understand it. The complexity will likely go up. SQA metrics run against it will point this out; e.g. McCabe complexity metrics.Avoid code copy-paste. It is an antipattern.
I'm on both sides of the coin. I have extensive experience as a software developer, I teach programing at Cincinnati State and at The University of Cincinnati. In my experience it's possible to design exercises and labs that expose students to the value of these principles. Example: I have a lab assignment that requires the students to design and program a class while adhering to a specific interface design for the public methods. They also write a test main( ). Following that, they are required to build a new project with their class but with the test main( ) from another student in the class. The experience opens their eyes to programming in a group environment. Every quarter we have several students who fail to adhere to the defined interface, which causes their integration attempt to blow up in their face. The feedback in the lab reports is positive; they invariably realize the significance of working within the framework of the group. As teachers, we need to stick to the fundamentals of computer science while integrating exercises that reflect real-world work experience. I submit that it can be done.
Closed AccountDec 24, 2005Submitter
Wow, thanks, Koolaid guy, for the "lovely" comments.
aiieeDec 24, 2005
As someone who has been in the ERP programming field for more than a few years, in both maintenance and new programming, I think this is a great article. I couldn't find a single point I disagreed with, and I found a lot of advice that would go a long way toward establishing you as a good programmer where ever you go.
shazeubaaDec 24, 2005
dharm -- pot is for dopes. heh.
rk_crDec 24, 2005
Very good article. This article is far better than those that state the blindingly obvious, such as "comment occasionally" or "don't be a dumbass."
808kickDec 25, 2005
Great read!I've got 1.5 years of Computer Science left. Ego is a big problem when working with people, and some of the most important things I learnt in school were: a) You WILL be wrong sometimes b) Most of your time will be spent planning and debugging c) and when planning aim low and shoot high
alchemistaJan 5, 2006
Having worked for 5 years in the field, everything this guy says is right on and shows expert experience.
nicompMay 7, 2009
They need to teach more of this stuff in college. It shouldn't all be learned on the job.
johnnysoftwareDec 16, 2009
No, that is how you: spread bugs, scatter details (brittleness), increase program size (bloat), etcAlso, you increase complexity in a number of ways. Each swatch of code will drift in different directions. Implications are:1. Each bug in that original section of code now has to be found/fixed in N places - not just one.2. Each place where bug occurs will likely now have to be fixed in slightly different ways, meaning almost the same code will have to be read/understood N times. And you might need to come up with N slightly, or very, different solutions to the flaw, depending on how much the code for each has drifted away from the original or each other.3. Making changes - functional improvements, architectural changes, re factoring, doing speed/space/size optimization is going to be made bigger & slower job than it should be.So, you will look forward to such changes like running through two foot snow, instead of a quick spring. Chances are this will deter you from doing almost anything to improve the quality of the system, if at all avoidable.Instead, look at such pieces of code that you are copying, and see if they can be re-used better as methods, functions, classes, polymorphism, macros, etc. This will help your design not simpler and more expressive solution to the fundamental problem/requirements at hand.The result will be that code will be more malleable, less brittle. You will be empowered to resculpt your program slightly when changes are called for, rather than go chipping away all over the place in it and hoping that nothing breaks.If you copy code all over the place, the code quickly becomes highly incoherent, both intrinsically, and in the mind of the reader - any programmer who is trying to understand it. The complexity will likely go up. SQA metrics run against it will point this out; e.g. McCabe complexity metrics.Avoid code copy-paste. It is an antipattern.
nicompDec 16, 2009
I'm on both sides of the coin. I have extensive experience as a software developer, I teach programing at Cincinnati State and at The University of Cincinnati. In my experience it's possible to design exercises and labs that expose students to the value of these principles. Example: I have a lab assignment that requires the students to design and program a class while adhering to a specific interface design for the public methods. They also write a test main( ). Following that, they are required to build a new project with their class but with the test main( ) from another student in the class. The experience opens their eyes to programming in a group environment. Every quarter we have several students who fail to adhere to the defined interface, which causes their integration attempt to blow up in their face. The feedback in the lab reports is positive; they invariably realize the significance of working within the framework of the group. As teachers, we need to stick to the fundamentals of computer science while integrating exercises that reflect real-world work experience. I submit that it can be done.
fugugamesFeb 14, 2012
This essay is now also available on the Nook and Kindle as part of the ebook "Technicat on Software"