Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Keep It Simple, Stupid

  1. Mar 23, 2017 #1

    Borg

    User Avatar
    Science Advisor
    Gold Member

    For the last week, I have been cleaning up code left by a previous programmer who clearly didn't know what the KISS principle was. I removed over 75 class files that were completely unnecessary and made the code ridiculously difficult for others to trace through. Most of this was code that could have been put in a single method but instead, he would create several interfaces, implementing classes, unnecessary Spring wiring and enums for as few as two potential options - all while mixing front-end and back-end processes such as enums with database implementations embedded. When you got to what was actually doing the work, it was the method that should have been written in the first place without all of the extra fluff. After all, why KISS your code when you can take it out back and violate it completely?
    :doh:

    I'm wondering how many programmers have had to deal with this kind of nonsense. Do you run into code left by previous developers where they created stuff that was way more complex than it needed to be? I would be interested to hear your stories.
     
  2. jcsd
  3. Mar 23, 2017 #2

    anorlunda

    Staff: Mentor

    Can it be that the previous guy worked in a shop where lines of code (LOC) was the metric of productivity?
     
  4. Mar 23, 2017 #3

    Borg

    User Avatar
    Science Advisor
    Gold Member

    It's the same office I work and that isn't considered. I have seen that though. My managers know that my LOC when I'm working with existing code is usually negative. My previous record was a 10,000 line class file that I reduced to 2000 lines for a -8000 LOC. I'm probably somewhere well past -100K over the last year with this project.
     
  5. Mar 23, 2017 #4

    anorlunda

    Staff: Mentor

    That reminds me of the time when I consulted on Y2K remediation. Big companies had huge piles of code that nobody remembered what it did our whether it was necessary. However there was no motivation to find out if it was really needed. Y2K provided the motivation.

    Unfortunately, there is no metric that measured how much cleanup happened globally in those years, but it was a lot. One anecdote points the way. Prior to Y2K, the disaster recovery systems of most companies was an untested rats nest of s***. But on 9/11/2001 the offsite backup centers of those companies housed in the WTC worked flawlessly.

    The public image of Y2K is that of silly wasted efforts. But I believe that the benefits were enormous, but alas not measured.
     
  6. Mar 23, 2017 #5

    anorlunda

    Staff: Mentor

    @Borg, your post about negative LOC stimulated my neurons. I can't resist telling one more old war story.

    I consulted for a big company during Y2K. They had 375000 PCs. Many of their employees, when faced with a PC upgrade, backed up the old PC and restored those files on the new PC. That included who knows what executables from who knows what sources. For example, old Word Perfect documents, or Dan Bricklin Visicalc spreadsheets that potentially were used for mission critical purposes. As a result, their PCs had 4-5 generations of old software installed, but no documentation on what was actually used.

    They could have done 375,000 employee interviews to find out which files were needed for what purpose. They could have done 50 million (my estimate) forensic investigations of all those files for Y2K compliance. Instead, they elected on one weekend to wipe the hard disks on 375000 PCs and to install a standard image on each. Of course, they had 375000 angry employees on Monday who lost their personal files, their email archives, and their favorite spreadsheets. (Suppose someone did that to your laptop this Saturday. How angry would you be?) The hit job had to be done stealthily because we feared that if was announced in advance, that many employees would back up their disk on Friday and restore it on Monday.

    Nobody could say with certainty what disruption the hit job might have caused for the company's business. It took great courage to make that decision. The end result, was that by Tuesday, nothing big happened and that ugly history was rapidly forgotten. It was a huge lesson on the difference between what's possible and what's probable.

    So that does not challenge your negative LOC record @Borg, because we couldn't count the LOCs. But I think it makes a fun story.
     
  7. Mar 23, 2017 #6

    jedishrfu

    Staff: Mentor

    While you might not have a KISS policy, your manager may be secretly evaluating you on your checkins and this programmer was keeping your { clueless | trusting } manager happy.

    Another source of problems can come from new programmers who learned about java classes and interface design. Hence for every class you create an interface in case that class needs to be "replaced" with a new implementation that is plug compatible. Interfaces can make things better but they also make things hard to track through at the source level instead you need a runnable program and a good debugger.

    (I always dreamed of a kind of source code debugger that tracked data through your code just by clicking on the variable of interest. Interfaces would require the programmer to select an implementing class in that case)

    For every great programming paradigm there is some programmer ready to make a mockery of it.
     
  8. Mar 23, 2017 #7

    Borg

    User Avatar
    Science Advisor
    Gold Member

    Count me in the group that backs up data like that. My company has been aggressively limiting software installations on their computers which is a pain for developers because we have to install and test software as part of our job. It's gotten better but, for a while installed software would disappear a few days after I installed it. This led to some interesting debug-fests trying to figure out why everything suddenly stopped working. Fortunately I have an administrative account now that limits the aggression on their part.
     
  9. Mar 23, 2017 #8

    jedishrfu

    Staff: Mentor

    Variety breeds chaos but conformity opens the door to disaster. (dangerous hack attacks).

    Where all men think alike, few men think at all and that's why we need women managers.
     
  10. Mar 23, 2017 #9

    Borg

    User Avatar
    Science Advisor
    Gold Member

    I don't make any secrets about the amount of code that I've been removing and everyone on the project knows what a coding mess we're dealing with. My last two yearly performance appraisals were rated outstanding so, if she's evaluating me on that, she's happy about it.
    After checking in one particular rewrite last year, I asked the other developers on the team to let me know if they notice anything different in case I broke something. One guy said right away that he noticed something. He said that the server no longer took 5 full minutes to start and was now down to less than a minute.
     
  11. Mar 23, 2017 #10

    jedishrfu

    Staff: Mentor

    Even negative LOC are checkins so she knows you're doing your job.

    There also used to be a programmer sentiment of making things as convoluted as possible to keep your job.

    What ever happened to the programmer that wrote the awful code ?

    Another thing I've noticed is that when faced with a complex application or problem and a short deadline to fix something invariably folks will go for the surgical approach with local changes only to minimize breaking other stuff.

    Sometimes this means making a new class or a duplicate of a new class so as not to break the old class.
     
    Last edited: Mar 23, 2017
  12. Mar 23, 2017 #11

    Borg

    User Avatar
    Science Advisor
    Gold Member

    True. I'm just thankful that my paycheck isn't proportional to my LOC because I wouldn't get paid much.
     
  13. Mar 23, 2017 #12

    Borg

    User Avatar
    Science Advisor
    Gold Member

    The two self-serving phrases that I hate to hear are "job security" and "that will look good on my resume". Neither of them serves the customer.
    He apparently didn't feel like maintaining the code that he created and moved on to another project. There were also 60 property files and a ton of manual processes that had to be done by admins on the production server. I've eliminated most of those as well.
    There has been a good amount of that going on and I've been repairing that as well. Some of it was my own from when I first started on the project and didn't have the depth of knowledge about it as I do now.
     
  14. Mar 23, 2017 #13
    Most likely scenario for me would be future-proofing. I often have a solution that I know will work, but purposely chose to make it slightly more complicated so that it can be generic for whatever changes happen in the future. I like being able to simply pull a class out, drop a new one in, and have the functionality be completely different.

    I also found myself thinking that when I was a young programmer. The concept of business logic talking to a database seemed most efficient and easy to work with. I ended up with a bunch of MySQL calls in high level logic. Then came the day. "one of our clients want to use Oracle instead of MySQL, that should be easy right?" "uhhhhhhhhhhhhh" I've come across the same thing in graphics, people will purposefully abstract things because they don't know if there final product will have OpenGL or DirectX behind the scenes. Interfaces end up being particularly far removed from the window API logic. Your code should know what a window and a mouse click is. It should not care if it came from GFLW or WinAPI or X.
     
  15. Mar 23, 2017 #14

    phinds

    User Avatar
    Gold Member
    2016 Award

    Although I've had some bad experiences w/ incompetent previous programmers, I've not had any as bad as yours. Close maybe. What I HAVE had, many times, is enormous problems with code being VERY hard to maintain because of complete or effectively complete lack of proper documentation. Programmers love to program but most of them hate to document. I was often an unpopular manager because of my insistence on extensive documentation except in those cases where the programmers knew that THEY were going to have to maintain their code. Only novice programmers think that in a few years they will have a clear understanding of code just because they were the ones who wrote it.
     
  16. Mar 23, 2017 #15

    Borg

    User Avatar
    Science Advisor
    Gold Member

    Exactly. One of the reasons that I had to do some of this was that the customer wanted encrypted connections to the database. Unfortunately, they used a Spring-Mongo implementation that did not support encryption. Upgrading the Spring-Mongo wasn't an option because it would have had to been updated to a version that would have broken all of the Spring code. So, I had to hunt down and replace all of the data connections to use the DAL that I created last year. That DAL was upgraded by just setting the mongo driver to a new version. My DAL layer is build so that I could switch the entire application to use a different database without much effort.
     
  17. Mar 23, 2017 #16

    jedishrfu

    Staff: Mentor

    I always went with documents in source code and even had a script to extract them out to make a document. This was in the days of Bookmaster and C/C++ coding. The comment blocks had style similar to Java code blocks. I would generate an overview doc by extracting the first comment block of each file and a reference doc by extracting all comment blocks of a certain style patterned after C standard function descriptions:

    Code (C):

    /** method : one liner describing the method / comamnd
    *
    *   This method/module does the following...
    *
    ** syntax:
    *
    ** returns:
    *
    ** notes:
    *
    * ...
    *
    **/

     
    The logic was: Its hard to blame a programmer for not updating the documents but if they changed the code and not the comment then it's "I've got you and your little dog Toto." time.
     
  18. Mar 23, 2017 #17

    Mark44

    Staff: Mentor

    For a method or function that has parameters, there should also be a brief description of each parameter, including the permissible values.

    If a method can throw exceptions, these should be documented, as well.
    Having comments that are out of phase with the code is probably worse than not having any comments at all.
     
  19. Mar 23, 2017 #18

    phinds

    User Avatar
    Gold Member
    2016 Award

    But not JUST documented. I've often found cases where programmers did not handle possible error conditions because they didn't they the would ever be thrown. Programmers don't always make good testers.
     
  20. Mar 23, 2017 #19

    jedishrfu

    Staff: Mentor

    We had some very unique testers at work. One report we got was a race condition that if you did something in some sequence it would fail. The programmer had fixed it twice before and each time the tester reproduced it until finally no matter how fast the tester hit those keys he couldn't get it to fail ... and then it did. A sad day for that programmer losing once again to the fiendish tester.

    Another time, I had a tester on my team that found a small api issue with some example code. He wrote a defect and the programmer closed it as trivial. He wrote it again and again adding more content and more force each time until the programming team conceded that it was a design issue that they didn't know how to fix for this release.

    Yet another time, I had a tester, during system test, write up a defect that the datawarehousing software component was breaking her MP3 player. Of course, we're thinking what? that"s not part of our system test plan. Eventually though we tracked it down to a memory issue and as thanks the company laid her off as part of an annual corporate downsizing (no good deed goes unpunished).
     
    Last edited: Mar 23, 2017
  21. Mar 23, 2017 #20
    I prefer the nice standard DOxygen format simply because there are boatloads of parsers that'll both generate it for you, and convert it to wiki pages.

    Code (Text):
    /**
    @function foobar
    @accessibility private
    @desc This makes a foo and does bar on it
    @param foo_t foo - the foo to bar
    **/
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Have something to add?
Draft saved Draft deleted



Similar Discussions: Keep It Simple, Stupid
  1. Stupid arrays question (Replies: 3)

Loading...