Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Reuse Code Or Code It Yourself?

kdawson posted more than 5 years ago | from the good-or-great dept.

Programming 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?"

Sorry! There are no comments related to the filter you selected.

It's knowing when (5, Insightful)

Bender0x7D1 (536254) | more than 5 years ago | (#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 (4, Interesting)

Midnight Thunder (17205) | more than 5 years ago | (#25635149)

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:It's knowing when (5, Insightful)

Artraze (600366) | more than 5 years ago | (#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.

Re:It's knowing when (0)

Anonymous Coward | more than 5 years ago | (#25635163)

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.

Aphorisms are the best way to get modded up on Slashdot.

Re:It's knowing when (5, Insightful)

syousef (465911) | more than 5 years ago | (#25635353)

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:It's knowing when (2, Interesting)

bky1701 (979071) | more than 5 years ago | (#25635407)

In my book, it is outputting code that works well and is maintainable that makes a good programmer.

Re:It's knowing when (1)

magarity (164372) | more than 5 years ago | (#25635471)

In my book, it is outputting code that works well and is maintainable that makes a good programmer
That's a little too simplistic, isn't it? What good is code that works well and is maintainable if the system it runs on has become obsolete? Development time must be taken into account as well and that's where the whole reuse vs from scratch really comes into play.

Reuse good code as much as possible (5, Insightful)

TheLink (130905) | more than 5 years ago | (#25635455)

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).

Re:It's knowing when (1)

DiegoBravo (324012) | more than 5 years ago | (#25635617)

Nah..... just go beyond that silly traditional dichotomy by consistently applying eXtreme programming, so you will never need to know if you're reutilizing or recoding... you're just eXtreme programming your never ending requirements.

prototype quickly, optimize later (4, Insightful)

evw (172810) | more than 5 years ago | (#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:prototype quickly, optimize later (2, Insightful)

somersault (912633) | more than 5 years ago | (#25635049)

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:prototype quickly, optimize later (2, Informative)

setagllib (753300) | more than 5 years ago | (#25635485)

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 fixed, but you'd think they'd test for stuff like that, since even popular projects like Eclipse were crippled by the bugs.

Re:prototype quickly, optimize later (5, Insightful)

Bad Mamba Jamba (941082) | more than 5 years ago | (#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.

code from scratch (1, Interesting)

lixlpixel (747466) | more than 5 years ago | (#25634901)

code from scratch - and reuse your own code - that way you know exactly what it can do and where you have to start from scratch

Re:code from scratch (0)

Anonymous Coward | more than 5 years ago | (#25634941)

That's not always applicable. If the code is not in your area of expertise, especially if that area is security, and the code works, you are better off reusing code. But in general I am with you.

Re:code from scratch (1)

sexconker (1179573) | more than 5 years ago | (#25635037)

If security is a concern, you sure as hell better make it your area of expertise, then audit any code you intend to use (whether you write it or not).

Re:code from scratch (0)

Anonymous Coward | more than 5 years ago | (#25634959)

Always code from scratch. The time saved from complete understanding of your own code is hard to describe.

Re:code from scratch (0)

Anonymous Coward | more than 5 years ago | (#25635059)

Always code from scratch. The time saved from complete understanding of your own code is hard to describe.

Comment your code.
Comment your code.
Comment your code.

Or else you'll revisit it in six months and wonder what the hell you were thinking when you wrote it.

Re:code from scratch (5, Insightful)

Antique Geekmeister (740220) | more than 5 years ago | (#25635069)

If you want to write from scratch, write your own compiler and build your own system from melted glass. The time wasted encountering and solving a variety of problems already solved by others is very, very easy to describe, and there is little guarantee of even the limited success demonstrated by the best of the older code.

The amount of time I've wasted arriving after some in-house project that one person wrote, everyone got stuck with, and needed to be ripped out and replaced with the standard open source tool when that one person got transferred away or they discovered its limitations the hard way would have given me a month off of work every year of my professional life. Chat clients may be the worst of the bunch: watching those harsh lessons relearned by every sophomore who just learned a new language and thinks the new language won't run into the same issues is in for big, big surprises.

Re:code from scratch (5, Insightful)

plover (150551) | more than 5 years ago | (#25635323)

Always code from scratch. The time saved from complete understanding of your own code is hard to describe.

Well, that's certainly the least maintainable answer I've ever seen on the subject.

If someone has to come along after you and maintain the system, how do they know what it does? Did you document it perfectly? Of course not -- you wrote it, you know how it works, so you'll invest nothing in educating others.

When you use a library, framework, or a reusable whatever, not only do you get the functionality, but you get the available documentation and a potential pool of developers who are already familiar with that technology.

I've seen an awful lot of NIH (Not Invented Here) syndrome in this business, and I've seen so many "look, I wrote my own string class, isn't it neat?" that I lost count. No, it's not neat. The STL has provided strings in C++ since 1994 -- if you're writing one in 2008, it's because you're so incompetent you don't know the full language. And the same is true for many of the major technologies. I'm not saying Hibernate is or was the best choice for your shop in this exact situation, but it was likely a better choice than writing your own.

There's actually a solution that's kind of like a compromise, but offers some advantages: write a thin wrapper around the technology. You can either write a straight 1:1 wrapper, or create your own API, customized to be something you're comfortable coding against. You can then replace the technology with something better, when that something better comes along, and all you have to do is change the wrapper. The other reason this is a good choice is you can provide a mock object replacement for your API and run unit tests against it without bringing up an entire web environment.

Re:code from scratch (1)

Satis (769614) | more than 5 years ago | (#25635007)

I agree, code everything yourself. There's nothing wrong with coding your own frameworks and reusing those... even if something needs to be changed you know exactly how and where to do it.

I don't mind using code for simple things (especially javascript snippets to do things that are a pain in the butt to make cross-browser). But any time I've used other peoples' code for something marginally large it's bit me in the ass.

Re:code from scratch (5, Informative)

AceofSpades19 (1107875) | more than 5 years ago | (#25635333)

I write my own implementation of the c standard library and the C++ standard library too, because I find they are not efficient enough and I find using the standard libraries bite me in the ass too

Yeah! (5, Funny)

gbutler69 (910166) | more than 5 years ago | (#25635213)

I always write my own bootloader, device drivers, operating system, assembler, compiler, C-interface library, graphics libraries, hardware abstraction layers, collections, and algorithms first. Then I just write a thin layer on top of that to implement the desired functionality. Easy, peasy, japa-neasy!

In my spare time, I grow my own grain, raise my own cattle, remove my own spleen and even generate my own electricity my peddling my home-made bicycle vigorously!

Why not use both options? (5, Insightful)

aurelianito (684162) | more than 5 years ago | (#25634909)

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.

Re:Why not use both options? (4, Informative)

MBCook (132727) | more than 5 years ago | (#25635369)

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.

Re:Why not use both options? (1)

syousef (465911) | more than 5 years ago | (#25635381)

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).

Subvert Hibernate? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25634925)

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.

Re:Subvert Hibernate? (1)

Bill, Shooter of Bul (629286) | more than 5 years ago | (#25635129)

Mod up! There are only a few spots in which you would run into trouble with hibernate ( such as dealing with scaled out DB's*), I'd be really interested to see if you really hit one or not. I want to hear more about the alleged problem.

*(I understand there is hibernate Shards, but I have some philosophical issues with that approach)

JDBC instead of Hibernate? (0)

Anonymous Coward | more than 5 years ago | (#25634927)

If you think it would be better if you had used JDBC instead of Hibernate when you began coding your application, you are probably doing something wrong.

Use JDBC *and* Hibernate (4, Insightful)

puppetman (131489) | more than 5 years ago | (#25634933)

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...

Re:Use JDBC *and* Hibernate (4, Insightful)

Shados (741919) | more than 5 years ago | (#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...

Re:Use JDBC *and* Hibernate (1)

ozphx (1061292) | more than 5 years ago | (#25635557)

I was under the impression the transaction support in Hibernate was more than sufficient for most purposes. I come from a .Net background so most of my experience is using the NHibernate [] port with the Diamond Binding [] active record implementation. In this, using transactions is as simple as using(new TransactionScope()) { ... }.

Any complex queries can be handled using HQL (including aggregates, etc, if you are feeling really manly), and if you really need you can get the connection and use ADO (similar to JDBC) for hitting sprocs/whatever, in the same transaction.

So I agree with parent, I think OP needs to read up on his framework more. Hibernate can be fairly intimidating, but this makes it quite flexible (difficult for clustering though, but I guess theres always Shards). The main reason we went with Diamond Binding is because it simplifys things down a fair bit (and gets rid of those pesky mapping files) which helps the junior devs a fair bit.

When in doubt rewrite it (0)

WarJolt (990309) | more than 5 years ago | (#25634935)

It's better to use the new library. Who know what new features you'll need later. Plus everything you've learned the first time around can be written cleaner and perhaps more modularly the second time around, so substituting pieces of code will be easier.

Re:When in doubt rewrite it (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25635011)

This is bad advice.

A system that has been tested for years will almost always be better than something new you've rewritten. Remember that it's more than a developer's resources you're using and no developer writes pristine code.

I've seen many projects that other programmers have said just absolutely need a rewrite and it's never ended well. Usually, they end up with more problems than they started with.

If you really need to sanitize the code base, wrap the old stuff. I've had much success with this

Easy (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25634947)

What elements or characteristics of a problem point to one option over the other?"
Having an axe a specific element (an axe) or a characteristic (extreme curelty) pointing to an option (your employer) definitely counts as a plus.

How about contributing to OSS (1)

michaelepley (239861) | more than 5 years ago | (#25634951)

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?

Re:How about contributing to OSS (1)

phyrz (669413) | more than 5 years ago | (#25635083)

*ding* this is the correct answer.

Re:How about contributing to OSS (1)

Canberra Bob (763479) | more than 5 years ago | (#25635225)

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.

What about a car analogy (-1, Troll)

Anonymous Coward | more than 5 years ago | (#25634953)

Do you like to build your cars from scratch or buy them?

Wrong Question (5, Insightful)

pete-classic (75983) | more than 5 years ago | (#25634957)

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.


Re:Wrong Question (3, Insightful)

chromatic (9471) | more than 5 years ago | (#25634995)

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 (4, Interesting)

pete-classic (75983) | more than 5 years ago | (#25635513)

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!


Re:Wrong Question (4, Insightful)

syousef (465911) | more than 5 years ago | (#25635187)

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:Wrong Question (2, Insightful)

Sloppy (14984) | more than 5 years ago | (#25635223)

In the real world, you never "collect all the requirements." That's just plain impossible.

Re:Wrong Question (3, Interesting)

pete-classic (75983) | more than 5 years ago | (#25635433)

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.


Re:Wrong Question (3, Interesting)

CorporateSuit (1319461) | more than 5 years ago | (#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:Wrong Question (0, Redundant)

pete-classic (75983) | more than 5 years ago | (#25635397)

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.

Well said.


Re:Wrong Question (2, Insightful)

E++99 (880734) | more than 5 years ago | (#25635611)

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.

I disagree. An experienced engineer would know that he never has all the requirements, and the no spec ever encapsulates every real need that will be realized. Therefore, every project must be built with the assumption of future change and growth.

The is exactly the problem of the overuse of frameworks like Spring and Hibernate. They too frequently introduce unnecessary complexity and limitations.

Great programmers... (0)

Anonymous Coward | more than 5 years ago | (#25634971)

reuse great code.

This question isn't about reusing code... (3, Interesting)

gdeciantis (570658) | more than 5 years ago | (#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.

Use JPA (1)

gbutler69 (910166) | more than 5 years ago | (#25635247)

Waaaaaay better!

Re:Use JPA (1)

kbrasee (1379057) | more than 5 years ago | (#25635571)

I'm a fan of JPA after using it on a decent-sized project (Spring MVC web app using Hibernate's JPA implementation). From what I've seen of original Hibernate config this does look a little simpler, primarily due to the annotations. However, I did run into a few JPA and JPA+Spring quirks that took up quite a bit of my time and would never have been an issue if I stuck to straight JDBC.

Would it have been quicker if I went with JDBC instead of JPA? Maybe. But now that I've got an idea of how to work through the minor issues, I'm pretty sure it'll save me some time on my next project.

Understanding the code is decisive (0)

Anonymous Coward | more than 5 years ago | (#25634977)

If you must "open the black box", and get into the entrails of some rat nest of logic to complete your project, then trying to tweak code you don't understand is a sure-fire time waster, and chances are you'll have to rewrite it later anyway.

Only if the code is clear to you then can go ahead and use it. Only you can answer that question.

Well.. (1)

somersault (912633) | more than 5 years ago | (#25634997)

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 with frameworks though. With each project I work on I try to learn from past experiences to make my code even more modular. I've also been working on web apps with a lot of feature creep recently.. if you don't manage to keep everything simple it quickly becomes a mess keeping track of the changes.

Re:Well.. (1)

syousef (465911) | more than 5 years ago | (#25635205)

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.

agreed (1)

nimbius (983462) | more than 5 years ago | (#25635001)

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.

Both (1)

Art3x (973401) | more than 5 years ago | (#25635025)

A little of both. Portion size is key. I search for functions and classes but not whole frameworks.

For example, as a web programmer, I love jQuery, to simplify my JavaScript. And sometimes I copy a PHP function or class when I need to do something complicated, like translate HTML to wiki mark-up.

But the requirements for each project is so irregular that customizing a one-size-fits-all PHP framework would be the same amount of work yet result in all this extra code, I think.

If you can reinvent the wheel, that is a way (1)

CrazyJim1 (809850) | more than 5 years ago | (#25635043)

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 something that someone made a library for, I typically code it myself.

Meh (0)

Anonymous Coward | more than 5 years ago | (#25635045)

Just duct tape them together with some Perl.

What's up with slashdot lately (4, Insightful)

1155 (538047) | more than 5 years ago | (#25635051)

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:What's up with slashdot lately (2, Insightful)

geekoid (135745) | more than 5 years ago | (#25635385)

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

Re:What's up with slashdot lately (0)

Anonymous Coward | more than 5 years ago | (#25635539)

Yes, you are. About two years of Slashdot apparently.

Re:What's up with slashdot lately (0)

Anonymous Coward | more than 5 years ago | (#25635621)

Slashdot has always sucked. It just sucks more and more as it ages. Even the trolls don't bother with it any more. And that's really sad.

That's some serious scope creep... (5, Insightful)

syousef (465911) | more than 5 years ago | (#25635063)

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).

Better Requirements Gathering (1)

twistedfuck (166668) | more than 5 years ago | (#25635071)

Sounds to me like you need to improve your requirements gathering. If you had gathered all the possible requirements, and tried to predict a few also, then you could have likely selected a framework to match your current project's scope, and the scope creep also.

Re:Better Requirements Gathering (1)

syousef (465911) | more than 5 years ago | (#25635245)

Sounds to me like you need to improve your requirements gathering. If you had gathered all the possible requirements, and tried to predict a few also, then you could have likely selected a framework to match your current project's scope, and the scope creep also.

I'm seeing a lot of statements like this but...

1) The business people tend to change their mind and expect technical staff to cope. It's hard to gather requirements if even the business doesn't understand what it wants to do. (Your job becomes trying to help them understand and letting them know how costly late changes to scope are, but that's assuming they're willing to listen).

2) Business needs change. Sometimes the regulatory rules do too.

Re:Better Requirements Gathering (3, Insightful)

Todd Knarr (15451) | more than 5 years ago | (#25635389)

The problem is that the standard response from the business people, when I try to anticipate future requirements, is "But we're not asking for that. Can't you just do what we asked instead of adding all this extra stuff that's taking too much time to do?". Part of it seems to be that business wants and is given the authority to add to and change the requirements, but never been required to take responsibility for the consequences of those additions and changes.

Re:Better Requirements Gathering (1)

Hairy Heron (1296923) | more than 5 years ago | (#25635443)

Wow you must work in the only software company on earth where every single requirement can be had up front before any coding is done. Those of us in the real world, though, realize that such a thing is never possible.

puzzled... (1)

BillAtHRST (848238) | more than 5 years ago | (#25635081)

Just what is it that makes ORM a non-starter for this project?

Hibernate doesn't completely suck. (1)

FatherOfONe (515801) | more than 5 years ago | (#25635095)

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 and it only needs to be a one way association do it. Avoid bi-directional associations at all cost.
2. Hibernate can use pure sql and it's own variant of SQL. Use them when you have to. We try hard to avoid every putting SQL in to our code but there are times when we had to do it.
3. Hibernate wasn't made for 40k objects in memory at one time. If you need that then it is possible but you will have to change some caching options.
4. Lazy instantiation. In theory it sounds great, in practice it doesn't. This may start a holy war on Slashdot, but I had to avoid this.
5. Working with Arrays of associated classes and having to make changes to them.

Re:Hibernate doesn't completely suck. (1)

syousef (465911) | more than 5 years ago | (#25635291)

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 really only work close to as well as advertised if you use them within the narrow context they've been built for.

Mmmmmmmmmm (1)

Anrego (830717) | more than 5 years ago | (#25635119)

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 I think if JDBC has become preferable over Hibernate.. you're doing it very wrong ;p

Yup, you've hit the nail on the head (1)

telchine (719345) | more than 5 years ago | (#25635135)

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 than one large monstrosity. If the requirements change, the n often you only need to swap out one component or two and continue with relatively little disruption.

The real solution is to make sure the requirements are right from the start. If you succeed in doing this, tell me how!

Quick vs Long (1)

bgibby9 (614547) | more than 5 years ago | (#25635181)

Basically it comes down to this. If the project started out as a "let's get something going and work from there" project and has now become something of a "this thing works, let's extend it's functionality" then you've got to make a choice.

Either take the concept and build it correctly (either by writing from scratch or extending the classes that you have) or continue to hack it.

I feel that taking a prototype and making it a production quality application needs to have the time spent doing it right! Prototypes fall over, it's their nature, but you don't want the same behaviour from your production apps!

Reuse (0)

Anonymous Coward | more than 5 years ago | (#25635183)

Reuse is only useful *if* you control the libraries that you are reusing. As new requirements come along that exceed the abilities of the libraries you are using, you need to modify those libraries and increase their capacity/use - this will allow for better future reuse.

When those libraries aren't open source, or when modifying them will create issues for other projects, reuse simply leads to stagnation.

Reuse, but not for reuse's sake (1)

VGR (467274) | more than 5 years ago | (#25635203)

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, but it will mean more work than not reusing it.

Re:Reuse, but not for reuse's sake (1)

jomegat (706411) | more than 5 years ago | (#25635545)

Code reuse is the one practice that can impact the cost of a project more than any other thing. But it can impact it in either direction, depending on the code you reuse.

Management has a tendency to ask engineers to reuse the wrong code almost every time. Code that has been badly designed and/or badly implemented is code that comes up in management meetings. Every week. For months. They start tracking it, and finally, someone beats the code into submission, and they add up the cost. "Wow. $150 thousand!"

The next time a project comes up and management can possibly imagine that their $150,000 "investment" might get leveraged, they push the engineers to reuse that code. "It must be good! It cost us $150,000 to develop it!" The reality is that this code should have been taken out behind the shed and shot. When it gets reused, even more bugs will be found, and the cost of the project will go up.

On the flip side is beautifully designed and implemented code. It works almost immediately, and without wringing of hands and gnashing of teeth. It therefore never sees the light of day at a management meeting. It is beneath their radar. They will never suggest that it be reused, because they know nothing about it. That's the code you want to reuse.

start over (0)

Anonymous Coward | more than 5 years ago | (#25635267)

I know nothing of the scripting languages you are using. What I do know is requirements almost always creep. It is hard to stop creep as the urge is there to please the customer. If you deliver something they wanted a year ago it is unlikely the thing they want today, that's the nature of custom built items. Requirements will likely continue creeping unless you are almost done and then the customer is itching to get their hands on the product before you are comfortable you have thoroughly tested it.

If there is a large ways to go on the project, restart. You seem more comfortable in the scalability of the other language so use that.

Also, a lot of the comments I have read seem to address what he should have done. I agree, but unfortunately, that's water under the bridge.

ORM != Reusable code (1)

Foofoobar (318279) | more than 5 years ago | (#25635309)

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 much as he wants (as long as he is communicating his changes to the developers) and the developers don't have to see all those queries in their code.

ORM is a solution only if you are fanatic about turning EVERYTHING into an object but a true engineer knows that one tool does not fit all paradigms. And ORM is such a case where objects tend to fall short; good in the short run but the more you try to scale your application up, the more ORM becomes a problem and you end up falling back on hand coding your queries.

The right lesson is... (1)

dethkultur (617989) | more than 5 years ago | (#25635337)

"Now, I used to be told that good programmers write code and great programmers reuse code." is sort of right.... the correct lesson is: "Good programmers borrow, great programmers steal." Same lesson applies to marketers. And to poets (Robert Frost said it first, speaking about poets.) Oh, and to politicians, esp if your name is Joe Biden.

Don't marry your code (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#25635345)

Whether you write code or use a library, you must do it in such a way that functionality is separate from policy and so-called business rules. In other words, the code that sends a message over the Internet or over any communication infrastructure is separate from the code that does the special stuff that makes your application what it is. If you need an interface layer, do it. Then if Java is better than Hybernate halfway through the project, you chuck Hybernate, replace it with Java. If Shmava is better later on, change it again. Your application won't be married to the code you are reusing. By the way, Obama has been friends all his life with people who hate America. There are gobs and gobs of evidence to that effect all around. Plus he wants to raise taxes across the board to sky-high levels and implement all kinds of socialist policies that have been demonstrated wrong in dozens of countries over the course of a century and a half. But the American people are going to put him into the highest office in the land today. Proof Americans are really stupid. Change and Hope. Bah. Those who have money will move it and their businesses out of this country to more business- and economic-friendly situations. Those who don't have money will be stuck with no jobs and a high tax bill. As Mr. Chapel would say, "Nanny nanny boo boo!"

Learn how to use the tools... (0)

Anonymous Coward | more than 5 years ago | (#25635361)

The Spring/Hibernate combination is very flexible. I find it hard to imagine you've come up with something these guys haven't thought of. If you're using the latest versions of these tools you should not have to deal with XML hell.

Ecellent programmers (1)

geekoid (135745) | more than 5 years ago | (#25635365)

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.

Re:Ecellent programmers (1)

geekoid (135745) | more than 5 years ago | (#25635371)

And no, they don't need to spell~

iBatis Rules (0)

Anonymous Coward | more than 5 years ago | (#25635375)

Check it out:

When in doubt, roll your own. (1)

parabyte (61793) | more than 5 years ago | (#25635395)

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 layer.


The new requests coming in involve capabilities (1)

dindi (78034) | more than 5 years ago | (#25635413)

"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 in time, they will also start to understand. Slowly though, as they are IDIOTS!!! Did you find it out yet? They are MORONS!

Sorry, don't know what to tell you, I usually write and reuse my own database classes, do not know hibernate and only use ODBC when I really have to (e.g. modifying some ASP crap that already uses it, or SQL 2005 with PHP is easy with it). Just use PDO or mysql_ or mssql_.

Do it from scratch until you hit something hard (1)

togofspookware (464119) | more than 5 years ago | (#25635415)

I got quite a taste of a few Java frameworks from my last job (Hibernate and Tapestry, to be precise, and given my experience, I'm inclined to agree with the 'hibernatesucks' tag. If you had mentioned Tapestry I would have agreed even more with a 'tapestrysucks' tag, because Tapestry does suck, hardcore. Hibernate I can at least see being semi-useful in some situations).

My view is this: If you're making a simple project, implement it in a simple way. You've got to expect new requirements to come in, so don't go choosing *any* sort of 'framework' right off the bat.

<tangent> Unfortunately you do have to choose a programming language -- I'm not too thrilled with any of the offerings right now. PHP is hosted everywhere, but in 3 different incompatible versions. I use Ruby, but in order to ensure it works on whatever web host, you've got to use it with CGI, so hope your site doesn't get a lot of traffic! If you have a host that lets you run Java servlets and whatnot (despite my old job I'm not especially familiar with how Java applications get hosted), then I'd say Java's a good choice - not my favorite language, but it's fast and stable. </tangent>

Only when your program (/web site) actually needs to do complex things that would take a lot of time to implement (graphics libraries, hardware drivers, complete xml parsers come to mind) should you start bringing in external libraries. And note that I said "libraries", not "frameworks". 'Frameworks', in my view, provide 2 things:

  • A standard set of libraries
  • A standard way to structure your code

If you can use those libraries that you need without a framework, it's going to be in your best interest not to include the extra frameworky stuff in your project that you don't need (get to the why in a minute). Importing a standard way to structure your code from a widely-used framework can be useful if you're working on a project with several other developers who would otherwise either argue about what made-up in-house standard to use or follow no standards at all, but if you're doing this thing by yourself, you can probably fulfill the needs of your project more simply by doing it yourself.

Even when you're importing functionality that will be controlled by your program (a library), and not the other way around (a framework), I would encourage you to try to implement it yourself, first. You know the specific needs of this project better than the people who wrote any libraries, so you may be in many cases be able to write something vastly simpler that gets the same job done in a way that makes more sense to you (not to mention that many libraries are simply crap, such as the ruby-git wrapper I recently downloaded before writing my own version that bothered to escape arguments to shell commands). If you do this enough times you will find that things you thought were difficult to implement are not so bad, and will wonder why so many people think they need a library.

To summarize, I agree with the guy who said "It's knowing when [] ". Also, for the most part, with Chuck Moore [] , even though I'm not a Forth programmer ;)

boring (1)

xdroop (4039) | more than 5 years ago | (#25635437)

Coder digs hole, asks for comments on different shovels and other holes; film at eleven.

Always code it yourself. God will love you. (2, Funny)

Anonymous Coward | more than 5 years ago | (#25635449)

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't say be fruitless and reuse other peoples kids.

So obey God and do His will. Create something old.

typical, so typical (1)

Ancient_Hacker (751168) | more than 5 years ago | (#25635481)

this is the usual hobson's choice. you load up some framework and WOW, 70% of the work is done for you! Whopee! Then the boss wants the buttons to update differently and you find it really hard to do that within the framework, but you manage by adding kludges in 73 places. Then you realize you really need a way to rollback or failover or fooswank and of course it's hard to impossible to wedge that into the framework. And then version 2 of the framework comes out and all your kludges you have to reimplement.

in other words the framework makes the first 70% easy, the next 20% difficult or slow, and the critically needed last 10 percent very difficult to impossible.

I've seen this time after time, with Hypercard, PowerBuilder, Notes, etc, etc, etc...

I don't get Hibernate et al. (1)

zigamorph (991245) | more than 5 years ago | (#25635489)

I prefer to code JDBC directly. Then I at least know what it is doing and can track down and resolve bottle-necks. Plus: there's less xml. For simple, low load applications it's probably ok but even then I find that it is better to get your hands dirty. You're going to need the experience when you tackle a not so simple application.

Reuse where possible (1)

CharlesK80 (1400427) | more than 5 years ago | (#25635507)

The benefits of reuse is that you have less code to maintain and costs fall, someone else does the testing and bug fixing of that code so you don't have to. The best thing you can do with a line of code is delete it I say. As long as the code being reused is from a good project (i.e. open source, active, mature, etc), always reuse.

pst. (0)

Anonymous Coward | more than 5 years ago | (#25635559)

God damn you software engineers.

Doing it from scratch has other dangers... (1)

TrixX (187353) | more than 5 years ago | (#25635565)

Sometimes you feel that working from scratch "would have been better". But you might be missing lot of details you have taken for granted or even never knew they were there, and you will have to face them.

There is a great article [] from Joel related to this... he actually speaks about saying "this sucks, let's rewrite it" so it's not exactly the same, but the points have a lot in common with your case. I recommend you to take a look at it.

Document! (1)

Mongoose Disciple (722373) | more than 5 years ago | (#25635575)

Here's a point I haven't seen raised yet: whatever you decide, document the hell out of the why in your code.

Maybe you do some analysis and figure out that Hibernate doesn't work for what you have in mind. You go your own way. If the why for that isn't very explicit in your code, the developer who has to maintain your code two years later will likely look at it and think, "The person who wrote this was a dumbass. They didn't know enough to use Hibernate for this!" Or they didn't understand Hibernate well enough to know how to do it the 'right' way. (And even if you do your research, it's possible this is true.) If you make clear notes of why you made the decisions they did, the person who has to maintain your code down the line will be considerably less inclined to want to murder you.

This is especially important if that person is a psychopath, or you, or both.

reuse good code and rewrite bad code! (1)

neonsignal (890658) | more than 5 years ago | (#25635579)

Seriously though, new requirements that come in after a project is written are often hard to fit into the framework.

That doesn't necessarily mean always writing from scratch just so modifications can be made more easily. Quite often the advantages of a well written library (good coverage of a domain, a worked over design, tested by multiple users, and quick to incorporate) outweigh the ability to precisely meet each new requirement.

No point in perfectly meeting requirements if the project is never finished (conversely you could argue, no point in finishing if you can't fulfil the core functionality!).

Reuse as much as possible (1)

hierro (809232) | more than 5 years ago | (#25635581)

The less code you write, the better. Keep in mind that a given computer program should always be measured by functionality, not by SLOC. Keep in mind that every line you write implies:
  • More possible bugs
  • More testing
  • More maintenance
  • More complexity

So my advice is reuse as much code as possible. However, as others have pointed out, check what you're basing your work on. There are a lot of shitty libraries and frameworks out there and for those cases you're better off rewriting the whole thing.

When you understand the problem (1)

shareme (897587) | more than 5 years ago | (#25635597)

When you understand the problem as in project requirements are not creeping up than re-use..otherwise new problems ot you at least, new code..

Design First Then Build... It Just Never Happens. (3, Insightful)

nick_davison (217681) | more than 5 years ago | (#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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?