Slashdot Mirror


How Mainstream Can Code Scavenging Go?

The time-honored tradition of code scavanging has long been a way for new programmers to "break in" to a new language or task that they may not want to build from the ground up. The re-use of old code, cleaned up and tweaked to a new purpose can help developers learn many useful skills and accomplish tasks quickly, especially for small tasks that aren't of vital importance. One blogger wondered if this process could be formalized and tools could be built to help foster and enable code scavanging on a mass level. Is this a viable option, or are there just too many things to consider?

139 comments

  1. IP Laws? by gambit3 · · Score: 3, Interesting

    So, how quickly would you run afoul of Intellectual Property laws doing this?

    1. Re:IP Laws? by thegrassyknowl · · Score: 2, Funny

      I want to be the first to welcome our new GPL overlord to the commercial software world.

      --
      I drink to make other people interesting!
    2. Re:IP Laws? by caffeinemessiah · · Score: 5, Insightful

      So, how quickly would you run afoul of Intellectual Property laws doing this?

      That's a great knee-jerk reaction. Without understanding the motivation behind the article, you assume that code scavenging means stealing other people's code. What they're really talking about is (legitimately) re-visiting code that you or other people have written, and then picking and modularizing bite-sized chunks. In other words, you would design a large program (mark I) and then go back and pick out useful parts, clean/debug them and have working modules (mark II) for the next project.

      Also, for people who haven't read TFA, it's 9 short paragraphs long and barely an article. They talk about a "formal approach to code scavenging" without even coming close to explaining what exactly that MEANS.

      --
      An old-timer with old-timey ideas.
    3. Re:IP Laws? by sootman · · Score: 5, Interesting
      They talk about a "formal approach to code scavenging" without even coming close to explaining what exactly that MEANS.

      Agreed. Reading TFS, I thought it was going to be yet another "we can make programming like Lego!" thing. (Which it ain't, and probably never will be. Bonus reference: "Lego" is mentioned in the second paragraph of this article about Steve Jobs/NeXT/WebObjects from Wired. God bless Wired and their eternally fucked-up CMS that can't serve images for any story in the archive and, this week, shows the actual HTML code that should be formatting the Question-and-Answer portion of the article.)

      Reading TFA, I really don't know much more than I did before. This is the best I could come up with:

      Code scavenging is seen as the most frequent and least complex way of re-using code and has been common practice at an informal level since programming first began. Programming is difficult to teach and most programmers learn their chops by looking at working code and using it as the basis for building their own programs. In other words, they "scavenge" the good bits and tweak them to a new purpose.

      The term scavenging appears to have first surfaced as a formal concept in a 1992 paper by Charles Krueger of Carnegie Mellon University. It was tested by academics in the 1990s but rejected because it yielded few gains for a lot of effort.

      According to Hackett, code scavenging is worth re-visiting because the Web makes it easier to find code and re-use it. He points to sites where massive amounts of existing code are available for potential scavenging such as Google code search, Sourceforge, Code Project, Microsoft's Codeplex, and O'Reilly's Code Search. Others include the Free Software Foundation (FSF), FreeVBcode.com, Freecountry and Freshmeat.

      So, code scavenging is... um, re-use? Can anyone make better sense of that than I can?

      "In other words, they 'scavenge' the good bits and tweak them to a new purpose."

      Um, no. You scavenge the pieces you need, not necessarily the good bits. Have you ever been looking for some code to do parse phone numbers, and while looking at source, said "Hey! This looks like a great way to compare two lists!" Probably not. You're only looking for formatting code, so that's all you see, so that's all you get. Looking at source is not like looking at produce at the food store, where you can walk by the tomatoes and they catch your eye because they're perfectly ripe and really, really nice-looking.

      Rather than searching Google, I think every good programmer should take the time to create a really good library. I don't mean take the time writing great code, I mean take the time to organize it into a proper library: make one, clean, well-commented version; put things into variables, ($tableName in queries instead of the actual table name, etc.) and pull code from that when you need it, rather than just copying-and-pasting from the last place you remember using it and then changing all the variable names, table names, etc.

      I plan to make mine Real Soon Now. :-)

      >> So, how quickly would you run afoul of Intellectual Property laws doing this?

      > That's a great knee-jerk reaction.


      No, that's just the first thing that popped into his head. (Pardon me if I'm putting words in your mouth, Mr. Gambit.) With that one sentence, he did not say (or imply) "The only people who would use this are thieves." He just put out that question for people to discuss. That topic came up here just a couple days ago. I highly recommend reading that discussion. There are some very good points; among them, that if you publish something with no licensing info, it is copyrighted to you by default. (In the US at least,

      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    4. Re:IP Laws? by ILuvRamen · · Score: 1

      in the case of visual basic for example, Microsoft made almost all the functions and objects used so you can't do some little code snippet using them and say somehow now you own it. That's like a company making cars and they sell one to you and you patent demolition derbies because you discovered a new thing to do with their tools. Now big, long programs or large, specialized modules that would have the same structure in any language and actually represent some logical idea that someone created are a different story. But if I go to vbforums.com and ask a good way to do something and someone shows me 20 lines for it and I use it, nobody should be complaining about me stealing someone's code. Yet, if I steal a DLL and use it for myself so I don't have to write any of it, that's different.
      Now that that's established, to answer the final question posed on the summary, it's caleld the MSDN library and it failed miserably. Its main purpose isn't this, but it does in fact strive to have a realistic example of how every function and object would be used...and it's gigabytes of un-navigateable garbage that doesn't tell you anything 95% of the time.

      --
      Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
    5. Re:IP Laws? by RobBebop · · Score: 1

      Some code cannot be copyrighted. HTML, for instance, cannot be locked away and hidden in a vault because it relies on being there so the browser can render it at the time of the download. Those, HTML is a great "scavenger" language, because it is easy to learn new techniques by poking around the "View Source" code.

      Other code that cannot be copyrighted is copylefted. The GPL expressly guarantees that code can be used, studied, modified, and redistributed.

      Now... formalizing a lesson plan to teach students of computer science the ins-and-outs of GPL code would be a wonderful thing. I would graciously sign up for that course.

      --
      Support the 30 Hour Work Week!!!
    6. Re:IP Laws? by tuomoks · · Score: 1

      A good comment! And the IP part is important, you just can't take any code you see, you can read it and code the solution yourself in most cases but there are some darn patent issues - stupid laws patenting algorithms !
      Another good point in comment "every good programmer should take the time to create a really good library" And this should go without saying, build your own library of templates and snippets you carry as long as you do coding, often saves a lot of time. Some companies which use SM/CM ( source/configuration management ) have ready made / canned templates, snippets, etc already bound to editors, IDEs, and so on. Unfortunately very few.
      Just don't get too hooked to those, some day you are in environment where the only tools are notepad or vi and a compiler, how to start now? And usually in those systems all the help files, man pages, etc are nonexistent.
      Also, be careful, code may be written to specific platform, OS, compiler, etc. I'm tired of fixing for example code written to PPC when compiling for x86 or 32 bit code going to 64. Did you think all systems have bytes in same order? Did you think all compilers and systems align same way? Did you think that all systems let you manipulate the stack? Did you think they are on same POSIX level? Did you think that objects with same names are equal? Well, you were wrong. Especially some Unix developers with fast cut and paste fingers have created millions of lines such code ( just my experience, sorry )
      Another ( one of many ) issue, did the original code writer think security? Ouch - all the string functions, etc. Yes, even if the code comes from experienced developers and (currently) well behaving systems does not guarantee that it will work for you.
      All that said, old code is a great source to learn especially if you are new and you have someone to explain it.

    7. Re:IP Laws? by iminplaya · · Score: 1

      ...stealing other people's code.

      Another great knee-jerk reaction. Since a revealed idea cannot rightfully be "owned" or controlled in any way by anyone. "Stealing" is a misnomer designed to incite more knee-jerk reactions to keep bad law on the books. Unfortunately it still works on a gullible public.

      --
      What?
    8. Re:IP Laws? by cromar · · Score: 1

      I, for one, .... always check the licence of snippets I use :)

    9. Re:IP Laws? by cromar · · Score: 1

      Dude... your example of derby demolition is a really good one. That appeals to a lot of people because everyone knows what it is. (A good car analogy on Slashdot?!!) WWE! :) (And I honestly mean that with all sincerity!)

      P.S. MSDN docs do often suck... luckily their IDE and Google results are OK.

      P.P.S. A fi bun mi sensi.

    10. Re:IP Laws? by d34thm0nk3y · · Score: 1

      What they're really talking about is (legitimately) re-visiting code that you or other people have written, and then picking and modularizing bite-sized chunks. In other words, you would design a large program (mark I) and then go back and pick out useful parts, clean/debug them and have working modules (mark II) for the next project.

      Exactly! You can visualize these modular chunks of code as actual objects actually. Each object could have a series of methods that you could manipulate to make it do things. I call this theory manipulation orientated programming (or MOP) and am filing for the patent presently. Prepare to hear from my laywer.

    11. Re:IP Laws? by Dogtanian · · Score: 1

      Some code cannot be copyrighted. HTML, for instance, cannot be locked away and hidden in a vault because it relies on being there so the browser can render it at the time of the download. Just because you can easily view it doesn't mean that it's not copyrighted. What on earth made you think otherwise?!

      Realistically, of course, there's the question of how far you can copyright many (small) HTML fragments and techniques anyway, but that's not the point you were making.
      --
      "Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
    12. Re:IP Laws? by ozone_sniffer · · Score: 1

      If that large program (mark I) wasn't built on top of a library (or somethin'), which in turn was designed for reuse, you'll get in trouble trying to reuse that code. Either: 1. You refactor the large program to reach that structure, or; 2. You start the new one from scratch. Scavenging is scavenging, be it code or corpses, and is a lowly thing to do no matter what. You want tools for that? Go grab some cutlasses and shovels, they've been around for quite some time.

    13. Re:IP Laws? by mollymoo · · Score: 1

      So, how quickly would you run afoul of Intellectual Property laws doing this?

      You're highly unlikely to run afoul of trademark laws and absolutely guaranteed to run afoul of patent law in the US, or virtually guaranteed not run afoul of patent law elsewhere. So you must have meant copyright. Why didn't you just say copyright? Lumping copyrights, patents and trademarks together is futile for most purposes and calling them "property" is dangerously misleading.

      --
      Chernobyl 'not a wildlife haven' - BBC News
    14. Re:IP Laws? by alex4u2nv · · Score: 3, Insightful

      These are the ideas that CPAN, PEAR and other code repositories are built on. So instead of trying to reinvent the idea, the author should have poked around a little more, and to learn more about what is available as opposed to trying formalize a "hackup job."

      The parent makes a good point here, where you should take the time to build a clean library base to work with. If one should have a well structured infrastructure, and should they need to implement a certain feature, more often is the case, that a generic library to facilitate the need already exists. If it's open source you're in luck, if it's commercial, you could license it. For example, take a peak into the game industry. A lot of those engines libraries are licensed out to many companies.

      Now I will assume 'bits and pieces' is nothing more than 1 class, or a function. So, If one should be looking for bits and pieces of codes, as a developer you should be able to develop at least that much.

      "Hackett makes some good points, but can scavenging for scraps really turn you into a master programmer, and is it possible - or even desirable - to institutionalize this "make-do" approach?...," TFA

      The short answer is No.
      This sort of programming will not make you a master programmer, it will make you a master scavenger.

    15. Re:IP Laws? by CRCulver · · Score: 1

      HTML, for instance, cannot be locked away and hidden in a vault because it relies on being there so the browser can render it at the time of the download.

      CSS style sheets also downloaded for the browser to render, and yet some of the best CSS designs out there are copyright.

    16. Re:IP Laws? by ILuvRamen · · Score: 1

      :-O I assumed all geeks love smashing cars! Why the heck wouldn't we?! I sure do!!! Although looking around me in the bleachers at a demolition derby kinda makes me think it's more of a hick/redneck thing lol. Still fun though.

      --
      Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
    17. Re:IP Laws? by jc42 · · Score: 2, Funny

      [I]f you publish something with no licensing info, it is copyrighted to you by default. (In the US at least, and many other countries as well.) So even if you're looking at a site that is, say, clearly marked as a tutorial, that doesn't necessarily mean that you can use that code, unless the guy comes out and says the code is public domain/GPL/etc.

      Good point. I think I'll use it the next time someone comments about code of mine that is overly complex and convoluted.

      "You see, all the simple ways of doing it have been published in tutorials. This means that they're copyrighted by the author. If I used simple code, I'd almost certainly be violating some author's copyright, and since you hired me to write the code, they'd probably sue both of us. Wouldn't want that, would we?"

      (Only half-joking here. This is what the world's coming to. ;-)

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    18. Re:IP Laws? by CptPicard · · Score: 1

      They talk about a "formal approach to code scavenging" without even coming close to explaining what exactly that MEANS.

      It's just another made-up specialization field for software engineering academics who didn't quite cut it in the real compsci stuff... even they need to write their papers on something.

      --
      I want to play Free Market with a drowning Libertarian.
  2. I've been thinking of scavenging code from SCO... by kclittle · · Score: 4, Funny

    ...since they obviously aren't going to be using it for much longer...

    --
    Generally, bash is superior to python in those environments where python is not installed.
  3. Vernor Vinge by boster · · Score: 4, Interesting

    In A Deepness in the Sky, Vernor Vinge posited Programmer Archaeologists would replace all new development. http://everything2.com/index.pl?node_id=760521

    --
    Madness takes its toll. Exact change please.
    1. Re:Vernor Vinge by Penguinisto · · Score: 1
      Not like it took deep thought to arrive at that conclusion - a look at the nearest sysadmin (myself just as guilty) and the wee habit of script-scavenging is sufficient to serve as a parallel.

      /P

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    2. Re:Vernor Vinge by bcharr2 · · Score: 5, Insightful

      Code is basically an algorithm that solves a computational problem. So yes, you can cut and paste algorithms. If you want your application to be maintainable, however, you also have to solve the larger architectural problems, which is something you DON'T get when you cut and paste code.

      It is one of the most misunderstood concepts about programming. A programmer fresh out of college knows how to write algorithms really well, but has no idea that there are architectural and design land mines waiting for them just down the development road.

      Too many development shops will get an app "working" and think that is all there is to development, because no one has the depth of experience to look a year down the road and see that they will need to rewrite the entire app from scratch in order to make the simplest of changes.

      I'm sorry, but if your program is not extensible nor maintainable then you really haven't "succeeded" at anything. You've simply fooled yourself into thinking the process is simpler than it is while screwing your clients out of their development dollars.

    3. Re:Vernor Vinge by d34thm0nk3y · · Score: 1

      In A Deepness in the Sky, Vernor Vinge posited Programmer Archaeologists would replace all new development. http://everything2.com/index.pl?node_id=760521

      Thanks, I already know Python.

    4. Re:Vernor Vinge by mochan_s · · Score: 1

      It is one of the most misunderstood concepts about programming. A programmer fresh out of college knows how to write algorithms really well, but has no idea that there are architectural and design land mines waiting for them just down the development road.

      I think you're wrong here.

      In college, a lot of architectural designs have to be made and made quick. OK, they are for small projects but still those designs have to be made. Plus, you have the luxury of seeing what other people designed and how it worked out.

      The method of assigning homework is to give 3 lines on what a program needs to do. For example, write an FTP client that you can use to download a file. The method of grading is if you can download a file or not. The decision on how to get the HW done with the least amount of time spent is an architectural challenge.

      Too many development shops will get an app "working" and think that is all there is to development, because no one has the depth of experience to look a year down the road and see that they will need to rewrite the entire app from scratch in order to make the simplest of changes.

      Even firefox and Mozilla did a few complete rewrites of the various parts. Rewrites are part of programming unfortunately. The nice thing about rewrites is that the programmers now have experience on how to do things better and are able to better compartmentalize the code. I wouldn't say rewrites are terrible things - though they do annoy management and people above to no end.

    5. Re:Vernor Vinge by Alphager · · Score: 2, Insightful

      The method of assigning homework is to give 3 lines on what a program needs to do. For example, write an FTP client that you can use to download a file. The method of grading is if you can download a file or not. The decision on how to get the HW done with the least amount of time spent is an architectural challenge.

      Which is what the parent hates: people who only think about getting the product out of the door and who sacrifice things like maintainability.

      Even firefox and Mozilla did a few complete rewrites of the various parts. Rewrites are part of programming unfortunately. The nice thing about rewrites is that the programmers now have experience on how to do things better and are able to better compartmentalize the code. I wouldn't say rewrites are terrible things - though they do annoy management and people above to no end.

      Firefox & Mozilla are prime examples of bad codebases. We all know the disaster that was the last rewrite in-house at Netscape.
      _SOME_ re-writes are necesary and usefull, but a company where the usual way to add a new feature is a re-write of the whole software is doing somethign wrong.
    6. Re:Vernor Vinge by obarel · · Score: 1

      I've heard the sentence "if we don't finish this by the end of the week, they are going to look for another provider" more times than I wanted to, but that's life.

      I wish I had the luxury to spend a week to estimate how long it'll take to design, then two months to design and then a year to implement. Unfortunately, I get two minutes to say how long it'll take to implement, and then work to impossible deadlines where every (inevitable) extension is seen as a failure, and sometimes *is* a failure (i.e. the customers simply refuse to pay for any extra work etc.)

      That's the sad reality, and I certainly hope they don't build cars/houses/machines/anything this way. But sometimes it's not important whether the code will be maintainable in a year's time, when it's not going to be used if it's not ready tomorrow (in whatever shape it is).

      Contrary to what most books claim as the single possible truth, the programmer's time is not always the most expensive part of production - sometimes the software has to be put on 4,000,000 devices and manufacturing starts in two weeks. Missing the deadline costs more than the extra two weeks it'll take a programmer to make a change in a year's time - it could even mean that there won't be any code (nor programmer) in a year's time.

    7. Re:Vernor Vinge by rjames13 · · Score: 1

      In A Deepness in the Sky, Vernor Vinge posited Programmer Archaeologists would replace all new development.

      Are you sure he said that, I read that book again quite recently and I don't remember any such proclamation. What chapter is it from?

  4. code repositories by drfrog · · Score: 2, Informative

    like cpan and ruby gems etc

    we scavenge code online w/e, find it needs to be used by a lot of people

    so we inherit the scavenged and put it in a nice module and tada!

    this is nothing new

    --
    back in the day we didnt have no old school
  5. Don't we call that "refactoring"? by khasim · · Score: 1

    You write program A ... eventually you refactor it and turn parts of it into cleaner modules.

    You can then use those modules in other programs.

    1. Re:Don't we call that "refactoring"? by caffeinemessiah · · Score: 1

      You write program A ... eventually you refactor it and turn parts of it into cleaner modules. You can then use those modules in other programs.

      short answer: yes. and even before "refactoring" came into vogue, there were other names for it. hence, TFA is not really a FA.

      --
      An old-timer with old-timey ideas.
    2. Re:Don't we call that "refactoring"? by Anonymous Coward · · Score: 1, Interesting

      well it's not that bad an idea. In my job I often have to come up with one-off shell scripts and whatnot. I have thought many times "this must have been done before, why am I doing it again"? The problem I have is, where does one look?

      I google and look through various scripts and stuff on linux boxes and can piece stuff together but by the time I do that I might as well have just written it. Often times I do after giving up. To have a place to pick through, even just for ideas, is not a bad thing at all. For the record I am an admin but not a programmer.

    3. Re:Don't we call that "refactoring"? by Anonymous Coward · · Score: 5, Funny

      TFA is not really a FA.


      It leaves us only "the". Which is an article. Liar.
    4. Re:Don't we call that "refactoring"? by The+One+and+Only · · Score: 1

      But not a fucking article.

      --
      In Repressive Burma, it's not just your connection that dies. slashdot.org/comments.pl?sid=314547&cid=20819199
  6. semi-formalized by mycall · · Score: 5, Informative

    Some people are already doing this, such as koders, code fetch, codase, and snippets. Talk to them for formalizing as I'm sure they have some good input.

    1. Re:semi-formalized by Peter+Cooper · · Score: 1

      One of the good things about Snippets in particular is the taggability.. kinda like searching for stuff in del.icio.us. So.. I can just kinda guess some URLs and know I'll get something relevant (I hope!)

      http://snippets.dzone.com/tags/ruby
      http://snippets.dzone.com/tags/ruby/http
      http://snippets.dzone.com/tags/python/windows
      http://snippets.dzone.com/tags/rebol

      And so on..

  7. It's called a "subroutine library" by Animats · · Score: 4, Funny

    The Web 2.0 crowd rediscovers subroutine libraries. Film at 11.

    1. Re:It's called a "subroutine library" by calebt3 · · Score: 1

      I don't even know how too code and I was thinking "library".
      And to preempt those that like to pun: I mean the "DLL" kind. Not the "lots-o-books" kind.

    2. Re:It's called a "subroutine library" by visualight · · Score: 2, Funny

      The poster you replied to is thinking the "lots-o-books" kind (I'm sure). As in, "a library of subroutines".

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    3. Re:It's called a "subroutine library" by Anonymous Coward · · Score: 1, Insightful

      Seriously though: welcome to CPAN.

    4. Re:It's called a "subroutine library" by Tablizer · · Score: 2, Funny

      The Web 2.0 crowd rediscovers subroutine libraries. Film at 11.

      You gotta punch it up, PHB-ify it: "Reusable Enabling Action-Oriented Web Object Architecture Patterns".

    5. Re:It's called a "subroutine library" by Tablizer · · Score: 1

      Seriously though: welcome to CPAN.

      When I was an intern for the US Geological Survey in the late 80's, they had pretty big FORTRAN libraries for graphing, charting, mapping, reporting, math, you name it. Being before open-source took off, they were expensive though.

    6. Re:It's called a "subroutine library" by Comatose51 · · Score: 2, Funny
      You joke but I've phone interviewed someone and asked him, "What are some ways of reusing code or implementation?" Inheritance or composition would have been okay. In fact, a lot of answers are acceptable.

      Instead, he answered "uh... cut and paste?"

      --
      EvilCON - Made Famous by /.
    7. Re:It's called a "subroutine library" by j_l_cgull · · Score: 1

      The Web 2.0 crowd rediscovers subroutine libraries. Film at 11.


      Wasn't that WebServices and XML ?!
    8. Re:It's called a "subroutine library" by joss · · Score: 1

      I don't think of inheritance and composition as *reusing* code,
      thats more just *using* it afaiac so I guess I would have been
      stumped by that question too. Lisp can double as knitting patterns
      and I guess perl can be a decent approximation to line noise, python
      can sometimes be read as intensely obscure haikus but its all a bit
      of a stretch.

      --
      http://rareformnewmedia.com/
    9. Re:It's called a "subroutine library" by Anonymous Coward · · Score: 0

      I'm not very old, but in the old days ... 1990, we used to pay other companies for reusable code. They called them "Libraries" and came with unlimited redistribution of runtime licenses for no additional charge. Of course, it was easier then because any serious development team only shipped object code (.o, .a, .so, .dll) files with interface files (.h) - you know, header files? http://snippets.snippets.org/index.php

      Script-based languages make this just slightly less useful ... to the library vendor. OTOH, I had to use fidonet to find a copy of the C/C++ snippets all those years ago. The internet/google made that a trivial exercise this morning. Perl code has this. It is called a module - http://search.cpan.org/
          I suspect Java, PHP, Python, Ruby all have repositories of reusable code too. Google is your friend, but check the license and be certain your project/company can live with whatever restriction the author chose to use. Generally, I use the v2 LGPL for non-work stuff, myself. For non-core work stuff, BSD license is preferred provided the company doesn't keep it all as a "trade secret". I don't have problems with trade secrets, where they make sense. Company owners tend to want to protect everything for some reason.

    10. Re:It's called a "subroutine library" by rah1420 · · Score: 1

      I would have hired him. These young whippersnapper programmers thinking that they are all that. What's wrong with 3GLs anyway?

      At the end of the day, it's all ones and zeros.

      --
      Mit der Dummheit kämpfen Götter selbst vergebens.
  8. Google Code by TooMuchToDo · · Score: 2, Informative
    1. Re:Google Code by daveb · · Score: 4, Informative

      for code scavenging try this instead / as-well
      http://www.google.com/codesearch

    2. Re:Google Code by skeftomai · · Score: 1

      That's pretty freakin awesome. Didn't know that existed; thanks for sharing.

  9. foreheat meet desk by Yath · · Score: 4, Funny

    I guess this is slow news day. Using bits of code without writing everything from scratch - how novel! How controversial! Is there anyone who doesn't do this? What kind of skull-shattering boredom do you have to endure before you start writing blog entries about this?

    And the first article suggests that trusting the code is an issue, because you didn't write it. Well let's see - it's short, and you just pasted it into your program. But you're not going to bother to read it? You fail. Seriously.

    --
    I always mod up spelling trolls.
    1. Re:foreheat meet desk by jgrahn · · Score: 1

      I guess this is slow news day. Using bits of code without writing everything from scratch - how novel! How controversial! Is there anyone who doesn't do this? What kind of skull-shattering boredom do you have to endure before you start writing blog entries about this?

      It might be a new idea for more people than you think. There is this ideal picture of people writing The Perfect Software from scratch, isolated from the rest of the world. And there is the other ideal, people assembling The Perfect Software from various Java frameworks with catchy names.

      It is a good thing that somebody points out that it is OK to just cut-and-paste code; that you don't have to make it a bloody library with the perfect API first.

    2. Re:foreheat meet desk by GunFodder · · Score: 1

      You said it. I think they have a name for reusing existing code, it's called "Software Engineering."

    3. Re:foreheat meet desk by Splab · · Score: 1

      Is it really?

      Don't know about you, but I don't have the legal background to figure out what happens to licenses for the code when you copy and paste others code into your project.

  10. NIH is healthy. by Anonymous Coward · · Score: 0

    Code reuse has been tried but cowboy programmers and the NIH syndrome strike every time. Besides algorithm reuse would be a better path to take.

    1. Re:NIH is healthy. by Alpha830RulZ · · Score: 1

      It's certainly healthy for job security, but it ought to be a firing offense. There is a group in my company right now who is literally rewriting a working system from scratch, even though we have working, debugged, solid code that does exactly what they need it to do, because it comes from outside their group. "Would you guys like some code that does that?" "Nope, we write our own." "Why?" "Because." "Would you like to see the requirements docs we used?" "Nope, we'll write our own." "Why?" "..."
      A production system is being delayed for three months while they do this.

      Sheesh.

      --
      I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
  11. Isn't this a library? by poppycock · · Score: 3, Funny

    Isn't this, you know, a library?

  12. "Scavanging"? by Anonymous Coward · · Score: 2, Funny

    Why don't you scavenge the dictionary to spell properly?

  13. Unlikely? by SnoopJeDi · · Score: 3, Interesting
    From TFA:

    You are unlikely to find what you want with a simple Web search


    Since..when? Recently I've picked up perl again, and I've found more than what I need to scavenge to make my own personal extensions to blosxom through google searches.

    I mean, granted, it depends on your definition of a bite-size task, but it's a blanket statement no matter which way you spin it.
  14. Eh? by Angst+Badger · · Score: 1

    Isn't that basically the point of a linkable library?

    --
    Proud member of the Weirdo-American community.
  15. This is a great idea! by AEton · · Score: 3, Funny

    If only there were some computer programming language that had built-in support for some kind of a Comprehensive Archive Network, that would be the best.

    Maybe the C++ language could do it. Then you could just ... hmm ... "import" the things you need from the Comprehensive C++ Archive Network!

    Hmm, CC++AN sounds pretty dumb. It'd never catch on. Oh well.

    --
    We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
    1. Re:This is a great idea! by Penguinisto · · Score: 1

      Hmm, CC++AN sounds pretty dumb. It'd never catch on. Oh well.

      Oh, c'mon! It has one potential use - It sounds like a munged pr0n version of something for Perl. That alone would make the effort worth it, no?

      /P

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    2. Re:This is a great idea! by CTalkobt · · Score: 1

      >> Hmm, CC++AN sounds pretty dumb. It'd never catch on. Oh well.

      Or alternativly, you could call it CCPPAN... but that sounds too much like the perl CPAN besides the fact that you'd have turret's jokes about it....

      --
      There's a gorilla from Manilla whose a fella that stinks of vanilla and has salmonella.
  16. Today Slashdot jumped the shark. by xxxJonBoyxxx · · Score: 2, Funny

    Today Slashdot jumped the shark.

    Seriously. I'm starting to lose brain cells when I read the "articles" these days.

    1. Re:Today Slashdot jumped the shark. by thatskinnyguy · · Score: 1

      Really... I mean really... I would have honestly expected less "duh" out of a kdawson article.

      --
      The game.
    2. Re:Today Slashdot jumped the shark. by Anonymous Coward · · Score: 0

      No no no, you know your loosing your brain cells when you can't tell the difference between loose and lose.

    3. Re:Today Slashdot jumped the shark. by Tablizer · · Score: 1

      Today Slashdot jumped the shark. Seriously. I'm starting to lose brain cells when I read the "articles" these days.

      Ahah! Caught you reusing cliches.

    4. Re:Today Slashdot jumped the shark. by Rocketship+Underpant · · Score: 1

      A more interesting story might be how Slashdot "scavenges" yesterday's stories for reposting tomorrow!

      --
      He who lights his taper at mine, receives light without darkening me.
    5. Re:Today Slashdot jumped the shark. by jo42 · · Score: 1

      Stay away from Digg - there you lose your brain.

    6. Re:Today Slashdot jumped the shark. by hmccabe · · Score: 1

      Maybe they'll just start somestonersblog.slashdot.org and we can opt out of those stories.

  17. Re:scavanging turds is mainstream by YrWrstNtmr · · Score: 4, Funny

    That sir, was a work of beauty. There should moderation other than -1 Troll for such art.

    Indeed...we need a -5 Asshole.

  18. It's already been done. by etnu · · Score: 2, Funny

    It's called Google.

    1. Re:It's already been done. by Penguinisto · · Score: 1
      And CPAN.

      (and half a bazillion other projects... Hell, not it's been going on before Microsoft decided they needed a working TCP/IP stack for Windows 2000 or anything...)

      /P

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
  19. A Brand New Idea by Anonymous Coward · · Score: 1, Funny

    What a great new idea! Maybe we could put all of the scavenged code into a container and call it a "library". Wiyth brilliant ideas like this software is going to advance by great leaps and bounds. No more reinventing the wheel, or constantly rediscovering ancient ideas.

  20. Wow by smitth1276 · · Score: 5, Funny

    That article used a lot of words to say absolutely nothing. But it got me thinking... perhaps we could group related snippets of code into units called "libraries", and then we could easily use those libraries to perform common tasks?

    1. Re:Wow by libkarl2 · · Score: 1

      Uh, no. We've shifted our focus towards a synergistic paradigmatic model better suited for the theoretical quasi-user experience. I have no idea what that means but the CEO loves it.

      --
      You are where you are at the time you are there.
  21. Good and Bad by Anonymous Coward · · Score: 0

    It's smart to not have to reinvent the wheel unless you're going to do it better. On the other hand, if you just acquire the wheel, you might not actually understand the wheel. The last thing we need is more sloppy coding nevermind the speed it's produced at.

  22. Ah, business versus pleasure by holophrastic · · Score: 1

    It's a funny game, using plucked code. I do agree that when it comes to learning a new language, or learning to program for the first-ish time, nothing's better than stitching together mounds of existing code and watching things emerge.

    When it comes to real business requirements, things are a little milky. I own and operate a small business, and there are a few problems with plucking code from the ether. The first is the notion of hiring a programmer to not write their own code. Getting the job done, and doing the job are two very different things. It pretty much hinges on a very simple notion.

    I love CPAN, I think it's the greatest resource out there. When I'm looking for a Perl module to do something that I can't do myself, that's where I go, and I've never been disappointed. But I go there expecting a solution that does what it says it'll do. I use it the way it says it wants me to use it. And that's all that I ever expect of it. FTP, PDF, english numbers, whatever.

    A while back, I asked one of my programmers to write a routine to dump out a Perl structure. I said I needed it in about a week. Lo and behold, it worked on-time and all was good.

    A few months later, I noticed that it wasn't quite working the way that I had wanted it to. I needed a tiny thing adjusted. So I went to my programmer, and told him to make the change. I was greeted with the lovely response of "it can't do that like that". I of course was perplexed. I'm not asking it to do anything. I'm asking my programmer to do something on the clock.

    Turns out, as any Perl expert here knows, my programmer simply took the Dump module, which dumps perl structures. I wanted to have the dump be a nice dynamic javascript html table thing, and my programmer told me no -- or rather that it would require him to do it from scratch, and of course now, a month later, we didn't have the time.

    Ultimately, my point is that when you control every line of code, you aren't hampered by other people's restrictions. I would have been happy had my programmer written his own dumping code from scratch, but I also would have been happy had he started with the cpan dump code, searned from it, and created a derivative version. Hell, in this case, I'd have been happy if he had studied it to the point where he could have modified it easily.

    Instead, I got a quick-'n'-dirty solution that prioritizes time over other benefits. Trouble is, in this case, we had extra time, and no extra benefits.

    1. Re:Ah, business versus pleasure by einhverfr · · Score: 1

      A while back, I asked one of my programmers to write a routine to dump out a Perl structure. I said I needed it in about a week. Lo and behold, it worked on-time and all was good. What is wrong with Data::Dumper? Or rather did you need something that worked with Data::Dumper?

      Turns out, as any Perl expert here knows, my programmer simply took the Dump module, which dumps perl structures. I wanted to have the dump be a nice dynamic javascript html table thing, and my programmer told me no -- or rather that it would require him to do it from scratch, and of course now, a month later, we didn't have the time. Having done a lot of work with Perl, I would say that Data::Dumper is the wrong thing to use for that. TemplateToolkit, OTOH, would allow you to quite quickly generate HTML based on your data structure. A competent Perl programmer shouldn't require too much time to do that, esp. if it is in a different document.
      --

      LedgerSMB: Open source Accounting/ERP
    2. Re:Ah, business versus pleasure by usrcpp · · Score: 1

      How do you not control every line of code when you reuse? Unless you're a code monkey, you'll most probably know how to write something, but just 1) not want to spend 20 minutes thinking about it when you get get it from somewhere in two, or 2) You're getting to grips with the language and so syntax is a bit of an issue. I think the point should really be that code monkeys shouldn't be trusted with writing critical components for the reason you pointed out.

    3. Re:Ah, business versus pleasure by holophrastic · · Score: 1

      So when I want to output a nested/recusive HTML table to show a perl structure of nested arrays and hashes, you'd recommend a 3 meg module? Kind of over-kill don't you think? Would you recommend a faster webserver to go with it?

      We're talking about a couple-dozen lines of perl code to do this -- I got to prove it, it wasn't difficult. It's not hard to traverse perl structures. foreach and each and ref make things pretty darn simple.

    4. Re:Ah, business versus pleasure by einhverfr · · Score: 1

      Ok, we use TT for LSMB pretty extensively in 1.3. Yes, there are some potential issues performance-wise, but those are actually ram-scarcity issues. BTW, LedgerSMB has portions which are very latency-sensitive (cash register support, for example) and we do everything we can to make those fly speed-wise. Generally speaking, however, in our case it is db access which is the bottleneck. We use it to generate HTML, LaTeX, CSV, Excel, and OpenDocument files.

      Part of the problem is that you are going to pay in performance for flexibility. Next time someone says "oh, we just want one simple modification-- can you output in Excel?" you can do that and it will be simple. Otherwise it will be a headache.

      The point is that you should have known and should have been informed this was web-based from the start, and if you didn't it is either you or your customer who is at fault here. Not your programmer. You can't blame developers for not building in requirements that were not given to them.

      --

      LedgerSMB: Open source Accounting/ERP
    5. Re:Ah, business versus pleasure by holophrastic · · Score: 1

      Ah, but I can. Because the developer was hired with the very direct understanding that the client will turn things upside down at least three times before it's done. The four-part code interview explained that quite well. Whether or not it was believed, is another matter.

      My question to you, as one who uses LSMB with the limitations that you've listed above, is very simple. I refuse, and prohibit my developers from using third-party modules for integrated features. Obviously, LWP, DBI, ImageMagick, something PDF, and other extensions of the core don't count. I'm talking about integrated business features because that's my industry. If my industry were database management, then I wouldn't let them use DBI either. But in my world, database performance is not something on which I need a strangle-hold.

      My question is, when you reach something that LSMB can't do -- perhaps your cash register example is one -- what do you tell your clients? Do you say something to the effect of "sorry, that's not possible" or "we'll have to rebuild everything from scratch"? or do you say something like "it can't be done properly, but we can bolt-on this work-around"?

      You see, neither of those is reasonable in my industry. My clients shift their business model and actually wrap their business around my product. Their business grows as you would expect any business with no software and no web-site to do upon getting one of either. I can't then say that they have to stop basing tehir business on my product, or that my product can't grow with their business -- that's exactly what I sold to them in the first place.

      Now, I can say that it was built to handle 1'000 customers, and not 1'000'000 customers. But I can't refuse the 1'001st customer. And I can't tell them that a relatively small feature can't be added -- and small in this case means small to their business, not small to my code.

      So my answer has to be, quite simply, "no problem, I'll just re-write LSMB to handle that properly". That's really easy if I'm the one who wrote LSMB. Hence, I write my own platforms, so that I can say I know every one of the 800'000 lines of code, and I can add, remove, or adjust absolutely anything within the parameters of their business objectives.

      My developers are supposed to understand that. It may be CSV today, TAB tomorrow, adn some magical EDI format the next day. One of those magic formats may be HTML. But none of that is the main function of the routine -- or the main routine of the function. That's part of separating form from function, content from layout, layout from code, and code from content -- even if it's all in the same block of code.

      But I've been doing this for a long while, and I've become pretty adept at seeing the future (from my clients' perspective). I just need my developers to believe me when I say that writing their own code is going to be better when they need to change it. "it's impossible" can't ever be the answer that I give to my clients.

    6. Re:Ah, business versus pleasure by einhverfr · · Score: 1

      My question to you, as one who uses LSMB with the limitations that you've listed above, is very simple. I refuse, and prohibit my developers from using third-party modules for integrated features. Obviously, LWP, DBI, ImageMagick, something PDF, and other extensions of the core don't count. I'm talking about integrated business features because that's my industry. If my industry were database management, then I wouldn't let them use DBI either. But in my world, database performance is not something on which I need a strangle-hold. I have no idea why you would be worried about the database performance and DBI. If you are doing anything non-trivial, DBI is not going to cause you any headaches. Case in point-- most of our interactions with the db tend to use PostgreSQL for only a tiny portion of the total execution time of the page load.

      Similarly, has anyone ever told you that premature optimization is the root of all evil?

      My question is, when you reach something that LSMB can't do -- perhaps your cash register example is one -- what do you tell your clients? Do you say something to the effect of "sorry, that's not possible" or "we'll have to rebuild everything from scratch"? or do you say something like "it can't be done properly, but we can bolt-on this work-around"? Ok, there are very few cases I will tell customers I wont do something. These generally involve cases where accounting logic would be compromised and don't have anything to do with the modules used. For example, if you asked me to port to MySQL, I would probably say no. If you asked me to port to Oracle, I might take you up on the challenge, however.

      I have run into cases in the past where things are not designed to work a certain way. In those cases, I do a gap analysis, come up with a solution, and write it. The cash register is one example. My customer wanted pole display support and this is a web application. So I created an additional UDP connection for sending commands to the pole display. So my answer is always:

      "Yes it can be done. Here is how much it will cost you." Obviously I can't get to an estimate until I have done basic requirements engineering and have a roadmap to get there.

      Of course, I might say "No that is impossible" if someone wanted me to hook wings made of wax, wood, and bird feathers, and make it fly around the room by flapping its wings.... But that is more than a little outside the scope of the project.

      But I've been doing this for a long while, and I've become pretty adept at seeing the future (from my clients' perspective). I just need my developers to believe me when I say that writing their own code is going to be better when they need to change it. "it's impossible" can't ever be the answer that I give to my clients. Sure. And you don't have to tell your customers you are rewriting chunks of code, but you do need to set their expectations accordingly.

      BTW, we are using TT because we use extremely complex data structures and TT handles those well. Consider a data structure which contains all the information needed on an invoice, for example. Works great.
      --

      LedgerSMB: Open source Accounting/ERP
    7. Re:Ah, business versus pleasure by holophrastic · · Score: 1

      I was introduced to TT a while back. That's ultimately when I wound up writing my own templating language. TT was really good, but it wound up being overly syntactical where I wanted semantic-style scripting.

      Regarding the DBI, I agree, in my world, it's a barely noticable delay. But in other not so unrelated industries, database access does become the bottle-neck, and DBI does a lot of unnecessary work when you can bolt down both ends of the connection. I find that to be the general way of things with external modules.

      My favourite being CGI. I decided to write my own cgi module, because the standard one is huge, and obviously wasn't integrated into my template language. Along the way, I found this wonderful article that advises one such as myself to never ever build one's one cgi module. And then went on to list all of the things that one such as myself would forget to handle. So ten minutes later, I was done. It's a whopping 2K of code, and is much faster than the traditional CGI because it does a lot less. Of course, it's not nearly as flexible, and would be mostly useless outside of my language, but it offers me tremendous benefits within my language that I could never get with the standard CGI module.

      Incidentally, it does sound like you and I treat customers similarly. I simply go for the guess first, and the change after, instead of figuring requirements ahead of time. I'm guessing that my projects are either smaller than yours, or my clients simply aren't as involved as yours are. However, when I told my developer that I needed the dump to have some HTML formatting, he did tell me that it was impossible, and couldn't be done in any reasonable (days) time-frame. That's the unacceptable part. Especially when we ran into a lovely bug in the dumper module that simply cut the dump short due to an escape sequence within the content.

    8. Re:Ah, business versus pleasure by einhverfr · · Score: 1

      IMO, at least with PostgreSQL, the planning overhead in a query drowns out anything going on in DBI. I move a lot of things to stored procedures try to move from running thousands of queries to only running a hundred or so. I suppose if you are using a database manager with a less sophisticated planner like MySQL, it might be an issue, but then you are limited to doing trivial things (and my comment was appropriately scoped to non-trivial operations).

      For example, if you are inserting records one by one (one row per statement), your planning overhead will be around 30 ms per row. If you leave autocommit on in your db handle, you are issuing additional commit statements after each record.

      If you consolidate those into one statement as in insert into x (a) values ('b'), ('c'), ('d'), ('e'), ...., you cut down both on the COMMIT statements which force disk writes *and* on the planning overhead. So optimization of SQL is *far* more critical than what you are using to connect.

      BTW, we use Simple::CGI (it does a lot less than CGI.pm, and is less buggy). CGI is not a templating language. Even CGI.pm is not a templating language-- it is procedural framework for building code. This seems to be what you prefer but you do lose something in the process.

      LedgerSMB is something like 85k lines of code (trunk) not including documentation that is not inline in the code. Consequently, while speed is something we care about, long-term maintainability of the codebase is more critical. Hence we are moving everything to a system where we only have one language per file. HTML, Javascript, Perl, and SQL are all largely contained in separate files. (2 files have both Perl and SQL in them, but that is as many as we expect to have in the long-run.)

      This means that changing colors is no problem- you edit a CSS file. Any web dev can do that. No problem. You don't even have to know Perl!
      Want to add Javascript? You need to know a little about TT, but we have it all documented. You don't have to know Perl. In fact long-term the required Perl knowledge to customize the application is going to drop a great deal. This is all based on appropriately layering things.

      --

      LedgerSMB: Open source Accounting/ERP
    9. Re:Ah, business versus pleasure by holophrastic · · Score: 1

      Heh, this is actually a great conversation, you and I have achieved the same objectives by flying completely opposite routes. We should talk again in five years and see just how far apart we've landed.

      I've built a platform that lets me write all languages in a single file. I got sick of splitting up the html, the sql, the javascript, and the css into multiple files because I hated having one business feature spread across multiple files. So my file split is a split of business features.

      For example, one template file may have the web-site login functionality. So it'll have the web forms, the javascript for the form, all of the layout, any bouncing, redirecting, forgot passcode, help/support, captcha, registration, and edit profile. It's one file so I can drop it in and out of a project, and generally be able to edit anything about the login in one place. The same file also has the code, script, and layouts for all of the e-mails: successful registration, manager approval back and forth, and forgotten credentials.

      I go one step further and don't have any css style sheets. The template language handles that automatically by ripping style="" to shreds as necessary. Any wide-reaching layout/colour rules are simply in the wrapper template, or some global utility template along with other project-wide devices.

      Incidentally, I too have found that database work ultimately comes down to sattement preparation. For the projects that require better database management, the solution has been to not run the database statements in-line. Lots of fun with running them later, and during moments of freedom, and simply faking their result in the meanwhile. So there are always some stupid things to be done.

      Another great example comes when you want to do replication, without all of the limits of replication. And when you have uids and datestamps on every record, there are many many ways to do interesting synchronization J.T.L. (Just Too Late) such that things can happen in real-time, but without slowing anything down. It's kind of a foreground background type of process.

      I've had some fun in my life. I leave you to wonder if I mean this stuff, or something completely different.

      Oooh ooh! Not ten minutes ago I got to use "Blank?! Blank?! You don't worry about blank! Let me worry about blank!" With an actual customer, where blank was their e-mail mailbox limit. Oh it was so much fun. I didn't even realize it until after.

    10. Re:Ah, business versus pleasure by einhverfr · · Score: 1

      There are a number of other similarities.

      Neither of us find specs particularly useful. I don't find UML diagrams terribly useful (actually I generate UML diagrams *from* my work rather than do them first). However, a lot of stuff happens via a proposal process which ensures that various businesses in the community get to weigh in about how to ensure that a feature works well for everyone. Yes it costs the customer a little more in the short run but a *lot* less once others are helping to maintain the code.

      I would be interested in seeing where things are for both projects in 5 years.

      --

      LedgerSMB: Open source Accounting/ERP
  23. I have found the most scavenged code on earth by nerdyalien · · Score: 1, Funny

    #include

    using namespace std;

    int main()
    {
              cout "Hello World!";

              return 0;
    }

  24. Microsoft Popfly? by im_thatoneguy · · Score: 1, Informative

    Isn't that what microsoft is trying to do with PopFly?

    http://www.popfly.ms/Overview/

  25. Compare to other engineering materials by peacefinder · · Score: 1

    How mainstream are SAE bolts? How mainstream is 18 gage 304 stainless sheetmetal? How mainstream is a CR2016 battery?

    Standardized and well-understood components save a vast amount of effort in other engineering fields and help produce results that are more easily verified to be good.

    Why not apply the same approach to software engineering? Isn't that the greatest promise of open source?

    --
    With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
    1. Re:Compare to other engineering materials by einhverfr · · Score: 1

      That is basically what libraries are, right?

      That is very different than taking a bunch of code, stitching it together, and building a system out of it.

      --

      LedgerSMB: Open source Accounting/ERP
    2. Re:Compare to other engineering materials by grumbel · · Score: 1

      ### That is basically what libraries are, right?

      Not really, libraries are an implementation, not a ISO/ANSI/DIN/whatever standard, so their behavior is defined for most part by implementation, not by specification. So you don't find an independent implementation of GTK or QT or most other stuff, aside from a few libraries that clones other libraries (i.e. lesstif vs motif, Wine, etc.), but even there its not following a defined standard but just cloning things as best as you can.

      The only part of programming that follows standards is the core language itself, but those often solve only a very tiny fraction of what you need to write real world programs.

      I think that is a huge problem, not only are the standard libraries to small, but they are often also terrible buggy and outdated, i.e. string handling in C is a total garbage, you have function like gets() which will cause buffer/heap overflows no matter what you do, you can't use that function correctly. And the alternatives like fgets() and such are cumbersome to use so that everybody ends up building its own little string library. I think in a day and age where security updates are installed on a weekly basis it would really help a lot to extend the standards a little more often instead of just every ten years, so that often used parts are more easily available and don't have to be reinvented each and every time. This would also help a lot in making libraries more compatible to each other, since you wouldn't need to convert forward and backward between types that are basically identical in their design.

    3. Re:Compare to other engineering materials by einhverfr · · Score: 1

      Not really, libraries are an implementation, not a ISO/ANSI/DIN/whatever standard, so their behavior is defined for most part by implementation, not by specification. So you don't find an independent implementation of GTK or QT or most other stuff, aside from a few libraries that clones other libraries (i.e. lesstif vs motif, Wine, etc.), but even there its not following a defined standard but just cloning things as best as you can. Some libraries are indeed standardized (standard libraries for C for example). I guess the question is why one would want every library to be standardized. There is, however, a standard *process* for determining what people should put into libraries: Analyze the code, identify reusable routines, and put them in libraries.

      I think that is a huge problem, not only are the standard libraries to small, but they are often also terrible buggy and outdated, i.e. string handling in C is a total garbage, you have function like gets() which will cause buffer/heap overflows no matter what you do, you can't use that function correctly. And the alternatives like fgets() and such are cumbersome to use so that everybody ends up building its own little string library. I think in a day and age where security updates are installed on a weekly basis it would really help a lot to extend the standards a little more often instead of just every ten years, so that often used parts are more easily available and don't have to be reinvented each and every time. This would also help a lot in making libraries more compatible to each other, since you wouldn't need to convert forward and backward between types that are basically identical in their design. Ok, that is a fair statement gets() really should be removed and replaced by something with a max size argument.

      However, since standards bodies move at a glacial rate, why not create a little LGPL/BSDL library for the required functionality and advertise it to the world? Why does the process require standardization?
      --

      LedgerSMB: Open source Accounting/ERP
  26. My reaction was different by einhverfr · · Score: 1

    I think that in some rare cases, code scavenging is helpful. However, in most cases, it does not lead to solidly engineered software. Basically you get a piece of code, review your code, analyze the interface, prefactor, debug, postfactor, and now it is working well. By that time, you could have written a rough draft, debugged, and postfactored in less time and gotten a more consistent codebase out of it.

    So I am not sure at all to what extent this code scavenging is sufficiently helpful to make formalize the process.

    --

    LedgerSMB: Open source Accounting/ERP
    1. Re:My reaction was different by chriseyre2000 · · Score: 1

      Unless the intent is to solve the problem in the same way as the (probably) undocumented code. This is quite often the case where the new application must do everything the old one does plus the following new requirements...

  27. One more note by einhverfr · · Score: 1

    Ultimately, my point is that when you control every line of code, you aren't hampered by other people's restrictions. I would have been happy had my programmer written his own dumping code from scratch, but I also would have been happy had he started with the cpan dump code, searned from it, and created a derivative version. Hell, in this case, I'd have been happy if he had studied it to the point where he could have modified it easily. Sadly here is where you are terribly wrong. They key to doing what you want to do is to understand what you want from the beginning, do the requirements analysis up front, etc. and so forth. There is a *huge* difference between dumping a Perl object (the way Data::Dumper does) and creating a nice HTML document from it.

    Your programmer, if he was smart, grabbed the CPAN module, wrote a little wrapper around it, and integrated it into your application. If you had known what you wanted up front, he would have done the same with TemplateToolkit. (LedgerSMB uses both so I have experience here!)

    Even if your programmer wrote all the code from scratch, adjusting it to output valid HTML tables that Javascript would reliably work on would be more work than just starting over with TT.
    --

    LedgerSMB: Open source Accounting/ERP
    1. Re:One more note by holophrastic · · Score: 1

      Yeah, I'm afraid we work in very different markets. "to understand what you want from the beginning, do the requirements analysis up front, etc. and so forth" is just complete ficction in my world.

      Never will a client ever know what they want ahead of time, and never will anyone want to waid through weeks or months of specification agreements. Also, their business is changing as the project grows and they become integrated around it. There's just no way to determine things ahead of time.

      In this case, dumping out a perl structure, or dumping out a perl structure as valid html tables is nothing more than the layout of the dump. If your dump code changes based on the layout format, then you didn't write it correctly in the first place. It's no different than writing an export script that outputs as tab delimited, and then saying it's impossible to switch it to CSV.

      TemplateToolkit is huge. Why on Earth would I allow my developer to pull in an enormous module to do something really simple? Especially when the next little change is going to have him pushing yet another module -- what's next?

    2. Re:One more note by einhverfr · · Score: 1

      Never will a client ever know what they want ahead of time, and never will anyone want to waid through weeks or months of specification agreements. Also, their business is changing as the project grows and they become integrated around it. There's just no way to determine things ahead of time. If your clients don't know what they need up front, then your development is going to be disorganized. You will have to charge your customers accordingly (and they will probably pay through the nose). FWIW, I don't get spec agreements from my customers either, but there are many times when we spend weeks ensuring that I understand what they need well enough to do it. It saves months of development time :-)

      Secondly there is a *huge* difference between wanting to just dump a Perl structure and wanting to dump it in a way that would be user-accessible. The fact that you write this off as a mere format difference suggests you don't really know what is involved. Let me see, you wanted a DHTML table.... What sort of DHTML table? etc.... In this case, I would *hope* you would know up front that this was going to be web-based. If not then the customer will need to pay for this lack of specificity and they will pay through the nose.

      TemplateToolkit is huge. Why on Earth would I allow my developer to pull in an enormous module to do something really simple? Especially when the next little change is going to have him pushing yet another module -- what's next? Because evidently you want some magical code which allows you to dump structures in any format, is tested, and is flexible. Yes it is huge, and it is a good module for what it does. But if you don't know what sort of layout you want, it makes things *much* easier. In LedgerSMB, we use it for LaTeX and HTML generation. I think we also use it for CSV, XLS, ODS files as well.

      In the end, you are blaming your developer for not creating something you didn't ask him to create. In general this is counterproductive. The way to go is to charge your customer to make it happen, if that is really what your customer needs.
      --

      LedgerSMB: Open source Accounting/ERP
    3. Re:One more note by holophrastic · · Score: 1

      See, yours is the perspective that I get from everyone -- including my developers. But that's just it. I do have a package that huge, and flexible, and makes things much easier, and supports dozens of structures in any sort of layout I want. I call it "the developer".

      I too am a developer. Writing a routine that traverses a perl structure is five lines of code -- ten if you want to go nuts. Any formatting can be shoved in and shoved out as quickly as a developer can type. Whether it's a bunch of tabs and line breaks to indent a tree, or td's and tr's to produce a table, it's an extra line or two of code. Making it dynamic is just adding id's and onclick's to the td's. So our ten lines becomes twenty. That's it.

      My clients don't don't know what they want up-front. Quite frankly, they have no freakin' clue what they want. And in my opinion, they shouldn't. My clients sell, widgets, manufacture widgets, dig tunnels, sell services, organize events and provide advice. None of them build web-sites nor design software. That's why they call me.

      I operate under that principle from the start. It's not unusual for me to build their entire project with virtually nothing from them outside of their business objectives. Then, I present to them the completed product, and we start with that. They change it, turn it upside down and inside out. Every one of my clients is an executive able to make decisions and edits and change anything before them. But they need a starting point.

      I see it like a car. I build them a car. It needs to do what a car does, and every car does the same thing. I build a good car. Then my client comes and doesn't like the steering wheel, so I show them wheel options. Then they don't like the body, so we talk and I build them a bigger body -- and swap out the chassis as needed. Then I strip the paint and re-paint it whatever colour they choose.

      Of course, this involves work that wouldn't otherwise be required. I have to remove and add a second chassis, and re-paint something that's already painted. But hey, first, I've got the experience to come pretty close the first time on most of the significant parts. I know, from my own experience, what kind of car they want -- suv, van, minivan, sedan, racecar -- so my chassis options are limited in the first place. Same goes for most things. So really, it usually costs me a few steering wheels, and a few buckets of paint. But I'm really good at my job, and can re-paint a car quite quickly, and I have my stock of steering wheels.

      Back to reality, changing a web-site's colours is not worth worrying about. I can re-skin the entire site's layout too and not be worried at all. But that's because I program things properly in the first place. The principles are simple: the client will change everything that they can see, and nothing that they can't see. Their business objectives won't change (within the scope of the project).

      As an experienced professional, I know what every product catalogue web-site has ever had. There aren't an unlimited number of available features, there are fewer than 200. So I build planning to add any random set of fifty. The client typically asks for ten, wants twenty, and should have thirty. Over the course of the launch, they get what they deserve -- no hassle and the knowledge that they don't need an iron-clad contract in advance.

      I've had to work of off such spec documents; and I've seen things that would make your head fall off. Spec documents that specify certain things to be broken -- nay, must be broken. Limitations that would be solved by one line of code. And the all time favourite: "Clicking on the contact link will take the visitor to the contact page".

      Doing it, and redoing it a dozen times until everyone is happy is a lot faster, measured in calendar time, than figuring out what everyone wants ahead of time. And nothing, nothing, is worse than spending twe months of scheduled and rescheduled meetings getting a dozen executives to agree to

    4. Re:One more note by einhverfr · · Score: 1
      After reading your post through, I doubt we are in industries which are that different.

      See, yours is the perspective that I get from everyone -- including my developers. But that's just it. I do have a package that huge, and flexible, and makes things much easier, and supports dozens of structures in any sort of layout I want. I call it "the developer".

      I too am a developer. Writing a routine that traverses a perl structure is five lines of code -- ten if you want to go nuts. Any formatting can be shoved in and shoved out as quickly as a developer can type. Whether it's a bunch of tabs and line breaks to indent a tree, or td's and tr's to produce a table, it's an extra line or two of code. Making it dynamic is just adding id's and onclick's to the td's. So our ten lines becomes twenty. That's it.

      Ok, IMO, this is a maintenance nightmare. BTW, traversing Perl structures can be tricky. I do have to do it on occasion to process various things (for example, ensure that certain objects are turned into strings prior to template processing) and yes, one can do recursion in 10 lines, but there will be corner cases that don't get handled properly. Perl being Perl, you can probably do it in fewer lines, but will drastically reduce readability in the process.

      My clients don't don't know what they want up-front. Quite frankly, they have no freakin' clue what they want. And in my opinion, they shouldn't. My clients sell, widgets, manufacture widgets, dig tunnels, sell services, organize events and provide advice. None of them build web-sites nor design software. That's why they call me.

      If that is what your attitude is towards development, it is easy to see why these projects sometimes go amiss. It is entirely certain to me that your customers do know what they want up-front, even if it is just "we know how we want this to help us." (Customers who don't know that don't tend to spend money.) From that point, it is your job to help the customer understand *how* you and they together are going to help them accomplish their goals. After all, you have to help the customer accomplish their goals-- you cant do it for them.

      Most of my customer's don't initially care how I accomplish what they want, but they do understand that they have to be a part of the solution and that we will work together. I can't think of any major jobs we do where specifications get agreed upon up-front. Instead we send analysts (even if it is myself) to their location where we document how they do things and what needs to be changed. It is still requirements engineering but we generally drive it. And we communicate what we are doing with our customers.

      However, it seems like you are asking developers to code without a roadmap or a list of technical requirements. So you can't be unhappy when things slip because those requirements change.

      Back to reality, changing a web-site's colours is not worth worrying about. I can re-skin the entire site's layout too and not be worried at all. But that's because I program things properly in the first place. The principles are simple: the client will change everything that they can see, and nothing that they can't see. Their business objectives won't change (within the scope of the project).

      So let me see-- you are equating changing a CSS file to changing the output format of recursing through a data structure. A better analogy would be to change a table in a web site from HTML to, say .ODS Yeah, they are both SGML-based and may both be XML (depending on the web site), but that is no less trivial than changing from a pure Perl dump to valid DHTML.

      I see it like a car. I build them a car. It needs to do what a car does, and every car does the same thing. I build a good car. Then my client comes and doesn't like the steering wheel, so I show them wheel options. Then they don't like the body, so we talk and I build them a bigger body -- and swap out the chassis as needed. Then I s

      --

      LedgerSMB: Open source Accounting/ERP
    5. Re:One more note by holophrastic · · Score: 1

      See, I disagree with your last point. For as long as software developers aren't software engineers, then you have two things. First, you have programmers who can't see three steps ahead. Second, you have designers who have no idea how things are actually implemented. Third, you have wasted energy passing between the two.

      Nothing I'm doing is difficult. Forty million if statements, basic iteration, rare recursion, and a whole lot of simple code. The trick is only knowing where everything is.

      Think after the project. When it's already launched, and already running, and the client's been happy for six months. And now, they call you in for a mystery meeting -- my all time favourite; it means free business. So you walk in two hours later, and they want a feature. They ask only two things: when, and how much. I take thirty seconds of silence, and I give them an answer. I know every line of code, so I know what's involved. And I've done shit before, so I know how long it takes. After all, they're asking for something as simple as an isolated feature, or a wide-ranging integrated cross-system entanglement. Either way, it's either something I've done a dozen times, or something that I planned they might want down the line.

      So I give them a dollar amount, and a date, right on the spot. They usually say yes, and I get to leave with a sale. If I weren't in such control, I'd have to go back to the office, talk it around, get a designer's take on how it should be built, and a programmer's take on how long it'll take, and what else it affects. Four hours of work and three calendar days later, I'd have to meet with my clients again -- really hope they have time for me or it'll be up to two weeks -- and by then, either they've found a way to avoid building it, or someone else has proposed something else and now I get to compete with some other company.

      Most of these features amount to throwing money at a problem because for my client, it's a ten-minute meeting, a two day wait, a few dollars, and the problem is solved. And hey, if the cost makes it under their "I don't need permission to spend this amount" budget, then it doesn't even require a purchase order.

      There are huge advantages to knowing every line of code in your product. Knowing what's possible and planning injection points are by far two of the greatest benefits.

      What I offer, as a service provider, is the ability to make 98% of the business decisions on behalf of my client. That gives them the piece of mind, and the time, to not worry about the project.

      On a not so unrelated note, I venturing into the computer manufacturing industry. I'm sick of relying on my clients to have good hardware, so I'm going to provide it myself. I'm also sick of ugly hardware -- and by that I mean composition, not cosmetics -- so I'm constructing my own enclosures (actually bending my own metal etc.) Guess how many suppliers can't give me straight answers like "how much does your lcd cost" or "what makes it different from this $100 screen I bought at best buy"? I actually had to threaten to lock a supplier in the basement before he'd give me a price range.

      Don't even ask me what the answer to "does your electrical certification include liability coverage if you make a mistake"?. Here's a hint, it's not a boolean response.

      I'm just really tired of people not knowing their own products. I bought a douve -- a bed quilt. I was looking for a 100% white goose down version. Every single box/bag says "white goose down douve". I asked the sales people: "is it 100% goose down?" every one of them "yes, it is". Then I got to rip open the bag, and show them the new materials tag on the product that says "contains an amount of feathers not in excess of legal limits". They not only didn't know, they actually lied to me. The difference is dollars, and that's just fraudulent.

      I'm not bitter.

      I did eventually find one. In a store that had both kinds. And three days later, they ran an ad in the newspaper offering 25% off of a 100% white goose down douve -- it was for the fake one.

    6. Re:One more note by einhverfr · · Score: 1

      See, I disagree with your last point. For as long as software developers aren't software engineers, then you have two things. First, you have programmers who can't see three steps ahead. Second, you have designers who have no idea how things are actually implemented. Third, you have wasted energy passing between the two. What I meant was that I can out-design most programmers out there. However, I have met a lot of developers who can out-code me. There is a deceptively large gap between those skill sets. I have been burned by assuming that there was less of a gap than there is. I am guessing that you are in the latter camp.

      Nothing I'm doing is difficult. Forty million if statements, basic iteration, rare recursion, and a whole lot of simple code. The trick is only knowing where everything is. IMO, nearly every application which relies on if statements for its structure is a maintenance nightmare.

      And now, they call you in for a mystery meeting -- my all time favourite; it means free business. So you walk in two hours later, and they want a feature. They ask only two things: when, and how much. I take thirty seconds of silence, and I give them an answer. I know every line of code, so I know what's involved. And I've done shit before, so I know how long it takes. After all, they're asking for something as simple as an isolated feature, or a wide-ranging integrated cross-system entanglement. Either way, it's either something I've done a dozen times, or something that I planned they might want down the line. But do you understand what, exactly, they need? 99% of my time in requirements engineering is actually just talking with the customer about what they need. Then we have meetings with developers and plan out how to get there. Generally speaking I do give them a date and a time (and I inflate both with the idea that I can then come in under budget and ahead of schedule). Sometimes projects slip because problems are more complex than they appear but that is not the typical case.

      Smaller projects ("I want price matrixes to update automatically when invoices are sent") also go the way you describe.

      What I offer, as a service provider, is the ability to make 98% of the business decisions on behalf of my client. That gives them the piece of mind, and the time, to not worry about the project. I would never trust such decisions to someone outside my business. I might ask advice, but....

      I'm just really tired of people not knowing their own products. I bought a douve -- a bed quilt. I was looking for a 100% white goose down version. Every single box/bag says "white goose down douve". I asked the sales people: "is it 100% goose down?" every one of them "yes, it is". Then I got to rip open the bag, and show them the new materials tag on the product that says "contains an amount of feathers not in excess of legal limits". They not only didn't know, they actually lied to me. The difference is dollars, and that's just fraudulent. Now, LedgerSMB is in a funny spot here-- we forked from an application which could easily be nominated "Worst web app ever" and after working with the codebase or over 3 years, I still find unpleasant surprises. Hence we are pulling out as much as we can in favor of CPAN modules, and moving everything over to a much cleaner architecture. Hence it is now far easier for everyone to work with the application and we are getting more community contributions.
      --

      LedgerSMB: Open source Accounting/ERP
    7. Re:One more note by holophrastic · · Score: 1

      Oh I'm definitely in that latter camp. It's not that I don't see the gap between the two skill-sets, it's that my products rarely benefit from advanced versions of either.

      Really, and it's hard to say this without insulting myself, nothing I do is complicated. Sure there are lots of parts, but it's like a chain. You make itty bitty links. Each one the same as the previous one. Not one of them complex. And then it holds hundreds or thousands of pounds. I've simply become really adept at making links of various shapes, twists, and sizes.

      That's really where my power comes from. Having the flexibility to do a lot, but only within a very narrow definition. I insist on the same languages, the same platforms, even the same hardware. And I just do again what I've done many times before.

      Regarding the if statements and maintenance, we've come a long way from cahins and chains of if statements. But we're still talking about conditional statements. They tend to take the form of dynamic function pointers and hashed lookups, but it's still just a straight conditional -- only the syntax is cleaner.

      We have this fun little motto around here, well, two of them. The function won't be complete until it takes a hash and returns a hash. If it doesn't, I promiss it will within a year. The second is plainly: if the function does anything, it's not finished.

      At this point, it's become funny. Most of our core platform code is composed of functions and subs that, when you read them, seem to do nothing. It pretty much reads like assembler. This function simply moves some value from one hash key to another. Or, all-too-often-the-case, takes a hash of values, and returns a smaller hash of some of the values. And you read through three dozen functions that each seems to do virtually nothing. But they all call each other, and they are all semantically named, and features just emerge. Combined with injection points galore, we get our coined concept of "accidental by design" where features and functionality wind up being implemented is seconds because, apparently, we've accidentally already built it, and just never noticed.

      --->"I would never trust such decisions to someone outside my business. I might ask advice, but...."

      You know, I used to say the same thing about my own business. And I still do for absolutely everything that touches the core of my business. And it's always been my challenge to garner the trust of my clients before they become my clients. But over the last few weeks, a partner and I have been jointly developing a new product -- with business model very different from anything either of us has ever explored.

      We've been sourcing suppliers. And while the cheaper ones that give us complete control of our product are certainly cheaper (by an order of magnitude), we've found some that are willing to take our suggestions, and build something that they feel is good without our having to do anything.

      We prefer the second set. Those that we trust allow us to walk away, and trust that they know what they're doing, and will do it well. Now I see what my clients see in me. They make widgets. They don't make software. They don't want to make software. They don't want to learn how to make software, and they don't want to supervise someone else making software. They just don't want to get screwed -- especially the ones that have been screwed in the past. I get to convince them that any supplier can screw them, and taht they need to trust me. Those that let me earn that trust get everything they wmant and more, without any work or worry.

      I'm looking for that in my suppliers too. Thankfully, I've found a handful that really make my professional life quite easy. Rackspace comes to mind -- what an excellent company. The company that supplies my gift baskets also takes major headaches away from me. Even my courier of choice beats the major ones by making it easier for me to get packages to and from them.

    8. Re:One more note by einhverfr · · Score: 1

      We prefer the second set. Those that we trust allow us to walk away, and trust that they know what they're doing, and will do it well. Now I see what my clients see in me. They make widgets. They don't make software. They don't want to make software. They don't want to learn how to make software, and they don't want to supervise someone else making software. They just don't want to get screwed -- especially the ones that have been screwed in the past. I get to convince them that any supplier can screw them, and taht they need to trust me. Those that let me earn that trust get everything they want and more, without any work or worry. With all due respect this doesn't sound like they are ceding business decisions to you. It sounds like you are essentially selling them a customized version of an off-the-shelf sort of product. This is sort of different.

      Ok. In a previous post you mentioned web catalog software. In general, web catalog software is pretty straight-forward. However, where the real difficult issues come in have very little to do with software, building software, deciding what the software needs to do, etc. They are the social issues. I.e. a web catalog is a catalog. It requires content management processes to be in place on the *human* level. This means content review, etc. And in fact, none of these things (except the actual data entry) need to even be done at a computer. This level (the business process level) is where the customer needs to be in control.

      As I sometimes say, "If the customer was always right, I would have a lot less work." The customer is not always right and they don't need to be in control of the technical end. However the customer is the expert on the customer's needs and the person with the ultimate responsibility and hence a) the customer needs to be in charge of their own business processes and b) the software needs to support rather than define those processes. From what you say, I am guessing that you don't entirely disagree.

      BTW, regarding performance-- I believe that support two of the largest instances of LedgerSMB. The largest is actually a cash register environment. We have found that in general, we get a *lot* better performance with each release despite doing a lot of things that you would think would degrade performance (for example relying more and more on CPAN). One of my recent changes reduced running time from 30 minutes to 1.8 seconds.
      --

      LedgerSMB: Open source Accounting/ERP
    9. Re:One more note by holophrastic · · Score: 1

      No I certainly don't disagree about clients control the business processes. However, I'd like to interject some of my psych learnin's. Are you familiar with the concept of "high choice"?

      For those who aren't, it's tihs lovely cross of psychology and philosophy. You basically ask a subject (err, participant, heh), to choose between two things. It's completely their choice, and they are free to make either selection. Funny thing though, under certain situations, absolutely (or virtualy absolutely) every single person makes the same choice, and feels as though it's their choice.

      Obviously, some magicians "push a card" the same way.

      Well I work in the custom software industry. And yes, it's all custom, and yes each client gets to control every aspect that they desire. But I work across verticals too, and over the years, I've noticed the patterns. Since I tend to work for the same three types of clients, they tend to make the same three types of decisions.

      So I like to guess. I'd rather have them see a whole product, and then turn it upside down and inside out, than take them through the initial development process because 95% of their decisions are going to be readily predictable. Again, it's not that they don't get to make the decisions, it's just that their business, while completely different from other clients, is attacking a similar problem in a similar manner.

      Incidentally, high choice is cool -- and yes, I was that participant (err, subject, heh). The philosophy part can't escape me -- so was it my decision?

    10. Re:One more note by einhverfr · · Score: 1

      I guess my point is that technical concerns are not the same thing as business concerns. Technical concerns are fundamentally cut and dried, and are basically a mathematical model of how data ought to exist and be processed.

      Business concerns are fundamentally human issues. They are questions like "How many people do I need to hire to make sure that the content on the web site is correct?" "How do I go about ensuring that employees aren't stealing from my business?" and "How do I encourage customer loyalty through great customer service?" All too often businesses end up mapping these sorts of issues to the flow of the software, rather than building the processes first and then getting them to work with the software. This is generally wrong because businesses lose their creative spark and their ability to run their business. These are the areas where customers need to be in complete control over their business.

      All technology exists only to support these processes anyway. There may be cases where there is one right way to do things, but more often, the one-right-way applies to the software and math, and not to the business.

      --

      LedgerSMB: Open source Accounting/ERP
    11. Re:One more note by holophrastic · · Score: 1

      Heh, I've always felt the reverse. That based on your business's mission statements, the business decisions are the cut and dry ones.

      If accurate web-site content is important, then the number of people dedicated to it is simply based on their productivity -- which is easily measured. If customer loyalty is a priority -- and it isn't for some of my suppliers actually -- then great customer service is easily mapped out.

      It's the technical concerns that I find more, well, subjective. Which side of the database connection to optimize? On-line admin area or webmaster/dbadmin? Caching engine or faster server? Caching in the database, or in the file system? Two-column layout or three?

      The cool part is that you and I actually agree. I think I'm playing more with what is business and what is technical, but ultimately, I do believe that once either problem is well defined, the solutions and actions to get there are cut and dry.

      Of course, as I've been explaining to a comedian friend of mine, who's asked things like "if that's such an easy feature to build, how come after ten years you haven't built it yet", it's a matter of priorities -- there are hundreds of features in my head that are each easy to build, but some are more urgent than others, and yes, the list is long and contains elements over a decade old.

      If you todo/bug/feature/upgrade lists include datestamps, you know what I mean when I say that the time component is entirely insignificant. But wow is it fun fixing a three-year-old bug!

    12. Re:One more note by einhverfr · · Score: 1
      Well, business priorities can be mapped out fairly easily by successive approximation. And this is best done by empowering people on the ground to tackle problems. However, if we look at problems that go into rollout of software such as CRM, ERP, and CMS systems, the reason for project failure is inevitably a lack of business process for the application to support. The better approach (and my advice to customers as an IT consultant) is to do what you can with people first and then get software to support them.

      As for optimizations of software, it isn't too complicated. There aren't very many concerns beyond performance and maintainability.

      Which side of the database connection to optimize? If you are asking this sort of question, you aren't pushing the database very hard :-). If you are doing anything non-trivial, your database server is going to be both the scalability and performance bottleneck.

      On-line admin area or webmaster/dbadmin? That isn't a technical concern-- it is a business process concern ;-) Also the question assumes limited resources to do this. For an open source project, like LedgerSMB, both areas get a lot of attention.

      Caching engine or faster server? Well, you start by seeing how far you can go with eliminating existing bottlenecks.... Usually I avoid caching servers in most cases. The complexity cost is too high. I would rather choose between vertical (faster server with more RAM) and horizontal scaling (for example Slony on PostgreSQL to scale db reads or a move to BizgressMPP for really big data analysis stuff).

      Caching in the database, or in the file system? I avoid caching except for long-term summary data in rare cases (for example, "last time you closed your books, your checking account had a balance of $126,000.00" as a way of avoiding aggregating over 20 years of data to get a checkbook balance). In those cases, however, the cost of having it in the db is almost always less both in terms of performance and maintainability than anywhere else.

      Two-column layout or three? Again, that isn't a technical issue so much as an aesthetic and workflow issue. Hence we are outside the math foundation and into the human element again.

      Basically you have three layers: Pure technical, the HCI layer (workflow, UI), and the Pure human layer. In general, as you move from technical to human, more flexibility is needed and less math applies.
      --

      LedgerSMB: Open source Accounting/ERP
  28. The Title by hpavc · · Score: 1

    The title of this article seems to have been 'code scavenged' ... it makes no sense and wasn't proof read. 'How far can can code scavenging go in the mainstream?' perhaps

    --
    members are seeing something, your seeing an ad
  29. indie code scavenging by screamphilling · · Score: 1

    indie code scavenging, indie code scavenging, indie code scavenging

  30. Re:END MODERATOR ABUSE by Anonymous Coward · · Score: 0

    Just do what I do: M2 frequently. And fairly. And by that I mean, if I don't see any insight in a comment that's modded Insightful, it gets metamodded Unfair. Etc. If it happens more than a few times to someone, they lose their mod privs.

  31. The reuse of old code... by adamkennedy · · Score: 2, Informative

    So... the formalised use of old code... you mean like CPAN?

  32. And the title... by Anonymous Coward · · Score: 0

    I think I lost even more braincells trying to grok the title. "How Mainstream Can Code Scavenging Go?". Wow, I thought! Is there a Scavenging version of the japanese game of Go? Can Mainstream ever be able to Code it? And How will they ever manage it? WTF!? What's with the capitalization of almost every word other than a few prepositions? Jeez...

    1. Re:And the title... by Anonymous Coward · · Score: 0

      WTF!? What's with the capitalization of almost every word other than a few prepositions? Jeez...

      http://en.wikipedia.org/wiki/Title_case#Headings_and_publication_titles
  33. Objects anyone? by olddotter · · Score: 1

    One of the selling points of object oriented coding was it was supposed to formalize this and make it easier. In theory all objects were to be designed to be generic and reused from day one. In practice it rarely works that way. Especially under tight dead lines and lean development teams.

    1. Re:Objects anyone? by grumbel · · Score: 1

      I don't think this has all that much to do with deadlines and more with objects being just as inflexible as what we did before them, i.e. as soon as an object wants to do anything useful beside very basic stuff it has to interface with some other object and unless you happen to have an object that has that interface you are dead in the water.

      Where objects help is in keeping related code together, but that is more syntactic sugar for stuff you would expect in a clean program anyway.

  34. Re:END MODERATOR ABUSE by jericho4.0 · · Score: 1

    Get. A. Life.

    --
    "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
  35. This reminds me of another book ... by James+Youngman · · Score: 2, Interesting

    ... of an SF book I read a few years ago, where all programs were written by a process of digging into 10,000 years' worth of computer programs in a sort of archaeological way, pulling out something that did more or less what you want and amalgamating it with what you had so far. I thought at first that it was a Vernor Vinge book, but checking the plot summaries on wikipedia, it looks like it was somebody else. Can anybody remember the book I'm thinking of?

  36. oops by yoprst · · Score: 2, Funny

    Apparently, slashdot has already scavenged angle brackets - they're gone. Truly the most scavenged code ever.

  37. In other news by irtza · · Score: 1

    SCO recently announced a 3 trillion dollar law suit against the owner of the kclittle slashdot ID. When asked about the dollar amount, they said that the "three billion" number lost its glamor and is no longer taken seriously.

    --
    When all else fails, try.
  38. Yay CodeProject by paulxnuke · · Score: 1

    I sympathize with the attitude that one has more "control" by doing everything from scratch, but I don't have the luxury of a huge team or reasonable deadlines. I get burned regularly by using third party code, paid for or not, but given the source code it can usually be made to work, or scrapped early if it clearly won't. One non-developer exec bought us a bunch of code from some third world outfit: we junked it all and rewrote when we realized that would be faster than fixing it.

    Everyone I know uses http://codeproject.com/, especially for oddball MFC controls. It's usually necessary to do significant debugging and extending, but you get ready-to-go starter code with most of the skanky MFC issues and gotchas already handled, plus usually a demo project, for less effort than writing from scratch.

    One coworker was an advocate of third party ActiveX controls: after one disaster too many I finally ActiveX entirely and we've almost completely replaced what we had. The issue, aside from extreme ugliness and painfulness to use, is that most commercial ActiveX is closed or unusable source, and is at least as incomplete/buggy as CodeProject source code.

  39. it's already been done by Biffers · · Score: 1

    http://www.google.com/codesearch apparently google has already done it.

  40. search is the problem by fuliginous · · Score: 1

    like just finding the right application amongst zillions the problem (to something most I'm sure would otherwise consider doing) is finding it.

    Yes you might want to save time through such reuse, but first you have to somehow find possibilities and then you have to decide which one of those suits best. And that time consuming process is why so much ends up getting written from scratch so often.

    Solving that problem is itself a problem though. At the moment there is such a diversity because of that. Take away the diversity and you move toward a narrowed less populated eco system, which I think for many (hopefully) obvious reasons is best avoided.

  41. Re:END MODERATOR ABUSE by Anonymous Coward · · Score: 0

    I see that you have learned to post anonymously when you are about to be a douche. Congratulations, that is a bit of progress. Now all you have to do is refrain from being a douche while logged in long enough to get mod points of your own (it takes about 6 months) and you can start instituting your high standards of intellect on our moderation... except looking at your posting history (if you are Taco Meat), you really are a douche.

  42. Extremely Simple example by Deliveranc3 · · Score: 1


    int Tree( Char ***Node1, char **data)
    Sort a-z
    return height

    int retreive (char **return, char **searchfor, int length)
    return found

    For simple functions it works well, for open source code it works great.

    Between those levels lies the question, why aren't you using their code anyway?

  43. First-class Copy & Paste for Code Reuse by naasking · · Score: 1

    Like most problems, textual code reuse has via copy & paste has already been studied, and a language based on first-class copy & paste is being developed; it's called the Subtext language. See a more detailed discussion of it on lambda-the-ultimate. Academia is not so far remove from everyday programming as people seem to think!

  44. DECUS Tapes by taosystems · · Score: 1

    Speaking of one of the grand-daddys of reusable source, does anyone remember the DECUS Tapes from the DEC community. There's still a lot of prior art work to be found there.

  45. Libraries by InsertCleverUsername · · Score: 1

    It's funny that people rarely mention how the code libraries in frameworks like Java and .Net have superseded a lot of earlier scavenging. I can't remember the last time I wrote custom code to send e-mail, display forms, etc. Today's scavenged functionality will be tomorrow's built-in tools.

    --
    Ask me about my sig!
  46. How many times... by PPH · · Score: 1
    ... can one re-use the:

    int main( argc, argv )
    int argc;
    char **argv;
    {
    ...
    }

    code snippet?

    --
    Have gnu, will travel.
  47. Oblig Quote by g-san · · Score: 1

    Sark.... all my functions are now yours.... take 'em.

  48. Re:I've been thinking of scavenging code from SCO. by Anonymous Coward · · Score: 0

    That's a great idea, the Linux kernel could use some SCO code. We used to have some but we had to bury it in the desert when SCO sent in the weapons inspectors.

  49. Scavenging Code by jjtechno · · Score: 1

    Maybe this is a push article from the authors of krugle.com? The enterprise edtion is supposed to be rolled out pretty soon. I would hope any software company can modularize their code for reuse. Most programmers can and do. How many times do I need to write a count function? Or poke data in to an array? It isn't protected property as much as saving time by not rewriting the wheel function.

  50. Business Sense by RAMMS+EIN · · Score: 1

    ``You've simply fooled yourself into thinking the process is simpler than it is while screwing your customers out of their development dollars.''

    Which, of course, makes good business sense. At least until customers start selecting on maintenance/improvement cost instead of initial development quote.

    --
    Please correct me if I got my facts wrong.