Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming Software Databases Open Source Operating Systems News Technology

Ask Slashdot: What Are Some Bad Programming Ideas That Work? (infoworld.com) 674

snydeq writes: Cheaper, faster, better side effects -- sometimes a bad idea in programming is better than just good enough, writes InfoWorld's Peter Wayner: "Some ideas, schemes, or architectures may truly stink, but they may also be the best choice for your project. They may be cheaper or faster, or maybe it's too hard to do things the right way. In other words, sometimes bad is simply good enough. There are also occasions when a bad idea comes with a silver lining. It may not be the best approach, but it has such good side-effects that it's the way to go. If we're stuck going down a suboptimal path to programming hell, we might as well make the most of whatever gems may be buried there." What bad programming ideas have you found useful enough to make work in your projects? Don't be shy or ashamed, we all want to hear your responses!
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Are Some Bad Programming Ideas That Work?

Comments Filter:
  • Denormalize (Score:5, Insightful)

    by tomhath ( 637240 ) on Monday August 15, 2016 @07:33PM (#52707903)

    I won't even call it a "bad programming idea". I've seen more problems from over normalizing a database than from under normalizing.

    Maybe the bad idea is trying for fourth normal.

    • Re:Denormalize (Score:5, Insightful)

      by sexconker ( 1179573 ) on Monday August 15, 2016 @07:39PM (#52707939)

      CNF2 is good. CNF3 is sometimes better. CNF4 is usually worse.

      • Re:Denormalize (Score:5, Insightful)

        by Anonymous Coward on Tuesday August 16, 2016 @12:03AM (#52709303)

        If it is stupid and it works, it is not stupid.

        I learned the above in the military, and I have seen no reason to unlearn it in 32 years working as an IT professional... Yeah, I'm no longer a programmer, but I still reach for my favorite hammer when I see a nail. Two years ago, I embedded Assembly Code into something that operated on Terabytes of transaction data. It wasn't stupid.

        • If it is stupid and it works, it is not stupid.

          I learned the above in the military, and I have seen no reason to unlearn it in 32 years working as an IT professional... Yeah, I'm no longer a programmer, but I still reach for my favorite hammer when I see a nail. Two years ago, I embedded Assembly Code into something that operated on Terabytes of transaction data. It wasn't stupid.

          Define "work". I've seen reports that prints the correct numbers but that are built (I shit you not) with cartesian joints executed in loops, over and over, per row.

          A more extreme example (I'm not making this shit up) - a reports server that makes a web service call to a "reports composer" service, one call per page, and for each page, the "reports composer" service makes multiple database queries per row (like not one of the a-holes who created this knew how to make SELECT SUM(somefield) FROM table GROUP

      • Re:Denormalize (Score:5, Insightful)

        by SpaghettiPattern ( 609814 ) on Tuesday August 16, 2016 @12:34AM (#52709427)

        CNF2 is good. CNF3 is sometimes better. CNF4 is usually worse.

        Sorta. First you analyze your model to be 3NF or 4NF. Then you denormalize in a controlled way. Logic before optimization.

        Accidental 2NF usually means the problem wasn't well analyzed. And that most likely there will be problems ahead caused by bad abstraction.

        • Then you denormalize in a controlled way.

          That sounds very much like something that optimizing compilers are for. Perhaps this means that the toolchains and/or abstraction levels are deficient?

    • Re:Denormalize (Score:5, Insightful)

      by Derekloffin ( 741455 ) on Monday August 15, 2016 @07:40PM (#52707943)
      Yeah, that. It is often a real pain in the neck to deal with a heavily normalized DB, where a few simple pieces of denormalized data would help you out immensely. "Bad" idea, but definitely works at times.
      • by raymorris ( 2726007 ) on Tuesday August 16, 2016 @08:51AM (#52711191) Journal

        Views allow you to operate on the database as if it were denormalized, without losing the consistency guarantees and other benefits of a properly normalized database.

        It's the same concept as STORING datetimes as a number internally, a consistent, monotically increasing number, while DISPLAYING them as strings like "November 6, 2016 1:30 AM". Storing "November 6, 2016 1:30 AM" is crap for any kind of calculation, especially because that string represents two different times an hour apart - there's no way to know whether that comes before or after "November 6, 2016 1:20 AM".

        Similarly, views are virtual tables which provide whatever you'd like the user to see, without breaking the underlying data structure.

    • I don't have to come up with bad programming practices that work!

      I have outsourcers who do that for me!

  • pop (Score:5, Funny)

    by Anonymous Coward on Monday August 15, 2016 @07:37PM (#52707921)

    using assembly language to code a web page because the boss wanted it to be fast

    • Re: (Score:3, Funny)

      by Joce640k ( 829181 )

      using assembly language to code a web page because the boss wanted it to be fast

      The bad idea was using JavaScript/PHP/whatever in the first place.

      Languages designed by clowns.

      The moment they should have given up was when they realized they needed to add an extra '===' operator because they messed up the '==' operator so badly.

      (and all the rest of the bad ideas they had around the same time they were implementing '==')

  • Goto (Score:5, Insightful)

    by jomegat ( 706411 ) on Monday August 15, 2016 @07:38PM (#52707933)
    Goto. I use that (in C) for error handling all the time, and frankly, it is about the cleanest way to do it I have seen.
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      I also used to do this all the time in C. Code looks a lot cleaner this way.

      • Re:Goto (Score:5, Insightful)

        by Darinbob ( 1142669 ) on Monday August 15, 2016 @09:14PM (#52708501)

        I've seen code that avoids this, or avoids multiple returns from a function, and the result was very difficult to understand. Either lots of misc state variables, or extreme indentation, etc.

    • Re:Goto (Score:5, Interesting)

      by lordlod ( 458156 ) on Monday August 15, 2016 @08:29PM (#52708237)

      Sure, C gotos are the cleanest solution in a few specific cases and sometimes I get frustrated in higher level languages that lack it.

      However I still demonise gotos when teaching coding because it should be use carefully and sparingly. New programmers often see it as a versatile stick that can solve all their problems, and while it can make the code "work" we moved on from spaghetti code for a reason.

      My personal rule is that a goto should only ever go down the code and never into new blocks.
      (except for implementing a try/catch system using longjump, every rule has an exception...)

      • by truedfx ( 802492 )

        My personal rule is that a goto should only ever go down the code and never into new blocks.

        My personal rule is simpler: if the transition would make sense in a flowchart of what the code is meant to do, then it makes sense in the code. If the only way to write that transition is through the use of a goto statement, then it makes sense to use a goto statement. This generally allows a bit more than your personal rule, but requires the person writing the code to be capable of creating intelligible flowcharts.

    • Re:Goto (Score:5, Funny)

      by fahrbot-bot ( 874524 ) on Monday August 15, 2016 @09:37PM (#52708633)

      Goto. I use that (in C) for error handling all the time, and frankly, it is about the cleanest way to do it I have seen.

      One little goto [xkcd.com]. How bad can it be?

  • by nadass ( 3963991 ) on Monday August 15, 2016 @07:41PM (#52707949)
    Every new software, platform, framework, library, protocol, language, compiler... is rife with shortcuts (by design or accidentally) which are, relatively speaking, considered 'bad programming ideas' from generations of folks who did not prioritize them previously. So every modern program basically sucks for the same reason.
  • HTML (Score:5, Insightful)

    by Anonymous Coward on Monday August 15, 2016 @07:42PM (#52707953)

    While it's great for reporting, It will never be a good fit for real applications. When I say real, I mean the ones that you use to actually get work done and not browse kitten videos. Modern use of HTML/JavaScript is the worst example of shoving a square peg into a round hole that I've ever seen... and yet, with enough effort, we make it work.

  • Sub-optimal code. (Score:4, Insightful)

    by Derekloffin ( 741455 ) on Monday August 15, 2016 @07:44PM (#52707961)
    Frequently run into it, where I have a data set that is small, but difficult as hell code in such a manner as to go through efficiently. So, I can spend many hours trying to get the efficient code right, or just use the much simpler more brute force approach which will still get the task done just a quickly to the user's perception.
  • Bad, you want bad: (Score:5, Insightful)

    by geoskd ( 321194 ) on Monday August 15, 2016 @07:46PM (#52707965)

    C++ Template Metaprogramming FTW.

    For when it absolutely positively has to squeeze every last instruction cycle, and screw the next guy...

    • Unused cycles are wasted cycles!

  • Empty set (Score:4, Insightful)

    by Excelcia ( 906188 ) <kfitzner@excelcia.ca> on Monday August 15, 2016 @07:47PM (#52707969) Homepage Journal

    There aren't any bad programming ideas that work.

    • Re:Empty set (Score:5, Interesting)

      by internerdj ( 1319281 ) on Tuesday August 16, 2016 @09:48AM (#52711547)
      Most bad programming ideas are bad programming ideas because they don't scale. They work fine in a small code base with sufficient documentation. They probably work fine sparingly in a large code base with good documentation. The problem is that if we teach bad programming ideas are routinely OK if we are careful, then we rely on them and when scope grows and we inevitably hit a moment in the project that doesn't allow for solid adherence to good software engineering practices then it blows up in our face spectacularly.
  • Bad Ideas (Score:5, Insightful)

    by MightyMartian ( 840721 ) on Monday August 15, 2016 @07:47PM (#52707971) Journal

    Coding in Javascript, PHP and VB6.

    • Coding in Javascript, PHP and VB6.

      There's nothing wrong in coding something in JS when it's appropriate. Some page effects can't be done any other way, and Ajax has allowed the creation of full-featured web apps that are the rival of many desktop apps. It's one tool of many in the box and it has its place.

      PHP is full of warts but I love it. It's made me a boatload of money over the years and I've never regretted learning and using it. It makes my house payment (and more) every month. Hard for me to complain about that.

      VB6...yeah, that one i

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        > VB6

        Yet, there are plenty of nice things about it, for example:

        Debugger: you can skip the execution point forward/backwards. You can edit code _live_ whilst debugging, or execute custom code in the same context as what's being debugged, and you can debug that as well. Can your favorite language's debugger do this?

        = operator that makes sense: how many beginners fall over the = vs == confusion? In VB6, you'll never accidentally assign a variable in an if condition.

        With statement actually works well, un

    • Re:Bad Ideas (Score:5, Insightful)

      by ZecretZquirrel ( 610310 ) on Monday August 15, 2016 @08:09PM (#52708119)
      Specifically, so-called "web" interface programming using client-side Javascript on the DOM.
      • Specifically, so-called "web" interface programming using client-side Javascript on the DOM.

        Amen! Productivity (work-related) application programming (CRUD) using HTML/DOM/JS is a f8cking nightmare.

        Part of the problem is that each browser brand/version combo can potentially render things differently such that you have to test on say 30+ combo's of browsers and devices to cover all bases, AND future versions may STILL break it after all those 30+ tests. My hair is turning Bernie Sanders shades over that cra

    • At least in JS and PHP, you have basically the same syntax as C, giving you the opportunity to write clean code. Again the problem is not the language, that's the person using it.
    • by Z00L00K ( 682162 )

      Not only VB6, any VB.

      But you forgot Delphi these days - the company behind it is falling apart since lead developers on the compiler have dropped off.

  • by xevioso ( 598654 ) on Monday August 15, 2016 @07:48PM (#52707975)

    There's a lot of cases where you end up doing something that is considered not "best practice" and is frowned upon, but it gets the job done, is not likely to cause headaches for future developers, and is the most efficient way to solve a problem. It's not programming, but using !important to force a style when you absolutely have to or to override a bad implementation of bootstrap is a surefire way to solve an issue.

  • by stoicio ( 710327 ) on Monday August 15, 2016 @07:50PM (#52707993) Journal

    and Matlab ....ffffffFFFFFFFFUUUUUUUU..........!

    enough said.

  • by Anonymous Coward

    Seems terrible because you become less productive, but with the overhead of communication with a larger team, it's still much more efficient than hiring more people.

  • by OrangeTide ( 124937 ) on Monday August 15, 2016 @07:51PM (#52708007) Homepage Journal

    Or really file systems in general, but most of the modern ones has directories. File systems try to seem like a general purpose database abstraction, but using a filesystem to access data is really fraught with peril.

  • enum values (Score:4, Interesting)

    by Anonymous Coward on Monday August 15, 2016 @07:53PM (#52708023)

    I've occasionally relied on enumerations being particular values, as a shortcut. Makes me feel icky, tho.

  • Throwing an exception with a completely empty catch block.
  • by gfody ( 514448 ) on Monday August 15, 2016 @07:59PM (#52708063)

    Or rather forget about what's business logic and what's not - if it can be done in the database, do it there.

    • Bad programming ideas: separating "business logic" from the rest of your program. Not sure what the difference is between 'business logic' and the rest of your programs that run your business but a lot of people seem to want to separate them out.
      Any database implements a turing complete language, it's generally a really bad idea to do anything there. Although to save time, I've often implemented SQL triggers and the like to do clean up that I didn't want to figure out in the program.

      • separating re-usable "business logic" from the vendor-specific language of your data repository

        ftfy, make more sense now? Not everybody delivers (or stays) on the same RDBMS all the time. Not to mention how miserable it is to debug programs that live half in the middle tier and half in triggers. Or better yet, autonomous transactions in triggers - aren't those fun? You may want to look into interception frameworks.

  • by shellster_dude ( 1261444 ) on Monday August 15, 2016 @08:03PM (#52708085)
    Few programs are more hellacious to write and maintain than code that has been overly-factored into classes, that inherit from other class, that implement some abstract that was inherited from other abstract, that isn't even called directly because it is actually a event handler or intent for yet another inheritance mess. OOP makes sense if used sparingly, if not, it makes GOTO spaghetti look sane.
    • by Shados ( 741919 ) on Monday August 15, 2016 @08:16PM (#52708163)

      I came here to actually say OOP.

      Its an absolutely terrible idea that tries to make software work the way we think it should, not the way we think.

      It never ends well, and every time it goes to hell, people say "Oh, but if it had been done right in the first place..."

      Though somehow people actually make it work, and right now superior functional patterns aren't taught, so if you implement them everyone thinks you're crazy. So for now, OOP is a terrible idea that "works", that many know is wrong, but that we still use for historical reason to make working software, for now.

      • by dgatwood ( 11270 ) on Monday August 15, 2016 @08:55PM (#52708387) Homepage Journal

        Likewise. OOP is an interesting design pattern, but not when taken to the extreme. Far too often, people use inheritance where an "if" statement in a couple of methods and an initialization-time flag would have sufficed, and the result is invariably unholy.

        I don't agree, however, that functional programming is an improvement. Functional programming is a migraine. In my experience, it usually causes things that are relatively trivial in procedural programming to turn into mounds of code. Everything that's bad about OOP is also bad about FP, just in different ways.

        The goal should always be to produce less code, to the maximum extent possible, and both of these paradigms tend to do the opposite—particularly in the hands of beginners, but not exclusively so.

        • by geoskd ( 321194 ) on Tuesday August 16, 2016 @12:36AM (#52709443)

          The goal should always be to produce less code

          Absolutely not, the goal should be to write the simplest code. Simplest being defined as easiest to understand that gets the job done. Simple code has fewer bugs, is generally easier to write, even if it is longer sometimes, and is far and gone easier to maintain.

          Many code abbreviation techniques actually make code harder to understand, like some of the sketchier if constructs in C, in-line class definitions in C++, etc... And before you start talking about in-line class definitions being faster, modern compilers have been able to handle whole program optimization including cross-source in-lining for many years now, there is no longer any benefit to having any code in headers, and for readability, lots of good reasons to never have code in headers. Keep each class in its own files (header and source pair), and nobody gets hurt.

          • by dwpro ( 520418 )

            You make a fair point, but I'd say 'simpler' is far more subjective than 'less', and less seems to be the right answer 95% of the time.

      • by AuMatar ( 183847 ) on Monday August 15, 2016 @10:37PM (#52708943)

        I actually think you're completely backwards. Most programmers think in terms of basic OOP and procedural programming. Nobody thinks in terms of functional programming- that's why no functional language has ever been a major commercial language.

      • It depends upon how people think about it. Some try to have each class be a real "thing" instead of being something more abstract, it's the way a lot of textbooks try to teach OOP. A file is a thing and so gets a class; a semaphore is a thing; a window is a thing that you can actually see so definitely it's a class. But a behavior, yuck, it's not a thing, so it starts to trip people up. But if you think of classes as an abstraction to tie data and behavior together, then you can look at it differently.

      • Its an absolutely terrible idea that tries to make software work the way we think it should, not the way we think.

        It depends, I'd say. Coming from a background as a mathematician, I tend to see programming a bit like set theory (set theory has a lot to do with binary logic, in fact, so perhaps that makes sense). Set theory is a funny subject - the theory we learned in school ('naive set theory') is very intuitive and gives us some profound insights into the nature of several important concepts; but it also runs into serious problems, like the Cantor Paradox. To get around these problems, there are now several, highlly

    • by quietwalker ( 969769 ) <pdughi@gmail.com> on Monday August 15, 2016 @08:25PM (#52708211)

      I had to work under a lead who had "Design Pattern Prejudice". Every class had to be named based on the pattern it took after, and everything had to come from factory factories that worked off interfaces to abstract parents at every step, everything had to be immutable, and in any given review, he'd point to a section of code and ask what design pattern this followed. If you couldn't specify one, he'd fail the review, and if you could, he'd want you to rewrite it to use at least 2 or 3 more patterns.

      Granted, he'd spend a whole week writing code, fail to complete any of his issues, and check in around 40 new classes & interfaces, but not one of them had any business logic in them at all, and then demand everyone refactor their code to use his new architecture.

      We only got things done when we started ignoring him.

      • The principle here is 'be selective about who you listen to'.

        Sometimes just listening to the client is the quickest way to get things done, instead of listening to the other programmers. In other words, just find out what the code is supposed to actually do, rather than how it's supposed to do it.
    • by hcs_$reboot ( 1536101 ) on Monday August 15, 2016 @09:36PM (#52708629)
      Don't forget to include (C++) operator over-overloading.
      • by Dutch Gun ( 899105 ) on Monday August 15, 2016 @10:53PM (#52709011)

        It could definitely be an anti-pattern if used incorrectly, but honestly, I've been programming in C++ for about twenty years, and do you know how many times I've seen co-workers abuse operator overloading? Precisely ZERO. Seriously... never seen it. Apparently, I work with people who weren't stupid to flagrantly abuse operator overloading for no good reason, even among those who didn't exactly produce the cleanest or more elegant code.

        On the other hand, this is the type of code I typically work with:

        Vector3 posDelta = position - lastPosition;

        Or this:

        Matrix m = m1 * m2;

        Overloading operators is best done in an absolutely literal sense. For instance, if you're doing matrix multiplication or subtracting two positions to get a delta value, the intent and what's happening in the code is 100% clear to everyone.

        I chuckle sometimes at how C programmers believe that there's some evil overloaded operator lurking behind every multiply or addition. Uh, yeah... you can also obfuscate the crap out of your C programs too (pretty sure I've heard about some sort of contest too *cough*), but you just don't do that.

        • by Alomex ( 148003 ) on Monday August 15, 2016 @10:59PM (#52709037) Homepage

          Some of us are old enough to have gone through a generation of "overload everything" which was a disaster.

          Only much later did people learned to use overloading sparsely and with good effects.

          This is similar to OOP which is also overused. Heck in Java you can't even have a variable or a function living on its own. Everything must be an object (except native types, sometimes).

    • by Darinbob ( 1142669 ) on Monday August 15, 2016 @10:29PM (#52708907)

      Bad programmers are bad programmers no matter what language or paradigm they use.

      I think some of this arises from someone doing busy work and getting the feeling that they're making progress. Ie, create lots of classes, draw lots of lines between them, and it sort of looks like a design. Now you spend the next few months implementing the skeleton of all those classes, and then every time you go home it feels like you put in a good solid day at work, your boss looks at lines of code and you seem productive so you get a nice raise. If your fingers get sore from all that typing, then you just call a few meetings to start debating the merits of class naming, which patterns are missing that should be added, how to improve the whole process, and so on.

  • by Narcocide ( 102829 ) on Monday August 15, 2016 @08:05PM (#52708095) Homepage

    ... despite that I keep telling them not to, but never good enough to save their business plan or their company from disregarding my wisdom.

      - Agile/scrum, anything related to it, inspired by it, or even remotely like it, and the mindset of managers who advocate it.

      - "continuous integration"

      - "devops"

      - server-side javascript

      - giving every single person in the IT department the root server access

      - using microsoft "solutions"

    • by dgatwood ( 11270 )

      I agree with everything on your list except continuous integration. What makes CI a nightmare is that so many CI systems basically eat themselves from the inside out, randomly, causing everything to stop while somebody wastes half a day to debug the CI system. But when it works, CI is a godsend. It makes it easy to know exactly when things started to fail (tests, building, etc.), which makes it much easier to pin down the causes for some types of problems. (Obviously for building, this is trivial, but

  • Multiple Returns (Score:4, Insightful)

    by tomhath ( 637240 ) on Monday August 15, 2016 @08:08PM (#52708107)

    For a while the mantra was that you only return from a subroutine in one place, at the bottom.

    I think that's been pretty much abandoned. Return when you're done; don't go through contortions to get out of nested loops or IF statements just so you can get to the return at the bottom.

    • Re:Multiple Returns (Score:4, Interesting)

      by phantomfive ( 622387 ) on Monday August 15, 2016 @11:12PM (#52709097) Journal
      I stopped doing that one day when I looked at the disassembly of my function and realized the compiler was optimizing my code to have multiple returns.
      • What the compiler does truly doesn't matter. All those rules you are supposed to obey are only intended for correctness and clarity on source code level.

        Assembly only has one kind of flow control ("jump", i.e. goto), but that certainly does not imply that you should only use goto's everywhere from now on!

  • Javascript (Score:2, Insightful)

    by Anonymous Coward

    Javascript, the worst possible programming idea that seems to unfortunately work.

  • by pedantic bore ( 740196 ) on Monday August 15, 2016 @08:14PM (#52708149)
    Some people used Tcl because for a while, it was the only way to use Tk, and Tk was handy. But people who used Tcl for the sake of Tcl shouldn't be watched over, for their own good.
  • MUMPS (Score:4, Insightful)

    by mmell ( 832646 ) on Monday August 15, 2016 @08:17PM (#52708165)
    No, really - I'm not making this one up. MUMPS manages to find every possible bad coding idea and make it as easy as possible. Interpreted code, typeless data, naked array references, zero FS compatibility with anything . . .
  • by Frans Faase ( 648933 ) on Monday August 15, 2016 @08:28PM (#52708231) Homepage
    I once discovered that an interpretting parser was faster than a compiled version of it. Probably because the compiled version became so large that it was larger than the CPU caches, causing lots of reads from memory, while the interpretter did not. It is often the case that interpretting is fast enough and that there is no need for compiling (to machine code or virtual machine).
  • by BarneyGuarder ( 44042 ) on Monday August 15, 2016 @08:30PM (#52708243)

    Magic numbers save tons of time. You get to working code quickly to verify your algorithm. They nev

    >Segmentation Fault

  • Switch(true) (Score:5, Interesting)

    by omnichad ( 1198475 ) on Monday August 15, 2016 @08:48PM (#52708353) Homepage

    switch(true) {

          case $a < 5:

          do something;

          break;
    ...

    }

    A bit messy, but a lot cleaner than a stack of if/then/else for a set of of conditions.

  • Javascript (Score:4, Informative)

    by Snotnose ( 212196 ) on Monday August 15, 2016 @09:18PM (#52708519)
    In 40 years I've used dozens of languages, the only one I learned to actively hate was Javascript/ECMAscript. A pathetic, piss poor excuse for a language.

    I've heard PHP is just as bad but, as I've never written anything in PHP I'll give it the benefit of the doubt.
  • by cloud.pt ( 3412475 ) on Monday August 15, 2016 @09:23PM (#52708557)

    I've been dwelling the past months in my team's will to go full-fledged MVC (actually MVP) while developing for the Android SDK (for those out of topic: making apps). I see peers and myself struggling with old, large activities, running laps around to make them pass "technical debt" code reviews intending to "make them more future proof".

    It would be nice and all if I could grasp the benefits, but the problem is three-fold:

    a) the team is fooling themselves and the company into spending too much resources in something they can't assure adds value;

    b) Android already has a very solid MVP-like pattern going on, and MVP-ing it up further is a clear case of overengineering

    c) most important of all: there is no actual standard to guide the team, so it's a free for all and I see all the initial benefits down the drain just because everybody tastes a different flavour of the view/presenter combo

    And I see and underlying problem which might even be more crucial: the app will likely be dropped before reaping the long-term benefits, turning the entire endeavor TOTALLY WORTHLESS. So what I'm trying to say is: you got a solid framework with great patterns put in place already, developed by a company that is on the tech top 10, and you decide to be all trendy around it? You're pretty much grinding for a promotion you definitely don't deserve, because you're making that framework worse for everybody that you manage.

  • Objective-C (Score:4, Interesting)

    by hcs_$reboot ( 1536101 ) on Monday August 15, 2016 @09:39PM (#52708643)
    Objective-C and its weird syntax reached success within the iOS world
  • by buddyglass ( 925859 ) on Monday August 15, 2016 @11:32PM (#52709181)
    Was going to be sarcastic and answer "Ruby on Rails", but I'll go with "process per request" instead. That is, the Apache model, or for Rails the model where you keep a pool of instances that only handle one request at a time.

    Terrible in terms of scalability, but generally works for small workloads. Plus it largely sidesteps developers having to understand how to write thread-safe code.
  • PHP (Score:5, Interesting)

    by EmperorOfCanada ( 1332175 ) on Tuesday August 16, 2016 @12:32AM (#52709419)
    People crap on that language and, when I use it I usually violate MVC hard enough that it needs therapy. Yet, damn, I can pound out high quality products in that format like I am a programming firehose. I am talking products that make money and need little to no maintenance for years to come.

    I can do python flask stuff that is technically cleaner, I could even do something super hardcore like a C++ we back end but for the easy homerun, PHP it be.

    Obviously I am talking about the web.

    Another dirty secret is that I do most of my stuff from scratch. Nearly every framework or great IDE extra out there I ignore. The whole storyboards thing in iOS, nope, Java on Android, nope, or just about any proprietary system that tells me how I should do something is a big fat nope. I find with most huge frameworks that I can knock of an almost fully functional prototype in no time at all, but then I start fighting with the framework and can never finish, 90% done and that is it.

    By working with the fundamentals and good libraries, I start slow, and finish slow, but finish I do.
  • Duff's Device (Score:5, Interesting)

    by hmckee ( 10407 ) on Tuesday August 16, 2016 @03:49AM (#52710125)

    Seriously, the first time I saw Duff's Device [wikipedia.org] I really thought it was a mistake. It's a do/while intermingled with a case statement. Look it up and be amazed.

  • by gosand ( 234100 ) on Tuesday August 16, 2016 @09:21AM (#52711337)

    Back in the early 90s I worked at the big cellphone company. We worked on Unix workstations, and I learned a lot of what to do and what not to do. We used an in-house built bug system built to use sccs. I managed the build shell scripts. The only way to get code into the build was to enter a CR (Change Request) and link the source files to it. Then the build would examine all the CRs for a weekly build, check out that code, ftp it to the target platform (tandem), build it. If all went well, 8 hours later you would have a successful build, which I would then write to 9 track tapes, and THEN install it on the target system testing platform.

    So the bug system I mentioned used flat readable text files to store all the info. There was a gui front-end but it was kind of slow.

    Out of necessity to quickly look things up, I wrote a shell script that would allow you to search and view CRs on the command line. Bad built on top of bad, but it worked pretty well. Other people on my team started using it too.

    It worked so well in fact that somewhere around 2006 I was living across the country, having been at a few other companies since then. An old colleague still at my first company got in touch with me, and someone was asking about me and the tool I created. They saw my email in the header of the script, and wanted to get in touch with me to see if I would let them edit it. They were still using it! What I created for myself others found so useful that it was still chugging along doing its job on the command line. I don't know if it made me proud or sad, but it was humorous to me. I haven't heard anything from them since then, but it would be very interesting if they were still using that same process and those shell scripts I created so long ago.

Ernest asks Frank how long he has been working for the company. "Ever since they threatened to fire me."

Working...