Coffeehouse Thread

19 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

can we as computer scientists really promote code reuse when we ignore it the majority of times?

Back to Forum: Coffeehouse
  • User profile image
    Jaz

    (I really need to get better with my titles)

    I was discussing something this morning with one of my friends, he was showing me a new service... Now this is where you may say, well "service" and code reuse aren't really one in the same.. I disagree because most of these services are software based, a lot of them tend to provide functionality that can be used by outsiders.  Why do we create new photo sharing services when we have flickr, why recreate forum services when we have VBB (or whatever it's called).

     

    Surely it would be better to reuse these existing services and then work with them to fill the holes we see missing in them.  I find it a little hypocritical to advocate code reuse when I'm busy rolling my own video sharing site.

     

    rambling thoughts I guess.

  • User profile image
    figuerres

    well i think we should be talking about and looking at stuff we do in coding not at businesses offering stuff.

    for example i need to process some xml, i write my own code to do it.

    how many gigs of code on my hard drive (or anyones)  is a result of dozens and dozens of programs that have code in them that should come from a shared library but do not?

    I bet if we could get the right info it might be that say 30% or the space on drives that stores code is wasted with duplicate code.

    sure disk is cheap but that also means time and money wasted (in development) and memory when running the apps and so on  ....

  • User profile image
    ryanb

    Code reuse in the real world is difficult because it is rare to find code that really is suitable to reuse.  Code usually falls just short of doing what you need it to do, and (if it is coming from some external source) it usually comes with licensing tangles that prevent you from just fixing what you need to.  Not to mention the business model that is based around providing a product that does the same thing as a competitor's product, but does it a little better.

    But while very little code is suitable for reuse in practice, that doesn't mean we shouldn't strive to improve the success rate -- particularly for internal software that is under our control.  Reuse is much more suitable in some application domains than others.  Code needs to be designed and written with reusability in mind for a more general case, instead of the normal path of doing the bare minimum to solve the specific problem at hand.  It's pretty hard to convince management that it is worth the resource investment to think about the bigger picture.

     

  • User profile image
    ScanIAm

    , ryanb wrote

    Code needs to be designed and written with reusability in mind for a more general case, instead of the normal path of doing the bare minimum to solve the specific problem at hand.  It's pretty hard to convince management that it is worth the resource investment to think about the bigger picture.

    YAGNI.

    We shouldn't be coding ourselves into a corner, but the idea that we can somehow predict what the code will need to do in the future is wasteful.  We should be doing the bare minimum to solve the specific problem, not designing frameworks that will only confuse and confound the developers that follow along behind us.

    Developers rarely, if ever, have an accurate view of the bigger picture.

  • User profile image
    Proton2

    "Code needs to be designed and written with reusability in mind "
    Yeah, I remember when I designed code for as many future possibilities as possible, creating UML diagrams, usage case scenarios... etc. I never actually wrote much code while designing for possible eventualities.
    I abandoned that way of code development and adopted the "Agile" development method and Test Driven development and I am much happier doing software development now.

  • User profile image
    spivonious

    , ScanIAm wrote

    *snip*

    YAGNI.

    We shouldn't be coding ourselves into a corner, but the idea that we can somehow predict what the code will need to do in the future is wasteful.  We should be doing the bare minimum to solve the specific problem, not designing frameworks that will only confuse and confound the developers that follow along behind us.

    Developers rarely, if ever, have an accurate view of the bigger picture.

    Agreed, but that doesn't mean code reuse gets thrown out the window.

    Every application we have at the place I work at has its own database access logic, it's own implementation of certain user controls, copies of model entities. It would have been difficult to anticipate these commonalities back when a lot of the programs were written, but it's very tempting now to go back and strip out common code into a shared library. But there's no business case for it.

  • User profile image
    Proton2

    Tests created using TDD is the allocation of resources, the investment for the future, so that it is much easier to refactor the code, to extract what is similar so you can reorganize and reuse code.

    It is also good at catching about 50% of bugs.

  • User profile image
    ScanIAm

    , spivonious wrote

    *snip*

    Agreed, but that doesn't mean code reuse gets thrown out the window.

    Agreed.  If you've written it twice, refactor it.

    Every application we have at the place I work at has its own database access logic, it's own implementation of certain user controls, copies of model entities. It would have been difficult to anticipate these commonalities back when a lot of the programs were written, but it's very tempting now to go back and strip out common code into a shared library. But there's no business case for it.

    So don't worry about it.  If you have to go in and change the code for some reason, then perhaps it can be addressed, but otherwise treat it like a bad relationship: hopefully you learned something and you'll never do _that_ again.

     

  • User profile image
    vesuvius

    @Jaz:People don't start off as computer scientists, that is the issue. If you have a team of 10 developers, and 5 are graduates, they almost always are not going to augment to existing code or find a library that does what they want. They invariably will reinvent the wheel, because it is one they can understand.

    This is not necessarily their fault, because it is hard to get people to learn the principle of code reuse. As a rule I use Enterprise library, Prism for a lot of my day to day tasks on new projects, your jumior developer will prefer to write their own logging system, or exceptions handling or data validation and so on, and still be fighting bugs several weeks down the line.

  • User profile image
    spivonious

    @vesuvius: In the end though, you have to take into account the time spent learning Enterprise library and/or Prism and see if it's worth it rather than reinventing the wheel. There are tons of logging systems out there, but if I can write one that meets my needs in an hour, then I'm going to write my own. It may have a few bugs, but even with time spent finding and addressing them I'm still ahead on time. It could take 3-4 hours of trying various logging systems and understanding how to use them and the pros/cons of each one before the feature gets implemented.

  • User profile image
    MasterPi

    Programs in UNIX aren't designed for every possible scenario; rather, the OS allows you to combine programs to extend functionality.

    I don't think you have to worry about all possible future uses of whatever you're developing. Coding to standards (including accepting standard forms of input and output) should be sufficient. We have design patterns (adapter, wrapper) for extending functionality, and in the case of open source, we can simply modify the source when needed. I just feel that providing these extra mechanisms to make an app ultra extensible results in a bloated codebase, which subsequently unnecessarily increases the file size.

  • User profile image
    vesuvius

    @spivonious: That is correct, and usually if you force someone to try use something, then you end up with something that does not work.

    I sometimes work in high pressure agile environments, where one day they want logging to the event log, the next to a database and a week later to a web service. Sometimes customers want a custom providor and I am not in the businesss of giving them software that does not work or contains bugs.

    Obviously there are finacnial benefits for dealing with this type of pressure, which is what I try to build a set of tools (some open source) that allow be to create software components very quickly that are reliable and most importantly reusable across many different customers and in many diffent situations

  • User profile image
    ScanIAm

    Enterprise library is a classic example.  If you are reading this, writing a .Net application and you don't have a damn good reason to not use EntLib's functionality, you, sir or madam, are a plague on our profession.

    At least use it for exception handling.

  • User profile image
    cbae

    , ScanIAm wrote

    *snip*

    YAGNI.

    We shouldn't be coding ourselves into a corner, but the idea that we can somehow predict what the code will need to do in the future is wasteful.  We should be doing the bare minimum to solve the specific problem, not designing frameworks that will only confuse and confound the developers that follow along behind us.

    Developers rarely, if ever, have an accurate view of the bigger picture.

    I think if you pick a good application framework, you can worry about code that you are going to need, while somebody else worries about the code that "you ain't gonna need" (yet).

  • User profile image
    ScanIAm

    And YAGNI doesn't mean that you put on blinders and only code day-by-day, ignoring what is required.  If the app is supposed to have a feature then code for it.

    In my experience, though, a team has 1 or more folks that want to justify gold-plated wastes of time with "But what if the client wants to X." or "It'll make it easy to Y".  Of course, the client never asked to X or Y, but that isn't important at the moment.

     

  • User profile image
    ryanb

    , ScanIAm wrote

    *snip*

    YAGNI.

    We shouldn't be coding ourselves into a corner, but the idea that we can somehow predict what the code will need to do in the future is wasteful.  We should be doing the bare minimum to solve the specific problem, not designing frameworks that will only confuse and confound the developers that follow along behind us.

    Developers rarely, if ever, have an accurate view of the bigger picture.

    Agree completely.  Designing for "what if" is something that would be wasteful most of the time.  I was more referring to the things that a dev is (or should be) aware of that DO come up over and over in a particular line of work.  I reuse very little code, and rarely ever put effort into designing code for reuse.  But there are certain things that I do reuse over and over.  Call it refactoring if you prefer, but there is a lot of benefit in cleaning up those common components over always fighting to make them work.

  • User profile image
    Adam​Speight2008

    It also depends on legal status of the "shared" code. If was invented, don't use. If a shared library breaks who's responsible?  Also depends on what the Client commission you to write, and what they want.

    Software Commissioning is like ask a carpenter to make you a made to fit bedroom suite. Reuse is like then using "insert popular furniture company" product and then claim its theirs.   

  • User profile image
    Bass

    Not all code is FOSS, so that fact precludes code reuse in a lot of cases.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.