Reuse Code Or Code It Yourself? 429
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?"
code from scratch (Score:1, Interesting)
Subvert Hibernate? (Score:1, Interesting)
Hibernate makes it very easy to write native queries for things that hibernate doesn't support well (e.g. bulk queries).
I'm really curious where it's come up that you just can't live without JDBC.
Most of the time a rewrite ISN'T the solution and should be avoided - no matter how tempting.
Care to comment more on the problem? Lots of nerds have your attention.
This question isn't about reusing code... (Score:3, Interesting)
Re:It's knowing when (Score:5, Interesting)
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 ;)
Re:Wrong Question (Score:4, Interesting)
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:It's knowing when (Score:3, Interesting)
Re:Wrong Question (Score:3, Interesting)
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 same results.
-Peter
Re:Wrong Question (Score:4, Interesting)
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:code from scratch (Score:2, Interesting)
This has the effect of documenting exactly what you are using from the library. (Usually you will only be using a small subset of any library)
The rest of your code can be written in an abstracted way. Like instead of instantiate an acme brand persistance object and call storeInXML on it every where in your code, just have a more abstract persist method, so the rest of the code doesn't even need to know how the stuff is being persisted
You can substitute a simpler or instrumented version for unit testing.
When you want to stop using the library for what ever reason (platform change, found a better way to get this functionality, different library, library licencing has changed etc) it is easy to see what needs to be changed, and the changes will not extend beyond one module
Re:code from scratch (Score:3, Interesting)
You're moderated as Funny, but I can't tell if that was actually your intent or not. On a lot of embedded systems, a custom version of libc is used to "trim the fat" or to add system-specific optimizations.
There are also those who fork the C++ library (or reimplement their own) because they're working in an environment that forsakes exceptions. Both the Google and Joint-Strike Fighter coding standards forbid exceptions in C++, which means libstdc++ as designed is a non-option.
Performance-wise, it's not actually that hard to beat a general-purpose libc or libstdc++, due to their extreme flexibility/generality. In some environments, it might actually be justified.
Re:Why not use both options? (Score:3, Interesting)
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 files (and the last one that you would think to look in). That and you often have a billion stupid interfaces with one and only one implementation class. Add to that NooB's who think everything has to be a session EJB with still another Facade EJB in front of it because they think Rod Johnson said it was supposed to be that way, and you realize that frameworks aren't necessarily going to make the architecture better, they just create more places for dumb developers to screw up (not that the original poster is doing that). Spring works well for developing a system that needs to support a lot of app server specific junk on multiple app servers (like LDAP single sign on stuff and JMX voodoo), multiple implementations of the same interfaces (like a product company writing client specific stuff), as well as for transaction management beyond pure JDBC transactions while running standalone JVM's outside of an app server. Almost no one needs that, so usually Spring is more hassle than it's worth. (particularly when trying to configure in Axis2 web services and other solutions that like to roll their own classloaders).
Good software engineers know which competing frameworks to use, when each is appropriate for the assigned task, when to forego a framework and roll your own. Good architects know all of that, plus when the developer is designing a Rolls Royce when a Toyota is appropriate, which frameworks play well together, which is appropriate for the developers on the team both present and future, as well as when architectural decisions should be made, because switching frameworks or architectural refactoring midstream becomes insanely expensive and wasteful. Bottom line -- code reuse in and of itself may make the coding easier to implement and maintain, but having a sound architecture appropriate to the project is even more important. Just using Spring, hibernate, struts, axis, GWT or whatever flavor-of-the-week framework is popular and throwing together some junit and canoo tests doesn't mean that your solution doesn't flat-out suck. If anything, the richness of frameworks borne of the maturity of a language requires more wisdom and discernment, not less.
As to the actual post itself -- It appears the dev isn't very familiar with the frameworks chosen, and needs to do a little digging in the mailing lists and doc. There's very few things that aren't possible with Spring/Hibernate with a little ingenuity. If the problems are with technical limitations of Spring Web Services such as WS-ReliableMessaging or WS-StandardOfTheWeek then use contract-first with Axis2. It's easy to swap it out.
Re:Reuse good code as much as possible (Score:3, Interesting)
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.
Libraries, not frameworks, for flexibility (Score:5, Interesting)
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.
Make the UI reflect the total state of the app (Score:5, Interesting)
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!
Since you're using Java ... (Score:3, Interesting)
... 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)
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.
Re:Hiberate will work fine (Score:3, Interesting)
This isn't totally true. I can give lots of examples, but one would be to have an object that has attributes in two different databases. You might be asking why would someone want to do that?
Lets say you are in a large company and they have many systems that make up an actual "customer", some of the info is in one system and some in another. If you are doing JDBC with a POJO then you would just build that object from the different data sources, but this becomes impossible (as far as I know) with Hibernate.
There are other examples were you would want to use cursors and stuff, so the original poster is correct. He has a difficult decision and we can't really answer it. If he never used criteria classes and his objects are very simple AND he only has a few objects then a rewrite may be simple. However, if he has a ton of objects and used a ton of lazy loading then a rewrite will be a pain.
I stuck with Hibernate, JSF and Netbeans (Visual Web Pack) and it doesn't suck, but I completely understand were this guy is. We have migrated to EJB3 now and it has its own set of issues (yes I know it can use a Hibernate persistent mangager).
Re:It's knowing when (Score:2, Interesting)
Re:It's knowing when (Score:5, Interesting)
"Wall along with Randal L. Schwartz and Tom Christiansen writing in the second edition of Programming Perl, outlined the Three Virtues of a Programmer:
1. Laziness - The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris.
2. Impatience - The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.
3. Hubris - Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience."
http://en.wikipedia.org/wiki/Larry_Wall [wikipedia.org]
Re:It's knowing when (Score:3, Interesting)
I'll add my own anecdotal evidence, too. I've long said that I'm a good coder because I'm lazy. I absolutely abhor doing something over and over, so I'll make sure I can reuse as much as possible when coding, and automate as much as possible when doing system stuff. When one of my fellow employees quit, I took the majority of his work and turned into Perl scripts. Literally. What used to take him hours each day now takes minutes... And because I've made it so easy, others can do it as well.
Re:It's knowing when (Score:5, Interesting)
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.
Just some points to consider (Score:2, Interesting)
1. Reuse if a maintained, actively developed component exists that provides the functionality, especially if the component is advertised for reuse - i.e. a library made for linking.
2. Reuse if you know you know less about implementing needed functionality than you plan to spend time and energy learning. Some things do need time to learn, and the mere programming skills do not help much if you are expected to dig into documentation of different standards and hardware specifications.
3. Reuse generally when any solution already exists, because wrapping up a bad component through a flexible interface is better than tightly coupling self-developed component. Later you may replace the mediocre component with a better candidate, but will retain the interface, so minimal changes will be required to your product.
4. Reuse generally, because through wrapping up a piece of foreign code, will give you the benefit of unit-testing, since the chance of even a mediocre foreign component working better than your first attempt to replicate its functionality is fairly high. This gives you two advantages, the one described at 3. and the benefit of said unit-testing.
5. Rewrite if you plan to after-maintain the developed component you otherwise would reuse from somewhere else, especially if you will consider giving it its own life as a standalone generic solution.
6. Runtime linking is teoretically a better idea, however practically, almost every time the version of the linked library changes, the whole product suffers due to degrees of incompatibility with the said library, however promised its version compatibility. This unfortunately happens much to often, one of the reasons many seasoned developers prefer to embed code at compilation time, thus eliminating the runtime incompatibility problem. They make up for it by frequently (or infrequently, pick yours) recompiling and publishing their host product with the updated library version re-compiled into it.