Slashdot Log In
Reuse Code Or Code It Yourself?
Posted by
kdawson
on Tue Nov 04, 2008 07:02 PM
from the good-or-great dept.
from the good-or-great dept.
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?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
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 ;)
Parent
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.
Parent
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...
Parent
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.
Parent
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.
Parent
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.
Parent
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.
Parent
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.
Parent
Re:It's knowing when (Score:5, Funny)
And people call me crazy for embedding Emacs in everything I write!
Parent
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.
Parent
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?
[...]
Parent
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.
Parent
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]
Parent
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.
Parent
Re:It's knowing when (Score:5, Insightful)
You left out
5) Say No when appropriate
Parent
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).
Parent
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).
Parent
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.
Parent
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.
Parent
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.
Parent
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: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.
Parent
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!
Parent
Why not use both options? (Score:5, Insightful)
Re:Why not use both options? (Score:5, Informative)
Parent
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.
Parent
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...
Parent
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: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.
Parent
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.
Parent
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
Parent
This question isn't about reusing code... (Score:3, Interesting)
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?
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?"
Parent
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.
Parent
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).
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.
Parent
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.
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!
Parent
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.
Parent
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.
Parent
Re:code from scratch (Score:5, Informative)
Parent
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.
Parent
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?
Parent