Slashdot Mirror
Reuse Code Or Code It Yourself?
eldavojohn writes "I began coding for a project that had simple requirements for my employer — Web services and a test application for them. But requirements have been creeping, as they always do. Initially I had decided to use the Spring Framework with Hibernate. And I re-used a lot of libraries that made things simple and quick for me. The new requests coming in involve capabilities beyond those of the frameworks. Now, I used to be told that good programmers write code and great programmers reuse code. It's starting to look like I would have saved myself a whole lot of time if I had written the database transaction using JDBC instead of Hibernate — now that I'm married to this object model framework, some of this stuff doesn't look doable. So what is better for the majority of software projects out there: reuse code, or code from scratch? What elements or characteristics of a problem point to one option over the other?"
It's not rewriting code or reusing code that makes you a great programmer. It's knowing when to rewrite code and when to reuse code that makes you a great programmer.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
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.
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.
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...
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
This is bad advice.
A system that has been tested for years will almost always be better than something new you've rewritten. Remember that it's more than a developer's resources you're using and no developer writes pristine code.
I've seen many projects that other programmers have said just absolutely need a rewrite and it's never ended well. Usually, they end up with more problems than they started with.
If you really need to sanitize the code base, wrap the old stuff. I've had much success with this
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?
In general it does depend on what application you re-use. If you reuse a poor piece of software you're building your product on shaky ground.
Now I actually don't like Hibernate and Spring all that much and I use them regularly. Replacing a whole bunch of boiler plate code with a whole bunch of boiler plate XML doesn't actually make your app less error prone. Introducing AOP makes it easy to code cross cutting concerns but can make it hard to debug and understand code as it becomes harder to trace (and instead of a pure stack, you again have to look at XML configuration). Then there's the massive overhead. I'm afraid their popularity is due to software as religion pushed by a culture of marketing, rather than being based soley on techical merit. Hell a few years ago EJB was the word according to Bob, and we all saw how well that went. Try finding a new project actively deploying EJB today.
That said, I've run into the limitations of those products, especially hibernate, and if your scope has crept enough that they were looking like a good solution, but aren't anymore, you need to address the scope creep first. Some creep is expected, and accomodating the business is always a good idea if you can manage it, but people go too far and forget that sufficient scope creep can and will make your project fail. You need to start by talking to the business and ensuring they have an understanding that the more redesign they do after the initial planning the greater the cost and risk. One other thing to watch out for. Make sure you evaluate whether each request is technically possible in the first place, and whether it is practical to attempt what has been asked with the resources you have. (I've often seen business people make requests without understanding the technical effort required. eg. request a change requiring a full blown compiler be written when the component was suppose to be a very simple parser and was scheduled to take 2 weeks to code. That's not entirely their fault. YOU are the technical staff and need to help them understand what is involved in fulfilling their request.).
Once you've addressed the scope creep, look at your application again and re-evaluate the tools. It may be possible to divide the project in such a way that you retain Hibernate and Spring for one part (and let's face it they're the defacto industry standard and are going to be the easiest to support in the short to medium term. Long term is harder to predict, but the less popular an approach is the harder it will be to find someone appropriate to maintain your app). The other part you can do with raw JDBC or another tool. (eg. you might find it's the reporting that Hibernate isn't dealing with adequately, so move to JDBC or a reporting framework that takes RAW SQL queries).
These posts express my own personal views, not those of my employer
If you want to write from scratch, write your own compiler and build your own system from melted glass. The time wasted encountering and solving a variety of problems already solved by others is very, very easy to describe, and there is little guarantee of even the limited success demonstrated by the best of the older code.
The amount of time I've wasted arriving after some in-house project that one person wrote, everyone got stuck with, and needed to be ripped out and replaced with the standard open source tool when that one person got transferred away or they discovered its limitations the hard way would have given me a month off of work every year of my professional life. Chat clients may be the worst of the bunch: watching those harsh lessons relearned by every sophomore who just learned a new language and thinks the new language won't run into the same issues is in for big, big surprises.
Always code from scratch. The time saved from complete understanding of your own code is hard to describe.
Well, that's certainly the least maintainable answer I've ever seen on the subject.
If someone has to come along after you and maintain the system, how do they know what it does? Did you document it perfectly? Of course not -- you wrote it, you know how it works, so you'll invest nothing in educating others.
When you use a library, framework, or a reusable whatever, not only do you get the functionality, but you get the available documentation and a potential pool of developers who are already familiar with that technology.
I've seen an awful lot of NIH (Not Invented Here) syndrome in this business, and I've seen so many "look, I wrote my own string class, isn't it neat?" that I lost count. No, it's not neat. The STL has provided strings in C++ since 1994 -- if you're writing one in 2008, it's because you're so incompetent you don't know the full language. And the same is true for many of the major technologies. I'm not saying Hibernate is or was the best choice for your shop in this exact situation, but it was likely a better choice than writing your own.
There's actually a solution that's kind of like a compromise, but offers some advantages: write a thin wrapper around the technology. You can either write a straight 1:1 wrapper, or create your own API, customized to be something you're comfortable coding against. You can then replace the technology with something better, when that something better comes along, and all you have to do is change the wrapper. The other reason this is a good choice is you can provide a mock object replacement for your API and run unit tests against it without bringing up an entire web environment.
John
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.
Actually, the trick is knowing that you _aren't_ a great programmer (honestly what are the odds that you are a great programmer?), and thus choosing to reuse code from better (and hopefully great) programmers.
If you wish to delude yourself, you can believe that you are a great but lazy programmer and thus choose to reuse code from other great (and more hardworking) programmers.
Stuff like Perl + CPAN is good because of all that code you don't have to write. The less code you write, the fewer bugs you make.
More importantly the less code you write, the less code OTHER people have to figure out. If you use popular libraries/modules whenever possible, other people can just go "Ah, the standard wheel", instead of going "He calls it a wheel but is it really a wheel? Better check, the bug might be there". Or they might even go "Ah yes, it's probably that bug in the standard wheel, when are they going to get it fixed already, meanwhile we'll do the recommended workaround".
You can also reuse "code" in other ways. For example - using a popular RDMBS is one way of reusing code. With a good database you don't have to reinvent transactions, row level locking and all that. Lots of smart people have done all that work already. And you can use the DB as a common "interface" for other programs (also written by other people).
A lot of the languages the CS academics heap praises on are powerful for the code you have to write, not the code you don't have to write. Yes it's probably a catch-22 thing, but when it comes to "real world", I'd rather pick the language where I don't have to write so much stuff.
Prefab may be uglier, but it beats spending 10 years carving that perfect sculpture all by yourself, only to have the customer say "erm I want a sculpture of my wife not my ex-wife...".
(Note I am not a great programmer, so feel free to ignore me).
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.
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 a lot of other ways, including experimenting / investigating solutions to reuse. But I think it misses the 'complete understanding' point.
Writing a solution from scratch (even a bad / hacky solution) does give you a much better understanding which is extremely valuable for you - that's why we do that for the classic problems all the time in college, after all. Of course, no one should be writing their own C++ string class these days, but if you wrote your own string class *once*, it helps you to understand the implications when you use the STL or something else.
But unless you are an academic, that's normally not what you are being paid for: you have a project to complete, and a specific problem to solve in the best possible way. Reusing a mature, tested solution is almost always simply in the best interest of the project - even if you do not learn as much as you would by writing your own.
On the other hand, if the problem is different and tractable enough, hacking your own prototype from scratch can give you better understanding that is applicable to any 'real solution' you adopt - and if kept simple enough, can be used for unit-tests, benchmarks or other purposes.
It's a matter of time and resources, but often enough prototyping your own wheel is well worth the investment - just use it as a tool to choose and apply the best solution for problems that are not well understood. Not as an excuse to risk the quality or cost of your project for the sake of pet projects and personal pride (which is often enough where NIH leads to).
Freedom is the freedom to say 2+2=4, everything else follows...
"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).
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.
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.
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.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.