Slashdot Mirror
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?"
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.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
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.
You should be asking, "Should I make architectural decisions before or after I collect all the requirements." But you know the answer to that one.
A more experienced engineer would have dug for requirements early, planned for some creep, and would have warned the manager that the risk of starting before the thing is properly speced is that all work might have to be thrown away.
You'll know next time.
-Peter
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).
These posts express my own personal views, not those of my employer
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.
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!
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
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.
John
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
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).
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.
You're the liason between programmers and customers, because you're good with people. Did I get it right?
how to invest, a novice's guide
On Wednesday we'll have: "I coded a project, and now it's all done, should I start another project?"
Thursday's topic: "A lot of people around me use the tab key but I like to key in exactly 3 spaces for indentation, who's right?"
And on Friday: "I...uuuuh...well....oh, have you ever hit refresh but the web page said it couldn't?"
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.
Then why are there over 200 comments, more than usual? Good programming practice is an interesting topic for many of us.
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!