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?"
It's knowing when (Score:5, Insightful)
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 (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:It's knowing when (Score:5, Insightful)
> - 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 (Score:5, Insightful)
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 TDWT
The fact that you seem to think that "copy and paste" is synonymous with "reuse" is a bit disturbing...
Re:It's knowing when (Score:5, Insightful)
I've even worked with senior developers who think "cut and paste" is code reuse. Clearly they were not spending enough time on sites like this one.
Re:It's knowing when (Score:5, Insightful)
I agree. Laziness is often the same thing as "saving time". Why reinvent the wheel when somebody already did the work?
Here's a good illustration from the 8-bit gaming era:
- Pitfall II was created by the original programmer for the Atari 2600/VCS. Activision wanted to port this extremely successful game to other platforms, including the new Atari 5200/Supersystem and the Commodore=64. Activision assigned this task to two programmers who also happened to be good friends.
- The C=64 programmer decided to recreate the whole thing from scratch.
- The A5200 programmer decided to directly copy the code, and only change the pointers as needed.
The A5200 programmer finished his task in only half the time as his friend. He then used the extra days to program an entirely new level into the game (think Pitfall III). Reusing the code allowed him to create two games, instead of just one game.
Re:It's knowing when (Score:4, Insightful)
This is an excellent example of a project with an end date. The game ships, and then you're done. No updating.
I've been working at the same place for 8 years, not a long time, but not just a blip on a resume either.
We are still working on the same projects from 8 years ago. Some of them were built using a framework, some were not. We ran into a lot of problems with frameworks. Honestly, if the projects had end dates, everything would have been fine, but they didn't.
We found that as time went on, the framework may or may not be upgraded along with the software it sits on. If it doesn't get upgraded, then you may have a problem where you cannot upgrade the underlying software. Sitting on an OS that is 2 versions old because the framework uses that particular API is not fun.
Another problem I ran into, was when the framework WAS kept up to date. As another poster said, we 'massaged' the heck out of the code. A new version comes out, and there are incompatibilities. The new framework can't just be dropped in. We need to re-do all of our work.
The stuff we have coded ourselves is easier to maintain. On the downside, any new features need to be written by us. On the upside, that is never a problem. We had developed 18 separate projects in the first 4 years I worked at this place. Now we've been able to morph them all into 1 project. That meant taking them off of the frameworks they were on (3 different frameworks) and code everything ourselves.
Coding it ourselves ensures that everything works together. If we had re-used a lot of code, then the systems just couldn't be integrated together nearly as easily.
I've tried it both ways, and for my situation, writing my own makes more sense.
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.
Re:It's knowing when (Score:5, Insightful)
Did he really make a mistake? He already has one version out and is now finding out what the software really needs to do. That sounds pretty damn successful to me. Now he's dithering about rewriting and replacing some of the libraries, which he would have had to do anyway even if they were custom-written.
If he had written everything from scratch:
His original choice was correct. As far as replacing Hibernate, he's in just as good a position now as he would have been if he had written his own persistence layer. Remember, he chose Hibernate, which turned out to be unsuitable, because didn't know the requirements when he started. He would have been damn lucky if he had just happened to develop a custom persistance layer that neatly anticipated the unknown requirements. So, ripping out or rewriting the persistence layer was inevitable. If you're going to throw code away, it might as well be code that you got for free, instead of code that you sweated and toiled over.
If you're really dead set against replacing or rewriting any libraries, the only way to improve your odds is to use the biggest, oldest, kitchen-sinkiest, most bloatiest library you can find.
Re:It's knowing when (Score:5, Funny)
And people call me crazy for embedding Emacs in everything I write!
Re:It's knowing when (Score:5, Insightful)
On the spot!! If the "poster" hadn't reused code from the get-go he was probably still coding. But instead of now making a choice between "hanging in" and "starting to rewrite", there is a third and IMHO better option: Throw out the framework that doesn't fit anymore and replace it with a better fitting one. Don't jump immediately into the "and now I've to write it all from scratch" excuse.
Your original "reuse" decision was the right one, but appearently you didn't pick the right framework. Which is normal, because at the beginning of the project you didn't know exactly what the requirements would be. Based on your improved knowledge of the application, you should redo your investigation of frameworks and find one that has the right fit.
And if you can't seem to find one that fits, you need to do some deep-deep-deep thinking. Is your situation really so unique that nothing "standard" out there will fit in, or is it the too often happening "not invented here" syndrome.
Don't fall into the trap of "I can do it better myself". Yes, I'm sure you can :-), but you won't have the time!! Or better said, your boss won't allow you the time.
Re:It's knowing when (Score:4, Insightful)
Did he really make a mistake?
Maybe.
He already has one version out and is now finding out what the software really needs to do. That sounds pretty damn successful to me.
It sounds like a mistake in the design stage to me. Did he interview the people who were going to use his software? Did he understand what they were going to expect from the software? Did he analyze the information needed by the software, and by its users? Did he define the software's scope and discuss it with its users?
I get the impression he didn't make the mistake of coding *beyond* the requirements, which is almost always a waste of time... But did he take a well coordinated effort to get the requirements clear before he wrote the first line of code or even chose the framework?
Now he's dithering about rewriting and replacing some of the libraries, which he would have had to do anyway even if they were custom-written.
Of course you'll chose to use libraries over writing it by yourself. I'd like to emphasize tho that the biggest benefit is not the time you'd need to write the code... but the time you'd need to debug it!
Libraries have usually been out in the wild for some time, been used in many different situations by different people, been looked at, debugged, improved, simplified and documented. Quite often all the functions in a library have a coherent interface, which makes for easy, "intuitive" use and a short learning curve.
So on my left I have hard time writing pages of code and annoying debug work, and on my right I have a comfortable ride quickly producing nice looking code that just works.
My two non-lazy braincells tell the rest of them that it's a no brainer ;)
[...]
Remember, he chose Hibernate, which turned out to be unsuitable, because didn't know the requirements when he started. He would have been damn lucky if he had just happened to develop a custom persistance layer that neatly anticipated the unknown requirements.
Yeah. Very lucky indeed. To get a decent course in software engineering, with an emphasis on interviewing techniques and information analysis. You don't really *need* to just code something out of the blue and be lucky to meet the requirements. It's not necessarily a process of trial and error.
The people you're writing software for can tell you what it's required to do. You can make a crude design and discuss it with them without even writing a single line of code. Once you have your design you start looking for an environment to implement in.
I think that would have had a good chance of avoiding the hassle in the first place. Right now he's doing what he should have done before writing the code, and finds his hands tied to a codebase and a framework that he probably would not have used if he'd taken time and effort to get the design right!
So to the guy asking the question... You cannot answer those questions without getting your design right... treat the code you have now as just a piece of code out there... then trust your laziness to chose the right tools to get the job done. If that's gonna be what you wrote yourself and the framework you're using now, or something else, who cares?
[...]
Re:It's knowing when (Score:5, Insightful)
The only difference is that efficient people actually get stuff done. Lazy people are just.....lazy.
my anecdotal evidence shows that lazy people tend to write the most nice code (to make life easier for themselves - futureproofing and all that) while "efficient" people are chugging out piles of shitty unmantainable code for 8 hours a day. I guess it's the old "work smarter, not harder" thing.
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: (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, Insightful)
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 (Score:5, Insightful)
You left out
5) Say No when appropriate
Re: (Score:3, Interesting)
Re:It's knowing when (Score:5, Insightful)
Well, I think the GP has a point. These days there seems to be more focus on worrying about the future than producing a high-quality product today (where quality means the least buggy product). Often you spend a lot of time creating sophisticated abstractions to ease future extensions only to find that the future is so different than you expect that your elegant architecture is just code bloat.
Re: (Score:3, Insightful)
Often you spend a lot of time creating sophisticated abstractions to ease future extensions only to find that the future is so different than you expect that your elegant architecture is just code bloat.
I don't. There's a different term for that - "Over Engineering". The OO fad has certainly contributed mightly towards encouraging over engineering.
Avoid putting artificial limitations into code where they should not and need not exist. That will do you well in most cases.
Re:It's knowing when (Score:4, Insightful)
The OO fad has certainly contributed mightly towards encouraging over engineering.
I don't think I would call a form of programming that has been pretty-much the dominant form for nearly 20 years now and is showing no signs of giving way to any other form a "fad".
I'm also not sure object oriented programming itself has contributed that much to *causing* over-engineering. It just makes over-engineering easier, so is particularly attractive to people who do over-engineer their code.
Reuse good code as much as possible (Score:5, Insightful)
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:Reuse good code as much as possible (Score:5, Insightful)
"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."
This is a similiar flaw to believing that ISO certification means that a company will always create great products. Just as each product should be evaluated on its own (the UL approach), so software should be evaluated on its merits, not on the reputation of the programmer.
There's no such thing as a "great programmer" in the sense that one individual excels in every aspect of software development. Average programmers (whatever that means) are quite capable of producing quality code. Quality code depends more on the dedication of the developers on the project than it does on programming IQ (again, whatever that means).
Re:Reuse good code as much as possible (Score:4, Insightful)
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.
Stuff like Perl + CPAN is also a very mixed bag and has likely caused my employer very much expense towards working around limitations in code therein compared to what has been gained. I know they've spent upwards of 6 figures on my time and others in direct and indirect costs working around the limitations and bugs in Storable, to name one example.
Re: (Score:3, Funny)
Code better than PEAR?
PHP's unsuitable
But knowing that, safe.
Re: (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.
prototype quickly, optimize later (Score:5, Insightful)
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: (Score:3, Insightful)
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: (Score:3, Informative)
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 fix
Re:prototype quickly, optimize later (Score:5, Insightful)
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.
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!
Re: (Score:3, Funny)
Why not use both options? (Score:5, Insightful)
Re:Why not use both options? (Score:5, Informative)
Re: (Score:2)
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).
Re:Why not use both options? (Score:4, Informative)
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:
Hibernate is successful in large part because it gives you a lot of options, so you can adapt it to your needs.
Re: (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 f
Use JDBC *and* Hibernate (Score:5, Insightful)
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 (Score:5, Insightful)
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...
How about contributing to OSS (Score:2)
Re: (Score:2)
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.
Wrong Question (Score:5, Insightful)
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
Re: (Score:3, Insightful)
Seriously, has that ever worked for you? (I assume you don't work on space probes.)
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:Wrong Question (Score:5, Insightful)
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: (Score:3, Informative)
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 th
Re: (Score:3, Insightful)
Re: (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 sam
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: (Score:3, Insightful)
Well, that's the wrong question as well. Only in highly structured environments can you collect all the requirements. And in those highly structured environments (ie: government, military, public safety) how many software projects come out meeting the requirements, are on time, and on budget?
The answer is probably very small. In fact, I'd guess that the only things that a highly structured development process gets you over a fast, iterative and mostly loose process are (1) CYA material, (2) aggravation, and
This question isn't about reusing code... (Score:3, Interesting)
Use JPA (Score:2)
Well.. (Score:2)
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 wi
Re: (Score:2)
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.
Re: (Score:2)
If you can reinvent the wheel, that is a way (Score:2)
What's up with slashdot lately (Score:4, Insightful)
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: (Score:3, Insightful)
Apparently you weren't here 2 years ago. These kind of question have been appearing on the front page for 10 years.
Other Slashdot Articles... (Score:5, Funny)
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?"
Re:What's up with slashdot lately (Score:5, Insightful)
Then why are there over 200 comments, more than usual? Good programming practice is an interesting topic for many of us.
Re: (Score:3, Funny)
Then why are there over 200 comments, more than usual? Good programming practice is an interesting topic for many of us.
Maybe it is just a boring day? Nothing of interest happening in the world?
That's some serious scope creep... (Score:5, Insightful)
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).
Re: (Score:3, Insightful)
I'd like to know what you dislike of Hibernate.
Where to start...
If you're writing something simple with very straight forward relationships and are able to define your database yourself up front it's not too bad. You lose some performance in caching, but also gain some in that hibernate does well using indexes to generate sane queries.
The idea that you don't have to hand code is only partly true. The low level database calls are indeed done for you but your mapping isn't - some of it is just moved away from
Re: (Score:3, Insightful)
Hibernate is a pretty good product. It has nice features that allows you to abstract tables into OOP representation. Joins can be specified optionally on column values. And while the XML can be hard to parse, it now allows for annotations to be done in the Java code itself.
That said, when Hibernate fails, it can often be hard to figure out why. It's error messages can be hard to parse, and difficult to trace where it originates. Also, I've definitely come across places where hacks had to be implemented into
Hibernate doesn't completely suck. (Score:2)
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
Re: (Score:2)
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
Mmmmmmmmmm (Score:2)
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
Yup, you've hit the nail on the head (Score:2)
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
Reuse, but not for reuse's sake (Score:2)
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,
ORM != Reusable code (Score:2)
Ecellent programmers (Score:2)
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: (Score:2)
And no, they don't need to spell~
When in doubt, roll your own. (Score:2)
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
The new requests coming in involve capabilities (Score:2)
"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 i
Re:The new requests coming in involve capabilities (Score:5, Funny)
You're the liason between programmers and customers, because you're good with people. Did I get it right?
boring (Score:2)
Always code it yourself. God will love you. (Score:2, Funny)
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'
Design First Then Build... It Just Never Happens. (Score:4, Insightful)
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.
Re:Design First Then Build... It Just Never Happen (Score:4, Insightful)
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.
Actually, if it's done right, that's the best thing to do. Why? You produce a first release _quickly_ without having to worry about the features that are several versions down the line. That release is adopted and the customer starts actually using it. Whatever happens, they're now actually getting the benefit of having the useful software that you have written for them.
And sure, they might decide that it's wrong in some critical respects. But at least they have _something_ to work with while you're making the changes they requested.
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.
I've never had a client who expects to get free changes to the working software I've delivered that meets their original spec, even when they decide it's not what they wanted. Well, OK, there was one. But the court agreed with me and made them pay up. That's in over ten years of professional software development. I've had clients who ended up with bills nearly double what they originally expected, but they've paid happily because they knew I delivered their original requirements, but those requirements changed. They know I charge per feature developed, and I always make sure they know before I start work on it what each feature will cost. Generally speaking, they're all happy with that.
Yes, code re-use is something great programmers do. But only if they have great designers who really think everything through first.
Some of the best code reusers I've come across are agile developers who espouse not thinking through anything beyond the feature you're working on at the moment. Reuse doesn't require ahead-of-time design, but it does require a lot of attention to detail. In the OO world, it requires a good understanding of design patterns (which means when not to use, as much as it does when to use them). It requires the ability to understand what your code is doing in great detail, and to hold a large chunk of that information in your head at once, to enable you to spot where another piece of code is doing something similar to what you're trying to do now. It requires you to have sufficient confidence to rework that old code to better fit its new application, where necessary (which normally means you'd better have good test coverage of it). But it doesn't seem to require you to identify the opportunities for reuse in advance.
Reuse the well done and code the rest... (Score:4, Informative)
Reuse:
Homebrew;
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.
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.
Hibernate (Score:3, Informative)
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.
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.
Good Programmers Abstract (Score:5, Insightful)
Where possible, you should never expose your choice to use an underlying technology. Instead wrap it in an Interface that exposes the functionality that your application requires and hide the implementation from the rest of your work.
Yeah! (Score:5, Funny)
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!
Re: (Score:3, Funny)
Nobody's buying that.
Re: (Score:2)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:3, Insightful)
I think the anonymous coward may have been trolling with the unconditional statement, but there is a valid (if expensive) point there and I would suggest a different (additional?) compromise: if you really want that 'complete understanding' for a brand new problem, write your own prototypes from scratch. Then choose and reuse a mature, complete solution (or write your own only as a last resort).
Wrapping an existing solution in your own APIs rarely teaches you much about the underlying problem - it helps in
Re: (Score:3, Informative)
That's absolutely incorrect. There are a number of reasons why someone would want to avoid using the STL string as-provided:
These reasons may not apply to 99% of the programming communit
Re:code from scratch (Score:5, Informative)
Re: (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 e
Re: (Score:3, Informative)
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.
Re: (Score:2)
*(I understand there is hibernate Shards, but I have some philosophical issues with that approach)
Re: (Score:2)
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 tryin
Re:Better Requirements Gathering (Score:4, Insightful)
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: (Score:2)
Re: (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 Hibernat