Reuse Code Or Code It Yourself?

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

Re:code from scratch

[AceofSpades19]

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

Re:Why not use both options?

[MBCook]

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:prototype quickly, optimize later

[setagllib]

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:code from scratch

[GarryFre]

Yep, I have this same issue with a current program. There is a constant clash between what the library the program was written to, and what the customer demands.

Customers don't have a clue what is easy and what is hard.

You can save a lot of time by thorough designing and specifying what the program is wanted to do.

Using a library can often transform programming into a circus of porkbarrelers, where functions don't do simply one thing, they have side-effects, that can drive a programmer nuts.

The thing is, that being off-target and having difficulties matching what the customer wants is a foregone conclusion in most jobs. It is extremely difficult to know what you might need of a program even 3 months down the line, let alone three years. Matching this moving target is like trying to shoot flies with a cannon, is going to take a lot of effort and its a never-ending job.

Just be glad that you are not working for my customer ... No matter what terrible data eating, bug I find, no matter what I tell them about money they are letting slip through their fingers, they consistantly just come up with new "Emergency" features, the want yesterday and to hell with my concerns.

Its exactly like being forced to add rooms to a burning building. I got to keep building so fast, I stay ahead of the fire, but oh God, what horrible results can happen when one is not allowed sufficient time for great coding, and are not allowed to fix new bugs.

Re:Why not use both options?

[swillden]

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

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

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

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

Re:code from scratch

[smellotron]

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.

That's absolutely incorrect. There are a number of reasons why someone would want to avoid using the STL string as-provided:

• if dynamic allocation is forbidden
• if exceptions are forbidden
• if templates are forbidden
• if immutable strings are desired for their performance or safety characteristics

These reasons may not apply to 99% of the programming community... but for the last 1%, this is critical.

Re:Then you need the balls

[syousef]

Then you need the balls to tell them it is a new project. You should also make sure they change the project name so as to prevent confusion with the old and now dead project.

Putting forward a good argument and suggesting that they start a new project may be the right thing to do. Trying to tell your employer what to do is stupid. Building a rapport and gaining their confidence isn't.

It's not about having balls. Telling someone who employs you that they MUST do something your way is stupid. You don't have the power to execute your decision. At best you look foolish and the business harbour ill will at being told what to do. At worst, start looking for another job.

Reuse the well done and code the rest...

[benow]

There are arguments for each.

Reuse:

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

Homebrew;

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

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

Hibernate

[countach]

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

Re:code from scratch

[smellotron]

Couldn't you just compile it with -fno-exceptions to not have exceptions in C++?

You could, but it wouldn't work. For example, std::string throws an exception when you pass it a null pointer. If you simply set -fno-exceptions, it would happily ignore the throw statement, and try to copy data from the null pointer to its own buffer (Segmentation Fault). If you can't throw exceptions, it affects the software interfaces—you need to error codes or a global error state such as errno.

I also don't really understand why Google wouldn't allow exceptions at all because exceptions are pretty useful

They want their code to be universally applicable. Since some projects can't use exceptions (hard realtime, embedded environments, etc.), that means they simply put a blanket rule disallowing exceptions. If you do any C++ development, I would recommend taking a look at their C++ style guidelines [googlecode.com]. I don't agree with everything in there, but it's a very good read. Another decent read (much longer and more boring, but still full of insight) is the Joint Strike-Fighter C++ guidelines (PDF) [att.com].