Forgot your password?
typodupeerror
Programming IT Technology

Reuse Code Or Code It Yourself? 429

Posted by kdawson
from the good-or-great dept.
eldavojohn writes "I began coding for a project that had simple requirements for my employer — Web services and a test application for them. But requirements have been creeping, as they always do. Initially I had decided to use the Spring Framework with Hibernate. And I re-used a lot of libraries that made things simple and quick for me. The new requests coming in involve capabilities beyond those of the frameworks. Now, I used to be told that good programmers write code and great programmers reuse code. It's starting to look like I would have saved myself a whole lot of time if I had written the database transaction using JDBC instead of Hibernate — now that I'm married to this object model framework, some of this stuff doesn't look doable. So what is better for the majority of software projects out there: reuse code, or code from scratch? What elements or characteristics of a problem point to one option over the other?"
This discussion has been archived. No new comments can be posted.

Reuse Code Or Code It Yourself?

Comments Filter:
  • It's knowing when (Score:5, Insightful)

    by Bender0x7D1 (536254) on Tuesday November 04, 2008 @08:05PM (#25634893)

    It's not rewriting code or reusing code that makes you a great programmer. It's knowing when to rewrite code and when to reuse code that makes you a great programmer.

    • Re:It's knowing when (Score:5, Interesting)

      by Midnight Thunder (17205) on Tuesday November 04, 2008 @08:28PM (#25635149) Homepage Journal

      It's not rewriting code or reusing code that makes you a great programmer. It's knowing when to rewrite code and when to reuse code that makes you a great programmer.

      Exactly. Experience will help you with this.

      You can reuse, reuse or rewrite:
        - the first case is trying to make the best of what you have and building on that
        - the second case is finding a library that already does what you are wanting to do
        - finally you take the time to rewrite things yourself

      Laziness is not a bad trait, since this will sometimes help you decide where you are best spending your energy. The bar is a good answer, but not applicable in this scenario ;)

      • by Artraze (600366) on Tuesday November 04, 2008 @09:09PM (#25635533)

        > - the first case is trying to make the best of what you have and building on that

        To add to this, never ever simply "reuse" code; if you just copy and paste you'll end up with a horribly designed hack job worth of TDWTF. Instead, take what you have and massage it into place.

        In this particular case, it sounds like your design no longer hashes well with the requirements. My suggestion is to start rewriting/reworking isolated portions of the code base and create a temporary compatibility layer (if necessary) to interface with the old code. Continue doing this until the entire application is converted over to the new design.

        • by thePowerOfGrayskull (905905) <marc.paradise@g m a i l . c om> on Wednesday November 05, 2008 @02:09AM (#25637079) Homepage Journal

          To add to this, never ever simply "reuse" code; if you just copy and paste you'll end up with a horribly designed hack job worth of TDWT

          The fact that you seem to think that "copy and paste" is synonymous with "reuse" is a bit disturbing...

        • by theaveng (1243528) on Wednesday November 05, 2008 @09:13AM (#25638989)

          I agree. Laziness is often the same thing as "saving time". Why reinvent the wheel when somebody already did the work?

          Here's a good illustration from the 8-bit gaming era:

          - Pitfall II was created by the original programmer for the Atari 2600/VCS. Activision wanted to port this extremely successful game to other platforms, including the new Atari 5200/Supersystem and the Commodore=64. Activision assigned this task to two programmers who also happened to be good friends.
          - The C=64 programmer decided to recreate the whole thing from scratch.
          - The A5200 programmer decided to directly copy the code, and only change the pointers as needed.

          The A5200 programmer finished his task in only half the time as his friend. He then used the extra days to program an entirely new level into the game (think Pitfall III). Reusing the code allowed him to create two games, instead of just one game.

          • by bigman2003 (671309) on Wednesday November 05, 2008 @09:34AM (#25639141) Homepage

            This is an excellent example of a project with an end date. The game ships, and then you're done. No updating.

            I've been working at the same place for 8 years, not a long time, but not just a blip on a resume either.

            We are still working on the same projects from 8 years ago. Some of them were built using a framework, some were not. We ran into a lot of problems with frameworks. Honestly, if the projects had end dates, everything would have been fine, but they didn't.

            We found that as time went on, the framework may or may not be upgraded along with the software it sits on. If it doesn't get upgraded, then you may have a problem where you cannot upgrade the underlying software. Sitting on an OS that is 2 versions old because the framework uses that particular API is not fun.

            Another problem I ran into, was when the framework WAS kept up to date. As another poster said, we 'massaged' the heck out of the code. A new version comes out, and there are incompatibilities. The new framework can't just be dropped in. We need to re-do all of our work.

            The stuff we have coded ourselves is easier to maintain. On the downside, any new features need to be written by us. On the upside, that is never a problem. We had developed 18 separate projects in the first 4 years I worked at this place. Now we've been able to morph them all into 1 project. That meant taking them off of the frameworks they were on (3 different frameworks) and code everything ourselves.

            Coding it ourselves ensures that everything works together. If we had re-used a lot of code, then the systems just couldn't be integrated together nearly as easily.

            I've tried it both ways, and for my situation, writing my own makes more sense.

            • Re:It's knowing when (Score:5, Interesting)

              by Gr8Apes (679165) on Wednesday November 05, 2008 @10:07AM (#25639875)

              I agree with you - pretty much anytime you're looking at a long running project you're better off not using frameworks that have cut corners in areas to "make it easier for developers". Frameworks like Hibernate are especially guilty of this, since those pesky DBs are just too hard for those poor little devs to learn how to interface with using the standard library (JDBC - which, btw, still morphs but usually keeps backwards compatibility)

              I personally find hibernate to be fine for simple POC's or very simplistic apps that have a definite EOL. Anything else, don't use these persistence frameworks because they'll wind up costing you more time in maintenance than having written a specific layer for your system in the first place. I've seen several projects where the Hibernate/JDO persistence layer code ran into the tens of thousands of LOCs, because the DB no longer matched the simplistic object table layout these frameworks assume. And even when you're looking to use simple tables, linking multiple commits in a transaction winds up being more difficult than it needs to be, especially if that transaction is "handled" by Spring:

              Spring - that's another one. Spring has a special place in my heart, as I see it as the Darth Vader of frameworks corrupting otherwise workable architectures everywhere. After more than 5 years of having to deal with it, I've concluded that if I can remove Spring from any project I'm working on, I will. It will save me significant time in the future. It's a poor substitute for real AOP. It masquerades as this wonderful factory (5 lines of compile time checked code without Spring, a min of 2 lines of runtime checked code with 9 lines of xml with Spring) that can inject all sorts of nastiness into your system and requires runtime debugging to figure out why the heck you don't have the object you thought you had, from the service you wound up actually not calling, 6 layers deep.

              Now, with all that said, sometimes you have to work with these systems, because there's no business case for removing them. It appears the OP has finally gotten to the point where there is a business case for revisiting his persistence layer, and if he's designed the access to Hibernate correctly on the edge of his application, it won't be too bad to remove Hibernate and install his own layer. If he's used the Hibernate calls throughout his code, he may wish to first migrate everything behind an internal API, and then start migrating code.

    • by syousef (465911) on Tuesday November 04, 2008 @08:46PM (#25635353) Journal

      It's not rewriting code or reusing code that makes you a great programmer. It's knowing when to rewrite code and when to reuse code that makes you a great programmer.

      Actually it's all of the above and more...a great programmer can:
      1) Evaluate the suitability of existing code for the task
      2) Use the existing code appropriately
      3) Write excellent readable, maintainable code when needed (and only when needed) to fill the gaps
      4) Communicate well with the business to understand the problem and design a solution

      Each of the above skills you're missing decreases your chances of success.

    • Re: (Score:3, Interesting)

      by bky1701 (979071)
      In my book, it is outputting code that works well and is maintainable that makes a good programmer.
    • by TheLink (130905) on Tuesday November 04, 2008 @08:58PM (#25635455) Journal
      Actually, the trick is knowing that you _aren't_ a great programmer (honestly what are the odds that you are a great programmer?), and thus choosing to reuse code from better (and hopefully great) programmers.

      If you wish to delude yourself, you can believe that you are a great but lazy programmer and thus choose to reuse code from other great (and more hardworking) programmers.

      Stuff like Perl + CPAN is good because of all that code you don't have to write. The less code you write, the fewer bugs you make.

      More importantly the less code you write, the less code OTHER people have to figure out. If you use popular libraries/modules whenever possible, other people can just go "Ah, the standard wheel", instead of going "He calls it a wheel but is it really a wheel? Better check, the bug might be there". Or they might even go "Ah yes, it's probably that bug in the standard wheel, when are they going to get it fixed already, meanwhile we'll do the recommended workaround".

      You can also reuse "code" in other ways. For example - using a popular RDMBS is one way of reusing code. With a good database you don't have to reinvent transactions, row level locking and all that. Lots of smart people have done all that work already. And you can use the DB as a common "interface" for other programs (also written by other people).

      A lot of the languages the CS academics heap praises on are powerful for the code you have to write, not the code you don't have to write. Yes it's probably a catch-22 thing, but when it comes to "real world", I'd rather pick the language where I don't have to write so much stuff.

      Prefab may be uglier, but it beats spending 10 years carving that perfect sculpture all by yourself, only to have the customer say "erm I want a sculpture of my wife not my ex-wife...".

      (Note I am not a great programmer, so feel free to ignore me).
      • by ClosedSource (238333) on Tuesday November 04, 2008 @09:55PM (#25635839)

        "Actually, the trick is knowing that you _aren't_ a great programmer (honestly what are the odds that you are a great programmer?), and thus choosing to reuse code from better (and hopefully great) programmers."

        This is a similiar flaw to believing that ISO certification means that a company will always create great products. Just as each product should be evaluated on its own (the UL approach), so software should be evaluated on its merits, not on the reputation of the programmer.

        There's no such thing as a "great programmer" in the sense that one individual excels in every aspect of software development. Average programmers (whatever that means) are quite capable of producing quality code. Quality code depends more on the dedication of the developers on the project than it does on programming IQ (again, whatever that means).

      • by SL Baur (19540) <steve@xemacs.org> on Tuesday November 04, 2008 @11:26PM (#25636307) Homepage Journal

        Stuff like Perl + CPAN is good because of all that code you don't have to write. The less code you write, the fewer bugs you make.

        Stuff like Perl + CPAN is also a very mixed bag and has likely caused my employer very much expense towards working around limitations in code therein compared to what has been gained. I know they've spent upwards of 6 figures on my time and others in direct and indirect costs working around the limitations and bugs in Storable, to name one example.

      • Re: (Score:3, Interesting)

        by murdocj (543661)

        It depends on whether you are truly using well known libraries or not, and how much extraneous code you pull in, just to avoid writing code. You can end up with huge blocks of unknown, potentially buggy code that you haven't written, haven't read, and which may have unknown side effects, just to save writing a few routines. Using code you haven't written isn't always a clear win, it's a tradeoff, and you have to evaluate the costs and benefits, as you would with any programming decision.

  • by evw (172810) on Tuesday November 04, 2008 @08:06PM (#25634899)

    If you'd tried to write it all yourself from scratch from the beginning you'd still be coding and you wouldn't have gotten the feedback about what needs to change as quickly. Prototype quickly then optimize later.

    • Re: (Score:3, Insightful)

      by somersault (912633)

      And if the library you're using has an obscure bug then you could also end up wasting days of work either having to track down a bug or write your own library.. sometimes it will be fine, but sometimes you might not be saving yourself any time at all, depending on whether the library is open source, how many other people have used it and bugfixed it etc.

      • Re: (Score:3, Informative)

        by setagllib (753300)

        That's fair to say, but you can be pretty confident Hibernate is a solid product. Same for Spring. They're many years old, with widespread use in open source and commercial projects. And very encouraging is how they both use unit testing from the ground up, so you can be very confident any given release is exceptionally robust.

        I wish I could say the same for the JVM they run on. There were a number of bugs in several official, supported Sun JVM releases which mis-optimised code on amd64. They seem to be fix

    • by Bad Mamba Jamba (941082) on Tuesday November 04, 2008 @09:03PM (#25635493)

      Except every time I've ever done a prototype it is invariably shipped as product minutes later.

      Naturally disaster follows.

      What you say: "I have a working prototype."

      What management hears: blah blah WORKING blah.

      Moral: Never say you have anything "working" until you're really done.

      • by Matje (183300) on Wednesday November 05, 2008 @03:35AM (#25637523)

        Joel Spolsky wrote a nice article about this a while back. Since non-technical people don't see the code that's behind the UI, they can't really judge the difference between a polished UI with no code behind it and a fully working application. It is very reasonable for them to look at a polished UI and say "let's ship this tomorrow".

        The solution is quite simple: make the UI reflect the state of the application! Use sketched buttons for stuff that doesn't work yet, use strike-through text to label stuff that doesn't work, etc. I've been using this technique for years with my customers. It gets the point across every time.

        and don't listen to all that stuff about prototypes being proof-of-concepts, that's non-agile blatter from the 70's ;-). If the prototype is attractive enough that the business people would like to use it then you'd be wasting money by throwing it away and starting over.
        The fallacy behind starting over is that the prototype is a code mess and the rewrite will be clean. Forget it. If you're no good at refactoring and organizing code then the rewrite will end up a mess too. And if you are good at it, you should apply those skills to the prototype!

      • Re: (Score:3, Funny)

        by gnud (934243)
        The simple solution to this problem is using GPL code in your prototype. Then management won't let you ship until you've replaced it with something else =)
  • by aurelianito (684162) on Tuesday November 04, 2008 @08:08PM (#25634909) Homepage Journal
    AFAIK, you can access a DB via both JDBC and Hibernate. Just do most of the job with the frameworks and just the little bit that isn't supported use plain JDBC.
    • by MBCook (132727) <foobarsoft@foobarsoft.com> on Tuesday November 04, 2008 @08:48PM (#25635369) Homepage
      Not only can you do that, if you want to keep things simpler (stay in the same transaction, for example) Hibernate can run native SQL queries in addition to HQL. You can code your own queries but still have the hibernate call return a full managed object that you can do the normal Hibernate magic on.
    • by syousef (465911)

      AFAIK, you can access a DB via both JDBC and Hibernate. Just do most of the job with the frameworks and just the little bit that isn't supported use plain JDBC. ...or if appropriate another tool (eg. report generation tool).

    • by swillden (191260) <shawn-ds@willden.org> on Tuesday November 04, 2008 @11:03PM (#25636217) Homepage Journal

      AFAIK, you can access a DB via both JDBC and Hibernate. Just do most of the job with the frameworks and just the little bit that isn't supported use plain JDBC.

      Actually, Hibernate gives you a range of options. You can:

      • Construct SQL queries and let Hibernate map the results into objects [hibernate.org].
      • Construct SQL queries and get the results as arrays of scalars [hibernate.org].
      • Bypass Hibernate completely and just operate on the raw JDBC connection. Just make sure you flush the session [hibernate.org] first if you're querying DB state that the session might have modified recently, and clear [hibernate.org] the session cache if your JDBC calls might have modified data that the session has cached.

      Hibernate is successful in large part because it gives you a lot of options, so you can adapt it to your needs.

      • Re: (Score:3, Interesting)

        by timewasting (1230064)

        Wow, someone who actually knows what they're talking about when posting here. That's kinda like someone RTFA.

        Hibernate is good by me, though I've enjoyed using Kodo/BEA/EJB3.0 in the past for OR mapping as well. Even old school JDBC in session beans is often good enough for most things.

        Personally I usually hate Spring IOC because all of the simple compile-time problems with typos and capitalization on imports turn into runtime configuration problems because those typos now exist in one of 500 random XML f

  • by puppetman (131489) on Tuesday November 04, 2008 @08:09PM (#25634933) Homepage

    It's starting to look like I would have saved myself a whole lot of time if I had written the database transaction using JDBC instead of Hibernate

    Hibernate is great most of the time, but every Hibernate application I worked on had some JDBC somewhere, and I typically managed my own transactions... With regards to object-hydration, Hibernate (2.x) was an all or nothing, and sometimes I needed something in between for performance reasons.

    Obviously, I don't know the problems you face, but I am surprised that a flexible framework like Spring isn't meeting your needs, and that Hibernate is preventing you from using JDBC...

    • by Shados (741919) on Tuesday November 04, 2008 @08:33PM (#25635215)

      This is indeed the best advice. No framework will ever meet 100% of requirements. So you either use extensible frameworks, or have a facade that allow you to pipe logic either through the framework, or through custom code, as needed, allowing 90%+ to go through the framework, and the last 10% to go through whatever you wish.

      A lot of ORMs (I'm not as familiar as I wish I was with Hibernate) will allow you to use the standard dynamic SQL generation, AND to do stored procedure wrapping and projections... With that, you seriously can do pretty much "anything", except for using the very very latest features of the very very latest version of your RDBMS of choice, such as unsupported datatypes. For the 2-3 queries in the entire app that ends up in that situation, you simply have a custom data manipulation layer (small, not very heavily architected), and both that and the framework just sit behind whatever abstraction facade one may have...

      I also agree with the other part of the advice.... Spring not being powerful/flexible enough? When you have what is basically a "meta-meta-meta-meta-extensible framework" (which is basically what Spring is), its hard to see that something could possibly need features that cannot even be met using all of Spring's extension mechanisms...

  • Assuming your employer allows it, why not take the time you might have spent recoding and contribute and add the features you need to some of the frameworks/toolkits you are using?
    • Generally the conversation would go something like:

      you: hey boss, can I improve Hibernate to do what we need it to do on this project and contribute the changes back to the project?

      boss: sure, as long as you finish this project first and don't do any of that during work hours you can contribute back whatever you want.

  • Wrong Question (Score:5, Insightful)

    by pete-classic (75983) <hutnick@gmail.com> on Tuesday November 04, 2008 @08:10PM (#25634957) Homepage Journal

    You should be asking, "Should I make architectural decisions before or after I collect all the requirements." But you know the answer to that one.

    A more experienced engineer would have dug for requirements early, planned for some creep, and would have warned the manager that the risk of starting before the thing is properly speced is that all work might have to be thrown away.

    You'll know next time.

    -Peter

    • Re: (Score:3, Insightful)

      by chromatic (9471)

      A more experienced engineer would have dug for requirements early....

      Seriously, has that ever worked for you? (I assume you don't work on space probes.)

      • Re:Wrong Question (Score:4, Interesting)

        by pete-classic (75983) <hutnick@gmail.com> on Tuesday November 04, 2008 @09:06PM (#25635513) Homepage Journal

        Has digging for requirements ever worked for me? I'll say! You must be doing it all wrong!

        Maybe I don't understand your question. Are you asking if digging for requirements has turned every project I've touched into a paragon of ahead-of-schedule under-budget success? Certainly not.

        But I have headed off innumerable problems by asking probing questions, clarifying what the customer wants (in his head and mine) and, thereby, minimizing dead-ends and unacceptable implementations.

        And sometimes I get slapped down. And sometimes that causes over-runs and schedule slips. And when that happens I know that I've done my job . . . and I make sure my boss knows it, too.

        Never worked on space probes, but I have worked on satellite set top boxes!

        -Peter

    • Re:Wrong Question (Score:5, Insightful)

      by syousef (465911) on Tuesday November 04, 2008 @08:30PM (#25635187) Journal

      You should be asking, "Should I make architectural decisions before or after I collect all the requirements." But you know the answer to that one.

      That's harsh. I've seen the business change it's mind to the point that all that was kept was the project name (and wonder why it couldn't be delivered on time). I've also seen changes driven by legislation or changing business conditions that could not have been predicted. You can't dig for what ain't there. What you're asking him to do is be a fortune teller. The best he can do is try to improve relations and communications with the business, and let them know that the more things change at requirements level, the more time will be required.

    • Re: (Score:3, Insightful)

      by Sloppy (14984)
      In the real world, you never "collect all the requirements." That's just plain impossible.
      • Re: (Score:3, Interesting)

        by pete-classic (75983)

        Sure. There are always going to be eleventh hour changes. But generally speaking, a reasonable requirements miss isn't going to cause a database architecture to go from being the best choice to making the project impossible. That's a huge miss that is partially the developer's fault.

        Maybe I'm wrong, but this sounds like a clear case of cowboy development to me. Maybe it wasn't, but this is what cowboy development gets you in any case. If he keeps doing the same things he's going to keep getting the sam

    • Re:Wrong Question (Score:4, Interesting)

      by CorporateSuit (1319461) on Tuesday November 04, 2008 @08:37PM (#25635259)

      would have warned the manager that the risk of starting before the thing is properly speced is that all work might have to be thrown away.

      One thing that is not taught in schools but learned "on the battlefield" is the instincts of when a project is going to go bad before it starts. You can simply smell it on the proposal or project schematic.

      Until that's developed, you have to live with damage control. I always suggest to new guys, who deal with management or clients, what I used to say when something like this would happen: "Sure, it can be done, but we'll have to extend the deadline a few (days/weeks/months), and it will be expensive to add that since we'll have to change our [blah blah blah, you said the word 'expensive' so they're no longer listening. They're thinking. Once their eyes refocus, stop talking and ask them for their final decision]."

      They don't care how difficult it is or how many bugs will be introduced by cramming foundational changes in at the last second. They care about deadlines and money. You tell them that both will be sacrificed for some unneccessary feature creep, and you'll start seeing some managerial decision making instead of simple managerial delegation.

    • Re: (Score:3, Insightful)

      by mveloso (325617)

      Well, that's the wrong question as well. Only in highly structured environments can you collect all the requirements. And in those highly structured environments (ie: government, military, public safety) how many software projects come out meeting the requirements, are on time, and on budget?

      The answer is probably very small. In fact, I'd guess that the only things that a highly structured development process gets you over a fast, iterative and mostly loose process are (1) CYA material, (2) aggravation, and

  • by gdeciantis (570658) on Tuesday November 04, 2008 @08:12PM (#25634973)
    Ok first, reusing code is very important. You can get a lot of gains out of code you can borrow/steal from some other place. BUT, code you can't change is rigid (by definition) and will make your life difficult. We used hibernate for one of our projects and I am regretting that decision as well because it brings its own host of bugs that are impossible to fix unless you know how to alter the hibernate code, which means you need to merge with the main branch, but then you must get approval, and the cycle is really awful. If we had built an abstraction between us and hibernate we could swap it out for another ORM technology, possibly even a homegrown one. Would I write that abstraction layer twice, probably not. Would I replace hibernate with something better, absolutely. That may not mean I build it myself, I might buy it from someone and that is a whole different kind of question which is much much harder. So should you reuse code, YES. But only if it is well tested code that you change if you need to. If it isn't, then you should be able to swap out what you grabbed for something better.
  • If you separate out your database code from the interface code then it would make things a lot simpler when it comes to changing the back end.. it shouldn't matter whether you've written it yourself or been using libraries because you'll only have to make changes in one place, and it should be easy to fire through it without too much hassle (unless you're switching to a new database system that has specific SQL quirks in date handling/binary blob handling or that kind of thing).

    Personally I've never gone wi

    • by syousef (465911)

      Personally I've never gone with frameworks though.

      Yes you have, unless you've written everything down to the database driver and comms layer. You just don't seem to understand that you've chosen a layer at which to employ a framework. JDBC is a framework too.

  • lock in the requirements early, damage control the creep, and make sure your meeting attendance roster doesnt start including more useless management than is really necessary. ive been screwed by managers from departments ive never even heard of before.
  • You have two choices: Read someone else's code and documentation, or write it yourself. Sometimes the act of learning someone else's code is almost as much work as writing the stuff yourself. The nice thing about writing the code yourself is easier to modify, and extend. The act of writing code makes you remember what you did whereas learning someone else's code doesn't always let you remember every nuance. I catch slack from my friend who disagrees with me, but whenever I have the ability to code somet
  • by 1155 (538047) on Tuesday November 04, 2008 @08:20PM (#25635051) Homepage

    I don't get it. About 2 years ago this post wouldn't have even been front page worthy, and now we have this? If I wanted to use slashdot as a howto forum, I wouldn't be looking here. I just don't get it, why would a post list this make it to front page? It's for nerds, but it doesn't matter except to a small minority, and it's not news.

    Or am I missing something?

    • Re: (Score:3, Insightful)

      by geekoid (135745)

      Apparently you weren't here 2 years ago. These kind of question have been appearing on the front page for 10 years.

    • by raftpeople (844215) on Tuesday November 04, 2008 @11:26PM (#25636309)

      On Wednesday we'll have: "I coded a project, and now it's all done, should I start another project?"

      Thursday's topic: "A lot of people around me use the tab key but I like to key in exactly 3 spaces for indentation, who's right?"

      And on Friday: "I...uuuuh...well....oh, have you ever hit refresh but the web page said it couldn't?"

    • by blank axolotl (917736) on Wednesday November 05, 2008 @01:58AM (#25637019)

      it doesn't matter except to a small minority

      Then why are there over 200 comments, more than usual? Good programming practice is an interesting topic for many of us.

      • Re: (Score:3, Funny)

        by johannesg (664142)

        it doesn't matter except to a small minority

        Then why are there over 200 comments, more than usual? Good programming practice is an interesting topic for many of us.

        Maybe it is just a boring day? Nothing of interest happening in the world?

  • by syousef (465911) on Tuesday November 04, 2008 @08:21PM (#25635063) Journal

    In general it does depend on what application you re-use. If you reuse a poor piece of software you're building your product on shaky ground.

    Now I actually don't like Hibernate and Spring all that much and I use them regularly. Replacing a whole bunch of boiler plate code with a whole bunch of boiler plate XML doesn't actually make your app less error prone. Introducing AOP makes it easy to code cross cutting concerns but can make it hard to debug and understand code as it becomes harder to trace (and instead of a pure stack, you again have to look at XML configuration). Then there's the massive overhead. I'm afraid their popularity is due to software as religion pushed by a culture of marketing, rather than being based soley on techical merit. Hell a few years ago EJB was the word according to Bob, and we all saw how well that went. Try finding a new project actively deploying EJB today.

    That said, I've run into the limitations of those products, especially hibernate, and if your scope has crept enough that they were looking like a good solution, but aren't anymore, you need to address the scope creep first. Some creep is expected, and accomodating the business is always a good idea if you can manage it, but people go too far and forget that sufficient scope creep can and will make your project fail. You need to start by talking to the business and ensuring they have an understanding that the more redesign they do after the initial planning the greater the cost and risk. One other thing to watch out for. Make sure you evaluate whether each request is technically possible in the first place, and whether it is practical to attempt what has been asked with the resources you have. (I've often seen business people make requests without understanding the technical effort required. eg. request a change requiring a full blown compiler be written when the component was suppose to be a very simple parser and was scheduled to take 2 weeks to code. That's not entirely their fault. YOU are the technical staff and need to help them understand what is involved in fulfilling their request.).

    Once you've addressed the scope creep, look at your application again and re-evaluate the tools. It may be possible to divide the project in such a way that you retain Hibernate and Spring for one part (and let's face it they're the defacto industry standard and are going to be the easiest to support in the short to medium term. Long term is harder to predict, but the less popular an approach is the harder it will be to find someone appropriate to maintain your app). The other part you can do with raw JDBC or another tool. (eg. you might find it's the reporting that Hibernate isn't dealing with adequately, so move to JDBC or a reporting framework that takes RAW SQL queries).

  • I have now done a few projects now with Hibernate, JSF Netbeans 5.x-6.1 and can feel your pain. I ran across some HUGE bugs and issues that if I would have just done it with JDBC it would never have shown up. Having said all that once I got through the bugs and did some workarounds (Sun support sucks), it is a lot better. I still wouldn't use Hibernate JSF and Netbeans for everything but it doesn't totally suck.

    Here are some high level things that might help.
    1. If you have a relationship between classes

    • by syousef (465911)

      I have now done a few projects now with Hibernate, JSF Netbeans 5.x-6.1 and can feel your pain.

      Mainly talking about Hibernate here. It's always good to hear you're not the only one. When I was learning this stuff (having come from different languages and frameworks) I always felt like I was somehow "not getting it" because things that should've worked easily broke or couldn't be done at all with the framework. As I've become more experienced and my experience has grown, I've realized that these frameworks

  • I tend to turn to the math when this problem presents itself.

    I`m a programmer.. not a project manager.. but I can still usually put some kind of approximate number on the time it's going to take me to write from scratch (or re-write) vs. adapt/hack a lib into what I need.

    Factor in deadlines, maintainability issues, support issues, sanity, the phase of the moon, the flacid length of my firehose at room temperature .. and I have my decision.

    As a side note, I don`t know what specific problems your having.. but

  • This is what I come up against. You're fine with off the shelf stuff as long as the requirements match (and continue to match) the design of the product you're working with. The more it differs, the more you find you have to spend time learning the ins and outs of the product you're working with. This can get to the point where sometimes it'd be quicker to write it from scratch yourself than learn the product inside out.

    The balance I try and meet, is to choose lots of smaller off the shelf components rather

  • Code reuse is a nice goal, but it's hardly the core definition of good software engineering. Code reuse is a benefit that arises from good design; code reuse as a goal unto itself is little more than wasted effort driven by cargo-cult misconceptions.

    The thing most people overlook is that for code to be reusable, it must first be ... usable. Code has to be well defined, well designed and well documented in order to be usable and thus reusable. Sure, you can reuse it even if it fails those qualifications,

  • ORM has it's own problems for database run applications. It adds alot of overhead to the amount of data you have to load when you could be customizing your queries to each method that has to call the database and just have the class instantiate a DB object instead. Is this a little more work? Yes. Is this more scalable? Definitely. Is this 'messier'? Depends. I abstract the sql into a separate database layer so it isn't even included in the functions; that way the DBA can mess with the database queries as m
  • Understand who to mitigate creep, get sign offs on changes Including time changes and architecture changes.

    Creep is fine, just be sure someone signs off on the details.

    If they won't, don't change your work.

  • The more you build on top of something, the more solid the base should be.

    If your own stuff is just a few thousand LOC, it does not matter that much if you are locked into a particular framework. You can still do it again with another framwork.

    However, if you investment is a major one, you better roll your own or use something rock solid, that even has different implementation with a similiar API or functionality, like a database or script interpreter.

    And when in doubt, roll your own or built an abstraction

  • "The new requests coming in involve capabilities "

    Any project should start with a complete specification of the final product. Yes I know, I also have IT and non-IT partners who DO NOT/CAN NOT/WILL NOT understand this, and then technically pay for every rewrite one way or the other.

    Well, just my 2c. When you require at least an outline of WTF they WANT, this happens to you less and less. When you explain it to them for the 50th time, that it will take SERIOUSLY LONGER to modify something, than plan for it i

  • by xdroop (4039)
    Coder digs hole, asks for comments on different shovels and other holes; film at eleven.
  • by Anonymous Coward

    Unless your employer pays you to reuse code, you should always code it yourself.

    Look, the man is sticking it to you. You know it. I know it.

    Let's stick it to da man. Code your BIOS, your OS, your framework, your driver, and your app. It's fun. It's profitable. Your doges will love you.
    Your wife will love you. In Alabama, your sister will love you.

    Reusing code is for wimps.

    When is the last time your review mentioned code reuse?

    Come on. We are paid to create things!

    God said, be fruitful and multiply. He didn'

  • by nick_davison (217681) on Tuesday November 04, 2008 @09:20PM (#25635605)

    You gain efficiency by understanding a feature set and picking the right tools to do that job.

    The problem is, most people/organizations desperately want to build something now, so they feel something's happening, then keep tweaking it all over the place until they're happy, totally changing the spec once it's underway.

    In short, they want you to do the job in order for them to then understand it - making it nigh impossible to select the right tools at the beginning.

    Most of the really great, really efficient systems are built by someone who had a firm idea, figured out all the aspects, then got on and built just that. Or they played with ideas, building multiple prototypes that likely weren't very efficient, then went back and rebuilt it with what they'd then learned.

    Most systems aren't like that. They're designed by committee who won't think through most issues until they see a working version. They essentially force prototyping on you - yet consider what you're building the final system and won't pay for you to do a final rebuild. As a result, they're bloated and suck.

    Welcome to the real life of a programmer. Yes, code re-use is something great programmers do. But only if they have great designers who really think everything through first. If you ever find such a mythical beast, let me know and I'll be clamoring to work there too.

    • by julesh (229690) on Wednesday November 05, 2008 @07:51AM (#25638559)

      The problem is, most people/organizations desperately want to build something now, so they feel something's happening, then keep tweaking it all over the place until they're happy, totally changing the spec once it's underway.

      Actually, if it's done right, that's the best thing to do. Why? You produce a first release _quickly_ without having to worry about the features that are several versions down the line. That release is adopted and the customer starts actually using it. Whatever happens, they're now actually getting the benefit of having the useful software that you have written for them.

      And sure, they might decide that it's wrong in some critical respects. But at least they have _something_ to work with while you're making the changes they requested.

      Most systems aren't like that. They're designed by committee who won't think through most issues until they see a working version. They essentially force prototyping on you - yet consider what you're building the final system and won't pay for you to do a final rebuild.

      I've never had a client who expects to get free changes to the working software I've delivered that meets their original spec, even when they decide it's not what they wanted. Well, OK, there was one. But the court agreed with me and made them pay up. That's in over ten years of professional software development. I've had clients who ended up with bills nearly double what they originally expected, but they've paid happily because they knew I delivered their original requirements, but those requirements changed. They know I charge per feature developed, and I always make sure they know before I start work on it what each feature will cost. Generally speaking, they're all happy with that.

      Yes, code re-use is something great programmers do. But only if they have great designers who really think everything through first.

      Some of the best code reusers I've come across are agile developers who espouse not thinking through anything beyond the feature you're working on at the moment. Reuse doesn't require ahead-of-time design, but it does require a lot of attention to detail. In the OO world, it requires a good understanding of design patterns (which means when not to use, as much as it does when to use them). It requires the ability to understand what your code is doing in great detail, and to hold a large chunk of that information in your head at once, to enable you to spot where another piece of code is doing something similar to what you're trying to do now. It requires you to have sufficient confidence to rework that old code to better fit its new application, where necessary (which normally means you'd better have good test coverage of it). But it doesn't seem to require you to identify the opportunities for reuse in advance.

  • by benow (671946) on Tuesday November 04, 2008 @11:51PM (#25636461) Homepage Journal
    There are arguments for each.

    Reuse:

    • great choice for things done well, or for things not understood
    • reuse means for more maintainable code. It'll be far easier for another developer to come in and help out.
    • more stable and optimized
    • saves time (and, possibly, money)

    Homebrew;

    • great if you have time and dedication
    • you'll learn alot, which will help you with future evaluation. You'll also become a better coder.
    • your solution will fit the situation exactly

    The reasons behind reuse should make it your first choice, but at the same time, it's hard to be a great coder without coding. Turn that desire to code loose on the situations where the existing approaches are insufficient.

  • by Animats (122034) on Wednesday November 05, 2008 @01:10AM (#25636827) Homepage

    There are some advantages to libraries over frameworks. (Working definition: if you call it, it's a library; if it calls you, it's a framework.) Frameworks are great if your problem fits into the model defined by the framework. Since many web applications are rather standardized, that covers much of web development.

    The real problem with frameworks shows up when you need more than one of them in the same program. You can usually use more than one library, but using more than one framework is at best painful and often impossible.

    It's annoying when something which could have been implemented as a library is architected as a framework because frameworks are "cooler" than libraries.

  • Hibernate (Score:3, Informative)

    by countach (534280) on Wednesday November 05, 2008 @01:51AM (#25636985)

    Are you sure you can't use Hibernate? It has a lot of hooks. At least tell me you've read the book by the Hibernate author. I think you might regret bailing on it. Harder requirements need better tools to get the job done, not crappier tools like JDBC.

  • by Qbertino (265505) on Wednesday November 05, 2008 @04:29AM (#25637715)

    ... I'd say don't programm anything yourself unless you are abolutely sure it doesn't exist in some form of lib or class. Programming in Java is a PITA as it is, and it's whole point is that you don't have to build anything yourself.

    In fact, Java is nearly not at all about programming but about reading docs and integrating libs and classes that provide the code you need. It's OOP Forte with the brakes removed, and one of the reasons it's considered to be so outright boring. That's why there are so many thriving alternatives such as PHP or Python, so that people can get a chance to do some result oriented coding.

    You are in Java territory allready and Java now is free (speech) aswell, so continue to play the Java game and learn as much as you can about it by integrating existing code. Java-style research, doc-reading and OOP knitworking is tedious but in the end it'll pay off. Especially if you plan to advance in an suit-style big-bucks IT career. There's a reason any other PL can't get by OOP and/or the Java way of doing things beyond a certain point if they want to be taken for granted.

    To go even further, I'd actually look into UML editors and CASE-Tools once you know your way around Java, as these are the most advanced in the Java world and mark the point beyond which Java loses its pain factor. I find JBoss and jBPM BPEL [jboss.org], JPDL [jboss.org] and GPD [jboss.org] particularly interesting. (If you allready feel sick reading those abrevations, then you know why a large part of me still avoids Java whenever possible :-) )

    My 2 cents.

  • Framework != reuse (Score:4, Interesting)

    by famebait (450028) on Wednesday November 05, 2008 @06:06AM (#25638099)

    Lots of good advice already, but I want to add one thing:

    There is a difference between frameworks and other libraries.
    Libraries are a no-brainer; you just don't go and write a
    replacement unless you have very weird requirements.

    But frameworks tend to dictate how your app is structred,
    and to some degree even what it does, and that can be severely
    limiting. Frameworks vary in how easy it is to deviate from
    the assumed flow of things, but you can indeed find yourself
    spending a lot of the time fighting a template that just
    doesn't fit your task.

    Before you drop it, especially if it is much respected
    by other good developers, make sure you really understand it
    and what freedoms it does offer you. But if you discover
    it simply has a different goal than you, the sooner you
    get out the less waste you have to grieve about later.

  • by smartin (942) on Wednesday November 05, 2008 @09:34AM (#25639145)

    Where possible, you should never expose your choice to use an underlying technology. Instead wrap it in an Interface that exposes the functionality that your application requires and hide the implementation from the rest of your work.

news: gotcha

Working...