Discussions

News: Software Reusability: Myth Or Reality?

  1. Software Reusability: Myth Or Reality? (43 messages)

    Arash Barirani has posted "Software Reusability: Myth Or Reality?" on Artima, pointing out that J2EE programmers tend to start from scratch on most projects, even when working in similar domains. Is software reuse a myth, then?
    "...oh we'll write it from scratch and we'll get to know it inside-out..." , a tech lead once told me when the decision came up on whether to rewrite or reuse a component. And there is a lot of truth in what he said. With deadlines looming over our shoulders we do our level best to write code as fast as possible. We do our level best to make it modular and reusable. But somehow when time is up for a new project we always opt for a rewrite from scratch. It just seems so much easier to reinvent the business application than to reuse parts from an existing application. Why is that? I just don't know—this is simply career-long experience so far. Having meditated over this for several years here are my top reasons why reusability is more of a myth: 1. Business modules are not always well-documented and currently-updated. Most of the time the engineers rely on the JavaDoc as the sole form of documentation. So when the time comes for a new project, it is always easier to "rewrite" than to "reuse" as there is, for most part, very little "currently-updated" documentation around. 2. Lots of times the original engineers that worked on a project move away to other—hopefully better projects—or they just get promoted to CTOs, or even win the lottery by getting hired by Google... Then, in turn, the new less experienced engineers that take over will always opt to re-build from scratch; and rightly so—since it is so much easier that way. Here are my two top questions on reusability: 1.Is reusability something that one can train for? Is this something that can be taught in school. And I am not talking about writing a project and then reusing the same project for the next assignment. What I am talking about is reusing something that someone else has written for the same domain but a different application. You see that is so different than re-using the previous project to build the next programming assignment—it is more real-life. Building over a previous project that one has written is not so much training for reusability since one knows all the parts inside out. 2. Is reusability for key business objects and application modules a concept that has to be dictated as a requirement?
    SOA's supposed to address this to some degree (at the very least!) but if reusability itself is such a novel idea, SOA might be less of a silver bullet and more of yet another killer technology that died on the vine, if you'll pardon the mixed metaphors.

    Threaded Messages (43)

  2. Frameworks[ Go to top ]

    As the frameworks like J2EE provide more and more functionality, the potential for reuse in your code becomes less and less. This is a good thing. In an ideal world you really should only be writing new, unique business logic in each new application.
  3. While it's good to focus on the production side of the reusability equation, I personally think more attention needs to be paid to problems on the consumption side. For example, two of the more prevalent barriers to reuse that I've seen in recent years fall on the consumption side: 1. many developers either don't think or don't know how to find existing solutions to a problem before implementing one themselves 2. a decreasing (but still significant) number of developers have "not invented here" syndrome Referring back to the questions posed in the article, I think both of these problems are amenable to better training / education (ideally as early as possible in a developer's career, before they've become a crusty old curmudgeon).
  4. I think both of these problems are amenable to better training / education (ideally as early as possible in a developer's career, before they've become a crusty old curmudgeon).
    I totally agree. The issue raised by the author has the same root as the rest of the problems we see in Software Engineering today: more than questionable competence of the programming masses. It all boils down to the competence and abilities of the software engineers who design and implement code. Even if a particular service/component/module is _supposed_ to be reusable, you can hardly expect it to be truly useful outside the original application it was written for - if it was written by incompetent programmers. I hate to say it, the majority of programmers today are really bad. It was like that years ago - when Edsgar Dijkstra wrote that at least 90% of all SEs were incompetent. I am afraid, it is much worse today since the general demand for programmers has increased significantly since then, and absolutly talentless unmotivated people rushed into the software field. For the same reason, incompetent programmers don't bother reading documentation or studying existing solutions. Such people don't read industry articles, they stay on the same project for as long as the company keeps them, and have no idea what new technologies and methodologies have emerged since the last time they looked for a job. It's a shame. You can't expect people like that to write reusable code, neither can you expect them to be keen enough to see the value in existing reusable components. So, I believe, the premise of the article is somewhat incorrect. Yes, most of the software is not exactly reusable: due to the incompetent implementation, or poor/missing documentation, or, most often, both. However, it does not mean that there is no value in creating reusable code entities. Personally, I constantly get to reuse the components, classes, and libraries I have written for previous projects. I always take an extra effort to structure and document my code well - even if for my own sake. It helps me to get the current job done faster and better, and often makes it easier to implement new solutions using the building blocks from the previous projects. At the very least. I, for one, extremely value - and always promote - code reuse.
  5. I think both of these problems are amenable to better training / education
    I'm afraid not. Many focus their studies to get the grades and get the whole thing over with and start earning some money. Let's just say many people suck, whether they are lousy programmers, lousy managers, lousy politicians or lousy :)
    I hate to say it, the majority of programmers today are really bad. It was like that years ago - when Edsgar Dijkstra wrote that at least 90% of all SEs were incompetent. I am afraid, it is much worse today since the general demand for programmers has increased significantly since then, and absolutly talentless unmotivated people rushed into the software field. For the same reason, incompetent programmers don't bother reading documentation or studying existing solutions. Such people don't read industry articles, they stay on the same project for as long as the company keeps them, and have no idea what new technologies and methodologies have emerged since the last time they looked for a job.
    I blame the invention of drag and drop and wizards, enabling monkeys to get a head start of people who set up a project in a way that it doesn't come crashing down after two releases. ;)
  6. I have the biggest one...[ Go to top ]

    I think both of these problems are amenable to better training / education


    I'm afraid not. Many focus their studies to get the grades and get the whole thing over with and start earning some money. Let's just say many people suck, whether they are lousy programmers, lousy managers, lousy politicians or lousy :)

    Precisely, that's what education is all about... educating ! Shall we just stop teaching because "many people suck" ? C'mon... This thread looks like a d... contest ! Look at yourselves, the "top nutch Software Engineers" ! Bullshit. Please, get us Rolf Tollerud back... at least he was funny ! Cheers Remi
  7. Precisely, that's what education is all about... educating !

    Shall we just stop teaching because "many people suck" ?

    C'mon...
    In some schools they teach people to read as well. Read my post again and see where I blame education for educating.
    This thread looks like a d... contest ! Look at yourselves, the "top nutch Software Engineers" !

    Bullshit.

    Please, get us Rolf Tollerud back... at least he was funny !

    Cheers

    Remi
    Please stop being so funny, you're hurting me.
  8. In some schools they teach people to read as well. Read my post again and see where I blame education for educating.
    C'mon Eelco. Maybe you didn't think twice before posting, but read yourself again. Here's what you wrote : " I'm afraid not [education can produce better coders]. Many focus their studies to get the grades and get the whole thing over with and start earning some money. [...] many people suck [...] " Do I really need to comment more ? You seem to think that most students (and thereby future coders) are money-driven and don't pay any interest in what they learn. That they're just here to get a job, whatever it is, and work the less they can just to get paid at the end of the month. As a teacher at the university, I have a slighly different opinion. I also know quite a lot of students, PhD applicants and even professors that would really enjoy your statements about people's motivations... Last but not least, the worse is that you seem to think that "it's like that, that's just the way it is". I may be a dreamer, but I sincerely hope I can transmit my love for programming to others (and it can work : I've witnessed it many times).
    Please stop being so funny, you're hurting me.
    It's your oversized ego that seems to be hurt. Depending on the person, it can hurt bad, that's true. But I should probably consider myself as a "sucking money driven monkey", and stop trying to talk to such a clever person... it's probably useless and anyway I can't read, I'm way too stupid. Your life must be really great, with only assholes around you : you're the boss man ! I let you enjoy that comfortable and healthy situation, and stop spending your time. If I had only one advice for you : respect people, be humble, and don't think you're the smartest guy around. And have fun with your mates, ya know, the "monkeys" :-) Remi
  9. Re: I have the biggest one...[ Go to top ]

    It's your oversized ego that seems to be hurt. Depending on the person, it can hurt bad, that's true.
    But I should probably consider myself as a "sucking money driven monkey", and stop trying to talk to such a clever person... it's probably useless and anyway I can't read, I'm way too stupid.
    Your life must be really great, with only assholes around you : you're the boss man ! I let you enjoy that comfortable and healthy situation, and stop spending your time.
    If I had only one advice for you : respect people, be humble, and don't think you're the smartest guy around.

    And have fun with your mates, ya know, the "monkeys" :-)
    Remi
    Remi, I don't know what you teach your students, but I think the tone of your post is uncalled for, and it seems to me you are the only one who's trying to start a d*ck contest here. Even although Eelco's statement sounded exaggarated, there is no need to launch a personal attack. This thread is about different takes on code reuse, and nothing else. What Eelco and many others here are saying is that the value, efficiency, and reusablity of any piece of software depends on the quality of the software engineer who wrote it. I totally disagree that most CS students are motivated by future paychecks. However there are more than enough accidental "SEs" who have never actually studied CS, and many of them are indeed have absolutely no passion for what they do. I think we all agree that people like that give SEs a bad name. Such people exist, and there are way to many of them. Someone has written all that horrible code that's out there. That is why we are still discussing the very basics here. I wish they would spend more time and effort in schools cultivating the proper mentality among the CS students. I was lucky to have a couple of professors who taught us that having the piece of code that simply "does the job" is not enough. We got points deducted for little things like misnaming a variable, putting two different tasks in one method, etc. Those instructors always taught by a good example, even their hand-outs (not necessarily code, just text, etc.) where always very well-structured, and easy to read and grasp. But there were those who were quite sloppy, they would be all over the place on the subject, etc. I have known very bright students who always got the problem solved, but no one could read and understand their code. I am sure they went on to create software that worked - until the requirements change... and then, no one would know what to do to make it work again... I always think of Dijkstra in this context. Dijkstra, one of the greatest computer scientists of all time had spent most of his life promoting the idea that there is a direct corelation between the elegance and clarity of the code and the reliability/correctness of the software. That's an opinion of someone to whom we all should be listening. If you disagree, I don't think it makes sense to argue any further...
  10. Re: I have the biggest one...[ Go to top ]

    However there are more than enough accidental "SEs" who have never actually studied CS, and many of them are indeed have absolutely no passion for what they do. I think we all agree that people like that give SEs a bad name. Such people exist, and there are way to many of them. Someone has written all that horrible code that's out there. That is why we are still discussing the very basics here.
    Actually, bad code is kind of like mold. It grows while no one it looking. No one wrote it, it just kind of appeared. One day it was a shining example of the latest techniques and design patterns, ready to meet user requirements, the next it is an antiquated piece of incomprehensible junk. I think there must be a virus that infect all configuration control systems to make this happen.
  11. Re: I have the biggest one...[ Go to top ]

    Remi, I don't know what you teach your students,
    That's completely out of scope. The question is now *what*, but *how*.
    but I think the tone of your post is uncalled for, and it seems to me you are the only one who's trying to start a d*ck contest here.
    It simply pisses me off to hear such bullshit, hence the "acid" tone. And *I* don't claim to be better than anyone...
    Even although Eelco's statement sounded exaggarated, there is no need to launch a personal attack.
    I never did. The attack was grouped, and targeted at everybody in this thread screaming loud that "they know it better than everyone". Eelco's post was just the catalizer, and reading all this again, it was probably not the most frightening one. One guy said "hey but they're lamers", and then 10 others went on approving that... For sure, that must be the reason why code reuse has failed, if it ever did.
    This thread is about different takes on code reuse, and nothing else. What Eelco and many others here are saying is that the value, efficiency, and reusablity of any piece of software depends on the quality of the software engineer who wrote it.
    And we need 10 top level SEs to come to this "conclusion" ? Waow. A d... contest, I tell you ;-P
    I totally disagree that most CS students are motivated by future paychecks.
    I don't really understand how one could agree with that, and reading it was really shocking (especially from Eelco who I respect a lot for his programmer's skills btw - yeah I've had a good look at Wicket, but it's not the point right now).
    However there are more than enough accidental "SEs" who have never actually studied CS, and many of them are indeed have absolutely no passion for what they do.
    Sure, and the post I was replying to was very precise, the question was "can you educate them so they get better" ? I think so. Of course, you won't get 100% success, just because someone who does not like his job can't possibly get much better without involvement. But you can create atmospheres that increase the probability for it to happen. And thinking that people are mostly suckers is just the best way to fail IMHO.
    I think we all agree that people like that give SEs a bad name. Such people exist, and there are way to many of them.
    There always will be too many people you don't like. You have to deal with it, and you can change that most of the time. Instead of insulting them, I instead try to prove respect and kindness. After all, maybe they have other talents which I can learn a lot from.
    Someone has written all that horrible code that's out there.
    I did, and I still do. Otherwise I wouldn't even need to refactor anything : it would just be directly perfect, and... reusable ! You have so start somewhere. I bless script kiddies and sunday programmers : they help us (the professional developers), create markets for us etc. The fact that the average joe can open up Excel and kick in some VB is a good proof. It solves tons of problems, everyday. Hopefully Joe doesn't have to pay huge money to get the job done by a "SE" that sees his "client" as a "monkey" ! Maybe one day Joe will get to Java, start learning, find folks around to explain, and he'll become a professional developer.
    That is why we are still discussing the very basics here. I wish they would spend more time and effort in schools cultivating the proper mentality among the CS students. I was lucky to have a couple of professors who taught us that having the piece of code that simply "does the job" is not enough.
    You're actually proving my point :-)
    I always think of Dijkstra in this context. Dijkstra, one of the greatest computer scientists of all time had spent most of his life promoting the idea that there is a direct corelation between the elegance and clarity of the code and the reliability/correctness of the software. That's an opinion of someone to whom we all should be listening. If you disagree, I don't think it makes sense to argue any further...
    I never went agains that, I'm a KISS fan ! All I said was related only to the mentality some seem to have. It's completely opposite to the way I see education (and "mentoring", or trainings, with professional coders). Cheers Remi
  12. Re: I have the biggest one...[ Go to top ]

    Instead of insulting them, I instead try to prove respect and kindness.
    Well, perhaps if you calm down and re-read the thread (when you are less "nervous") you will see that no one here was insulting anyone - until you joined in. If this is what your idea of "respect and kindness" is, perhaps it's better if you find a different outlet to spew it the next time... Peace.
  13. You seem to think that most students (and thereby future coders) are money-driven and don't pay any interest in what they learn. That they're just here to get a job, whatever it is, and work the less they can just to get paid at the end of the month.

    As a teacher at the university, I have a slighly different opinion. I also know quite a lot of students, PhD applicants and even professors that would really enjoy your statements about people's motivations...

    Last but not least, the worse is that you seem to think that "it's like that, that's just the way it is". I may be a dreamer, but I sincerely hope I can transmit my love for programming to others (and it can work : I've witnessed it many times).
    Yeah, I was trying to be ironical. So much for that I guess. Of course not all students are like that and if you look at SE education, it is probably quite the opposite, and education usually is very well geared towards teaching people the proper skills that will last for a while. However, and this was my poorly expressed point, even though I don't think education is to blame here, we end up with a considerable number of lousy engineers. Nothing I can back statistically, just a feeling based on my own experience. Becoming a good SE takes a while (years), and takes an attitude of always wanting to keep improving one self. Formal education is just the starting point.
    Please stop being so funny, you're hurting me.


    It's your oversized ego that seems to be hurt. You:
    Please, get us Rolf Tollerud back... at least he was funny!
    Me:
    Please stop being so funny, you're hurting me.
    My attempt being ironical about the fact that your reply wasn't exactly funny either. I'm out.
  14. Eelco,
    Yeah, I was trying to be ironical.
    I realize I may have been pretty harshe myself, and you may have taken that personnally. It wasn't my intention. As I said in a previous reply, your post has just been the catalyzer : there are several posts in this thread that seem to carry that ugly, selfish mentality. And I often meet such people who really think they're better than the others. The fact that you used the "bad words", and that I was probably a bit nervous that day... I should have reworded my thought, I'm sorry if I offended you. Anyway, I think most of us agree in the end. Simply because we've probably been educated by good people that transmited this unvaluable knowledge to us... That's why it pissed me off to hear what you said, after I had read a few other posts stating that the failure in reusability (which I think never happened) is because of "monkeys" that claim to be SEs, most of the students being there for the money only, etc... was too much for me ;-P Cheers Remi PS : And I wasn't comparing you to Rolf Tollerud, it
  15. Re: I have the biggest one...[ Go to top ]

    BTW, the expression "code monkey" is not a derrogative term, that's how programmers jokingly refer to themselves. It is a very common lighthearted way we make fun of ourselves, and it basically implies a hardworking programmer who spends his day banging on the keyboard... That's all. You got fired up over nothing.
  16. Re: I have the biggest one...[ Go to top ]

    BTW, the expression "code monkey" is not a derrogative term, that's how programmers jokingly refer to themselves. It is a very common lighthearted way we make fun of ourselves, and it basically implies a hardworking programmer who spends his day banging on the keyboard... That's all. You got fired up over nothing.
    I don't know. It may have started out that way, it in some places it may still have that meaning, but I think it has taken on some sharp negative connotations.
  17. That's why it pissed me off to hear what you said, after I had read a few other posts stating that the failure in reusability (which I think never happened) is because of "monkeys" that claim to be SEs, most of the students being there for the money only, etc... was too much for me ;-P

    Cheers

    Remi

    PS : And I wasn't comparing you to Rolf Tollerud, it
    Peace :)
  18. Agreed but where is the real re-use?[ Go to top ]

    What you are trying to say is that packages are re-used but not user written software. Well, packages existed all the time... probably one didn't call them packages. Except that in Java pgms today one see a multitude of imports...Building blocks are package members... If one take an example from olden days, DBMS software was always resued for database access. User pgm contains just a call to the DBMS in a prticular format (IMS, IDMS, DB2, Oracle, Sybase... or any db). DBMS code changed without any change in the user program. Compared to today's Javaworld, one seldom got a 'deprecated message' on anything. Confusion and anrchy reigns the software world today. Software companies are adding to this confusion instead of reducing it by introducing irrelevant vapourwares like SOA! The amount of money a large software vendor makes is directly proportional to the confusion in the market! So all are happy!
  19. If one take an example from olden days, DBMS software was always resued for database access. User pgm contains just a call to the DBMS in a prticular format (IMS, IDMS, DB2, Oracle, Sybase... or any db). DBMS code changed without any change in the user program. Compared to today's Javaworld, one seldom got a 'deprecated message' on anything.
    Go back farther. There was a time when programmers wrote their "data access layer" themselves (ISAM!). A lot of that software is still around today. At a point farther back the same thing can be said for the OS.
  20. not a myth, reality[ Go to top ]

    The reality is that software systems are extremely large nowadays and mostly consist of code written by third parties. The average production of software engineers measured in lines of codes per time unit has not increased significantly over the past decades and it only takes a few to construct software systems composed of multiple millions lines of code they could not possibly write themselves even if they had decades to do it. I can't imagine writing any java code without importing at least a few dozen different packages. I can't recall the last time when I restricted myself to just the jdk packages for any significant software package. And that already represents quite a huge amount of software. What is a myth is that you will be able to reuse much of your own software. That's a myth because it requires accurate insight in future requirements, which if you had that would be the current requirements. Consequently most software you write is based around your current assumptions. If you are right, your software will become a commodity, if you are wrong it will undergo significant maintenance. Nobody makes money of commodities except Microsoft and a handful of others. In the open source community, commodities are free in all relevant interpretations of that word.
  21. Re: not a myth, reality[ Go to top ]

    The reality is that software systems are extremely large nowadays and mostly consist of code written by third parties. The average production of software engineers measured in lines of codes per time unit has not increased significantly over the past decades and it only takes a few to construct software systems composed of multiple millions lines of code they could not possibly write themselves even if they had decades to do it.

    I can't imagine writing any java code without importing at least a few dozen different packages. I can't recall the last time when I restricted myself to just the jdk packages for any significant software package. And that already represents quite a huge amount of software.

    What is a myth is that you will be able to reuse much of your own software. That's a myth because it requires accurate insight in future requirements, which if you had that would be the current requirements. Consequently most software you write is based around your current assumptions. If you are right, your software will become a commodity, if you are wrong it will undergo significant maintenance. Nobody makes money of commodities except Microsoft and a handful of others. In the open source community, commodities are free in all relevant interpretations of that word.
    +1. Even if you try really hard you won't get much reuse out of your own code unless you are designing very similar systems. There is also a point of diminishing returns depending on how well your sharded code is managed/maintained in your environment. I've noticed in companies with large IT departments that upgrading custom reusable components becomes an overhead issue quickly. If you look at how many 3rd party libraries the average project uses it is hard to argue that we as an industry are not reusing the majority of our code. It is just very hard to write reusable code that performs a specific business function, which is why most business apps do not share code.
  22. Its up to the kind of project...[ Go to top ]

    In my opinion, the decision whether to produce reusable artifacts or not is simply based on the kind of your project. Creating a reusable artifact requires a good design to ensure it's really reusable. This is a big question of time, money and manpower - things software development teams usually do not have. 1) If you develop a product, you better think about reusable artifacts to support your product lifecycle / product chain. It's the only way to deliver quality and competitive APIs. In that case you're the one who creates the timeline, pays the bill and hopes for revenue. 2) If you use your/a product to integrate into a customer's specification, you reuse the artifacts / API provided by the product. Then it's up to your customer to decide what level of code quality is required. If you use the product / artifact to build a (competitive) product or good quality, then goto 1) else 3). 3) In all other cases, reusability is a matter of time, costs and requirements (and your team skill). Robert PS: I hope, I do not need lessons in English ;)
  23. Re: Its up to the kind of project...[ Go to top ]

    Think about how much reusability you need at the first place. For example, a simple POJO class "Dog" could be reused by many different applications but it depends on what properties you need for the Dog. For example, "Employee" is an object that you create for your company. When you want to use the same object in other company, you just cannot because they might require two or even more properties and other behaviors. So you do abstract this employee and create specific subclass from this? but how do you know how abstract this "employee" has to be? A car engine has many components so you create a hierarchy of objects to build 3D Model. But do you think Toyota can reuse the hierarchy or those POJOs from Honda? I was thinking to have a web site that can make general objects GPLed and people can download these Objects for their use for free. They can even use the web services to make these objects available anywhere. But once I thought of reusability, I thought of a big question: how do you define one abstract object that is abstract enough for others to reuse?
  24. Re: Its up to the kind of project...[ Go to top ]

    Think about how much reusability you need at the first place. For example, a simple POJO class "Dog" could be reused by many different applications but it depends on what properties you need for the Dog. For example, "Employee" is an object that you create for your company. When you want to use the same object in other company, you just cannot because they might require two or even more properties and other behaviors. So you do abstract this employee and create specific subclass from this? but how do you know how abstract this "employee" has to be?
    Well, I don't think anyone argues in favor of reusing domain objects... They are application or organization specific by definition. Not a good example.
  25. Re: Its up to the kind of project...[ Go to top ]

    Think about how much reusability you need at the first place. For example, a simple POJO class "Dog" could be reused by many different applications but it depends on what properties you need for the Dog. For example, "Employee" is an object that you create for your company. When you want to use the same object in other company, you just cannot because they might require two or even more properties and other behaviors. So you do abstract this employee and create specific subclass from this? but how do you know how abstract this "employee" has to be?
    If you know, you might have to reuse your Employee in other projects later, you need to make a decision whether you have the time or budget to make it abstract. Would the customer pay for it? If not, it's an investion you have to do by your own. But only invest if you do not fail your 'initial' project and the result is worth for sale (you create a kind of product then). The second project must be shorter in time and budget then (except on license issues).
    A car engine has many components so you create a hierarchy of objects to build 3D Model. But do you think Toyota can reuse the hierarchy or those POJOs from Honda? I was thinking to have a web site that can make general objects GPLed and people can download these Objects for their use for free. They can even use the web services to make these objects available anywhere. But once I thought of reusability, I thought of a big question: how do you define one abstract object that is abstract enough for others to reuse?
    If you speak about providing domain entities (your 'general objects', somehow BPEL'ed) to a complex world, you need an abstraction representing the complexity of the world. This means, you create an exact copy of the world and that's neither possible nor helpful. On the other hand, you will engage SAP and the other EnterPrize-My-World companies.
  26. See, you are thinking of code reuse only from the standpoint of large components. I disagree with such point of view. A good software engineer should intuitively comup with modular - and, therefore, potentially reusable - code constructs on any level! It should be in your blood, if you were born to be a software engineer. I don't see it any other way. I try to reuse my own code on the level of methods and code snippets. If I see that a particular code snippet is used - or can be potentially used - more than once, I put it into a separate method. It helps me to better visualize my own solutions, it helps me and other people to read and understand my code. And it helps me to recognize and reuse theh code that can be re-used. Therefore, it makes my programming more interesting and pleasurable - for me, first of all. But as the result, it helps other people on the team to understand and use my code if they have to, or maintain it after I leave the project. If Computer Science students are taught to always look at things this way, on any level, at any stage of the project, chances are we will be seeing more truly reusable enterprise-level components. But, for starters, one should apply this mentality on the level of individual lines of code. Unfortunately, I don't see it happenning. Most of the code I see from project to project looks like it was written by people on acid...
  27. ... Most of the code I see from project to project looks like it was written by people on acid...
    Do not understand me wrong. I totally agree with you. Every line of code must be as clear as possible to any other developer reading it. At least, thats why I comment my code as a novel when lines grow. Often, I dig into source storages to learn and to raise the standards for myself (the ideal reuse!). As a typical example, you can look into the Jakarta Commons. The reason we often use these artifacts are their APIs (evolutionary good code, documented in the source code). These artifacts are reused in other top-level projects of Apache as well, which are highly reusable by themself. In the case of Apache, it's the standards and the OSS principle which allows to build reusable stuff in such a recursiv manner. What I learned from the commercial world is: time and money, first. Never mind whether you rewrite code everytime, unfortunately. Most times we reuse code in a commercial environment, we use OSS code or licensed API's. Everytime I wrote something reusable by myself (often based on reusable artifacts) in a standard customer project, I failed because of defending it against time and budget (maintainance is unlikely trivial in a commercial environment). I hate to produce acid code. But sometimes, your soul is sold to do a difference. Otherwise you're better be in developers heaven. OSS is a really good thing! Everyone supporting it, understands to keep the level high. OSS is the best we have to prove concepts against time and budget rates! Greetings from Berlin Robert PS: JBoss.org, please do invent Maven2! PPS: My wine is worth its money!
  28. See, you are thinking of code reuse only from the standpoint of large components. I disagree with such point of view. A good software engineer should intuitively comup with modular - and, therefore, potentially reusable - code constructs on any level! It should be in your blood, if you were born to be a software engineer. I don't see it any other way. I try to reuse my own code on the level of methods and code snippets. If I see that a particular code snippet is used - or can be potentially used - more than once, I put it into a separate method. It helps me to better visualize my own solutions, it helps me and other people to read and understand my code. And it helps me to recognize and reuse theh code that can be re-used. Therefore, it makes my programming more interesting and pleasurable - for me, first of all. But as the result, it helps other people on the team to understand and use my code if they have to, or maintain it after I leave the project. If Computer Science students are taught to always look at things this way, on any level, at any stage of the project, chances are we will be seeing more truly reusable enterprise-level components. But, for starters, one should apply this mentality on the level of individual lines of code.
    Yes! +1
  29. I think there are many different kinds of reusability. Open Source has increased dramtically reuse between projects. You tend to get the best of breed programmers working on these projects with amazing outcomes. If you need evidence of this when was the last time you wrote code to process SOAP/HTTP. Business components reuse and the whole concept of business components has never taken off. Mainly I think because these components are often designed in house and the quality of programmers/architects is poor with only one or two people having a clue.
  30. Myth++[ Go to top ]

    If you need evidence of this when was the last time you wrote code to process SOAP/HTTP
    When using Websphere 6.0.x and HTTPS.
  31. java.util.*[ Go to top ]

    Ever heard of the JDK's standard library? Anyone using Hibernate or EJB3? Anyone using jakarta commons, velocity, xstream? Was anyone using Xerces or Xalan? How about the regexp libs before jdk 1.4 came out? log4j? Code reuse outside of specific projects occurs once it is standardized, documented, and implemented, and works well. Now if you ask me if java as a language implements features that properly enable code reuse, then I would agree. Inheritance is not a sufficiently granular approach to object/class construction, given: - imposes an hierarchical relationship - java only enables one level of super. You cannot super.super.method() to access a method that has been overridden twice. Yes I have seen something where I needed it, and instead had to copy and paste the original implementation. - doesn't support mixins (or my version of mixins) Mixins (basically a function/method template) are essentially inherited methods. I propose something like this as a definition of an inherited method: public mixin SampleMixin { int somemethod(String p1, int p2) {   i1 = p1;   i2 = p2; } } What is the list? That allows a class that uses this mixin to map which instance variables in the actual class are used in the method. So an implementing class that uses this mixin: public class SomeClass uses SampleMixin { int someclassint; String someclassstring; int somemethod; } The "int somemethod;" declaration tells the class to map i1 and i2 to someclassint and someclassstring. This allows us to create objects by picking and choosing method implementations, without having to use inheritance which would force the inheritance of all the methods of the parent class definition. Interfaces really could do this too. Just expand the interface syntax with the notation already used for generics, and old interfaces should still be backwards compatible.
  32. Re: java.util.*[ Go to top ]

    Ever heard of the JDK's standard library? Anyone using Hibernate or EJB3? Anyone using jakarta commons, velocity, xstream? Was anyone using Xerces or Xalan? How about the regexp libs before jdk 1.4 came out? log4j?
    +1
    That allows a class that uses this mixin to map which instance variables in the actual class are used in the method. So an implementing class that uses this mixin:

    public class SomeClass uses SampleMixin
    {
    int someclassint;
    String someclassstring;

    int somemethod;

    }

    The "int somemethod;" declaration tells the class to map i1 and i2 to someclassint and someclassstring.

    This allows us to create objects by picking and choosing method implementations, without having to use inheritance which would force the inheritance of all the methods of the parent class definition.

    Interfaces really could do this too. Just expand the interface syntax with the notation already used for generics, and old interfaces should still be backwards compatible.
    Sounds a bit crafty to me... What's wrong with using the good old composition vs. inheritance?
  33. the author seems to be rolling several problems into one. there is clearly a lot of reuse amongst the J2EE community, the abundance of open source projects is testament to that. For example, most modern web projects are using a struts/spring/hibernate or equivalent (mvc/ioc/orm) type stack, and most will use utilities like quartz or jasper and be built using ant or maven. badly coded and badly documented coded is just bad practice, I've never met someone who would argue against the need for well laid out code and appropriate documentation, but I've met many who "can't be bothered". at the business domain level, the need to bring reuse into the equation is highly debatable. Sure it needs to be designed well so that it can be extended easily later if required; but there are strong arguments for starting with a simple clean set of objects every time. In the real world businesses making the same thing often do it with different attributes and processes; therefore when you model it your objects will be slightly different - you don't necessarily want to clutter it up with unused code. If you are a large ERP vendor then you can afford to build the mother of all objects for every entity imaginable - and you end of with systems that take just as much to understand and configure then if you wrote from scratch.
  34. If you are a large ERP vendor then you can afford to build the mother of all objects for every entity imaginable - and you end of with systems that take just as much to understand and configure then if you wrote from scratch.
    This discussion quickly slips into a spin that only demonstrates why code re-use is viewed as a "myth" by so many. Most folks think of it in terms of some kind of "mother of all objects" thing, whereas the mentality to code with re-use in mind should be enabled on a daily basis on the lowest level. Don't dream of creating a reusable component that will save the world. Start with creating microscopic reusable code snippets to get you daily job done. That, at least, will make you a better programmer, and your code will be better, your applications will be more flexible, configurable, and easier to maintain. Once that is in your blood, then, perhaps, one day you will be indeed capable of conceiving solutions like Spring, etc.
  35. Most folks think of it in terms of some kind of "mother of all objects" thing, whereas the mentality to code with re-use in mind should be enabled on a daily basis on the lowest level. Don't dream of creating a reusable component that will save the world. Start with creating microscopic reusable code snippets to get you daily job done. That, at least, will make you a better programmer, and your code will be better, your applications will be more flexible, configurable, and easier to maintain. Once that is in your blood, then, perhaps, one day you will be indeed capable of conceiving solutions like Spring, etc.
    While some succeed with this approach, in particular those with potent sponsors, hundreds of projects fail because of this mindset. Silver plated code is - along with madly hacked away code - the one single reason that makes projects fail on the programming/design level. In other words: Reuse is something you should do if there is a clear advantage of the reuse in the context of your current tasks unless your very task is building reusable software. Also keep in mind that reuse most of times makes things less error prone and more robust but not necessarily easier to understand and faster to implement. Reusability and good abstraction need not go hand in hand!
  36. Most folks think of it in terms of some kind of "mother of all objects" thing, whereas the mentality to code with re-use in mind should be enabled on a daily basis on the lowest level. Don't dream of creating a reusable component that will save the world. Start with creating microscopic reusable code snippets to get you daily job done. That, at least, will make you a better programmer, and your code will be better, your applications will be more flexible, configurable, and easier to maintain. Once that is in your blood, then, perhaps, one day you will be indeed capable of conceiving solutions like Spring, etc.


    While some succeed with this approach, in particular those with potent sponsors, hundreds of projects fail because of this mindset. Silver plated code is - along with madly hacked away code - the one single reason that makes projects fail on the programming/design level.
    Wow... No offence, but I think you just pulled those "statistics" right out of your ass... :) How can writing neat, clean, compact, well-documented, easy-to-read, modular code drive your project into the ground? I think you are confusing that with over-engineering for extensibility and compatibility with "future" systems/requirements that never come. It is very different. I have been programming for 20 years, and have absolutely no doubt by now that writing elegant thoughtfully designed code - on the lowest level - helps achieving the end results much, much faster! Your productivity grows almost exponentially. You spend some time upfront on thinking things through, code some basic building blocks, and - most importantly - apply micro-refactorings on a daily basis, as you move along, as soon as you notice that the code snippet could be improved with some advantage. And your job gets easier every day. It is a known fact that daily refactorings are the only refactoerings that are feasible and efficient. I ahve never heard of any successful massive "refactoring" efforts - after a messy project had already been almost completed. You do it as you go, or you drive yourself into the ground. There is no other way. The same goes for documenting your code. Don't put it away for later: you'll never do it. I often write a javadoc for a method before I have even written the method: it helps me to structure my thoughts and actually visualize exactly what the method should do. Often, when you start describing the method, you realize that you are intending to put one task too many into it. So, there you go, you extract that task into a separate method. That task becomes potentially reusable, and your code becomes more readable. Later, you may find that the method actually could be reused by other classes, so you refactor it into the subclass, or, perhaps create a new class, etc. That's what programming is about. You do things like that because you see how they make your life easier, not just for the sake of some meaningless "re-use". I absolutely despise the (unfortunately common) point of view that applying some extra intelligence to code design in order to make the code elegant, readable, etc. is somehow bad for the project, and negatively affects the deadlines. It is BS! There is never excuse for poor coding. The only people who defend it are lame programmers themselves. If you are capable of writing good code, you know the true value of that, and you know that it is indeed the fastest way to get the project up and running. I can't tell you how many times I have heard the same lame excuse: "Oh yeah, in the perfect world, I'd love to do things right, I'd love to use the true OO approach, I'd love to code to abstractions... but, unfortunately, we don't have time, and they [some bad guys, managers, customers, you name it..] want me to get something done right away, so I have to do hardcode everything and do whatever it takes to get things done..." In reality, he gets nothing done, for another year or two, he keeps turning in the code that is full of bugs, and the whole "sustaining team" works full-time for another year to find and fix those bugs. But each bug fix opens a whole new can of worms, more bugs... It never ends, the project NEVER completes, and finally gets cancelled. (True story... ;) I'm sure we all can think of a few projects like this...) The bottom line is that I have never heard a truly good SE using such excuses, while it is the common excuse for a lame developer.
  37. I think you are missing a mere simply fact: Good code is always good code in context. "Beautiful" engineered code can be extremely cumbersome to read. I wholeheartedly agree to aim for simplicity and (micro) patterns in daily coding practice as well for early documentation. No argument there. But I have seen dozens of projects that failed or were significantly delayed because of silver plating. In the end, a lot of customers care much less about the possibility for reuse than about meeting the deadline.
  38. I think you are missing a mere simply fact: Good code is always good code in context. "Beautiful" engineered code can be extremely cumbersome to read.
    Well, that's where you are completely misinterpreting what I have said. In my opinion, any code that is hard to read is not good code, and it may not be considered "beautifully engineered." I think what you are saying is that over-engineering for the sake of some questionable flexibility, performance gain, and/or reusability is bad, and I totally agree with you. My point was regarding the mindset that we all should be cultivating in order to be beter in our job. I have proven to myself many times that the more elegant, readable and reusable - on the micro-level - my code is, the easier it makes my job day after day, and I simply get things done faster with less bugs. It's not just my observation. Like I said, Edsgar Dijkstra had been trying to drive this idea into the minds of software engineers all his life, and the guy knew a few things about Software Engineering, he invented it. ;) Cheers, C
  39. Depending on what we are trying to reuse the answer will be different. Is it reuse of "technical libraries", "business objects" or "services" ? I think the blog talks about business objects. I have elaborated a bit on this subject i my blog Three different things to reuse
  40. i found most often we reuse very few code from previous projects. most of the code are concerned with specific problem of specific project... it is true sometimes when we find some module can be used in multiple project. we separate those module in a separate artifact. and our developers use it as 3rd party library. i found it is very rare case. i think Software Reusability is not a myth.. it is real. bcz now these days we are using many libraries from apache and other open source community. which is the sign of reusability and DRY... best regards,
  41. I agree - it's almost impossible, but possible to reuse domain objects in different projects. We use such pattern: if I need to use "User" object in a new project, I take existing one, extract superclass that confirms requirements of both projects and extend with new properties required in new project. But this pattern makes sence only if both projects live in parallel side by side and base class is really reused. When we talk about infrasturcture of projects, there is always wide field for reusing existing code. A soon as you can't live with code duplication (can you?), you will always generalize existing code and some pieces will organize a framework that can be reused not only inside current project, but also outside of it. We also have time pressure, but once a week or such it's possible to perform code reviews and make some refactoring. XP forces to remove code duplication just during coding, but it doesn't work for us - we prefer weekly reviews / refactoring when we ensure we have enough use cases for generalization.
  42. Reusability means all levels, we can reuse the existing project/module/class, even methods. It depends your requirement and decision.
  43. No architect would ignore perfectly good code and instead write code that provided the same functionality from scratch. The key feature is perfectly good code. When a software development effort is funded, the focus is typically on "getting the job done". The architect designs for reuse, but must balance that with cost and schedule, in which they generally have little control. So, on the front-end, coding for reuse is costly, It is, of course, important to code for reuse, but it is has diminishing returns for a project. On the back-end, coding from scratch is costly; however, when using existing code, regardless of its original design, reuse can become a hindrance rather than a benefit the farther from the problem the reused code is to be applied. As an example. an accounting package written for a company would probably be able to leverage existing code quite well if the company changes banks, adds a new class of worker, etc., but the accounting package would probably not be a good fit for another company because, although the problem set (accounting) is the same, the implementation details would no doubt different and would getting those business practices to work in a framework which was not designed to support them takes time, and effort, and the end result generally is a poor fit. When that poor fit is compounded with changes (new bank, new class of worker, etc.) it can become more and more of a hack rather than an elegant solution. And architects love elegance. There are two different types of differences that are generally not accounted for in "reusable" code: unforeseen, which were not taken into account by oversight (nobody's fault); and seen but intentionally not accounted for, due to cost, schedule, and lack of reason to implement such a solution with the funding for the project. In general, the more the code lives in the problem domain, the less long-term cost benefit in reuse. But, as I think we can all can attest, writing code has become more and more easy because of code reuse. As other have pointed out, general use packages, both part of Java proper and as standard add-ons (and well as a migration from one to the other, e.g., JAX) has made it easier for the Architect to focus on the problem at hand and less on the details of how to log messages, how to provide web services, how to deploy a web component, whatever. We all think our ideas are superior to others (why else would be be posting here?), but we are professionals. We chose to rewrite over reuse because, in the long run for the task at hand, we will end up with a better product that meets the customer's current and can be easily leveraged to meet their anticipated future needs in less time than it would have taken than to reuse ill-fitting code, egos aside.
  44. First, to answer your 2 questions: 1. "Is reusability something that one can train for?" - Yes 2. "Is reusability for key business objects and application modules a concept that has to be dictated as a requirement?" - Not necessarily. You can't always know which parts of a system will be useful elsewhere, so always adhere to good software design and the chances it WILL be reusable will be much higher. Reusability is most certainly a reality in software development. This topic alone can weed out the "hackers" from real software engineers. The only common thing between hackers and real engineers is that they can solve a problem, since that's what software development is based upon. The way in which they solve the problem is where the vast difference lies. I've had the experience of working at a company with developers on each end of this spectrum. One product (which we'll call Product A) was developed by what I call real engineers, while the other (Product B) was run by hackers. I had the pleasure of taking part in both of them, which is when I really began to appreciate why following good software development practices is so beneficial. While working on Product A, we had a strong focus on design. Whenever we developed a new feature or framework, we took the time to consider how it could be useful elsewhere in the system and how to ease future maintenance. The initial design work ended up paying off in the long-run, as our maintenance costs were minimal, allowing us to add new features without worrying about product instability. Our focus on reusability is what helped this product become successful. Not to mention, we documented all of the features we developed, providing UML diagrams when necessary. Soon after, I moved to work on Product B which was a whole new ballgame. It had just undergone an entire rewrite (to move from older technologies), so one would think it would be in pretty decent shape. The manager was big on pushing the "Just get it done" principle, rather than "Get it done right". This manager even told me once that I shouldn't be taking the extra time to write up design documentation or unit tests, since I could be banging out more code instead (had he been sitting closer, I might have slapped some sense into him). Each developer on the product, including the manager, would best be described as a hacker. They would do the bare minimum work required to develop new features. The lack of design and this hacker mentality resulted in very little reusability within the product itself. As I was tasked to develop a new screen, I began asking around for common widgets that I could reuse, since I had seem similar ones throughout the app. It turned out that each hacker just copy 'n pasted code or just rewrote something themselves. It was no surprise that this product was already in an unstable "fire drill" state, even right after a complete rewrite. This was a case study of why you take the time to follow good software development practices to get the job done right the first time. To sum up my thoughts: The reusability of a software product is proportional to the quality of the developers that created it.