Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am facing some issues with a buggy library I currently have and it's used in my current project, I need to finish this project as soon as possible in order to deliver it to our client.

However, this library is horrible!

Lots of bugs, lots of errors and bad performance, I thought to write my own library to handle what that library handles (GUI/Graphics and some Data manipulation) but I lack time to do it.

I have wasted a lot of time repairing this library thus I am very close to my deadline with 85% completion and still lots of bugs I face and fix everyday.

Maybe you will ask me the following question:

Why did you use it in the first place if you knew it was buggy?

I will answer that question, the reason why is because the buggy library is considered a standard in out company; plus, I am not the only one who thinks that library is buggy, almost all developers hates it!

My question is, should I deliver the current project with that library then develop a new library and use it to enhance the project after that deliver it to the client again as an update, or develop the new library and restart the whole project using the new one? and why?

share|improve this question
    
What does your management think about the library? Do they know it isn't good? –  superM Jul 25 '12 at 8:48
    
They think it is a good library with tiny issues, we tried to raise that matter to them but no use. –  Aamer Alduais Jul 25 '12 at 8:51
2  
Try to count the time that you spend on fixing library bugs (time:bug), and time needed to re-write the library. If these are close, you could probably convince your management. I wouldn't re-write it right with 85% of work done and little time left –  superM Jul 25 '12 at 8:53
    
That's true, plus, we have a testing phase which will make it even uglier! –  Aamer Alduais Jul 25 '12 at 8:59
    
"85%" is not very close to completion (unless you've written fully tested code, ready for shipping) –  user1249 Jul 25 '12 at 9:07

3 Answers 3

up vote 5 down vote accepted

As I was told: "A 80% solution in time is better than a 100% solution too late". I'd finish it using the legacy library and deliver an update later. It is important to plan this update in advance, ideally now. As mentioned by ElYusubov, Design by Contract is a good keyword. You could keep the interface of the library, in that way there would be a sooth shift, even in other projects. If the interface itself is that flawed and rusty, a Bridge might be helpful.

share|improve this answer
    
The interesting question is whether the library can actually do what is needed. If it is buggy it may not - the sooner you know the better. –  user1249 Jul 25 '12 at 9:23
    
"A 80% solution in time is better than a 100% solution to late"....That's so true! OK then, I guess I will finish the project with this library after that I will deliver an update to the client with a new library and that's better for now. Thanks Vain! –  Aamer Alduais Jul 25 '12 at 9:24
    
@Thorbjoern: the library will do the rest of the job with a lot of core modifications and tests but that will make the delivery of the application quick for now at least until I finish developing my own library and replace the old one with the new one. –  Aamer Alduais Jul 25 '12 at 9:26
3  
@AamerAlduais you may also simply provide correction patches for the old library when you fix the bugs. The time before you finish developing your own library may be longer than you think. –  user1249 Jul 25 '12 at 10:35

I would consider writing a set of unit tests for the library in question, which exercise just the functionality you NEED from the library (but do so fully), and then see if the library works correctly for just what you need or if you trigger enough bugs for it to be unusable.

If not you now have a set of unittests from which you can easily create your own library.

share|improve this answer
    
True, but I am afraid that writing unit tests for the library will consume a lot of time and I need to deliver the application as soon as possible. –  Aamer Alduais Jul 25 '12 at 9:15
    
It is my guess that it will be faster to test the library in isolation and then integrate it, than to test it as part of your final application. –  user1249 Jul 25 '12 at 9:17
    
This is actually quite close to "Designing by Contracts" which you like in another answer. –  user1249 Jul 25 '12 at 9:18
    
I agree with that, Thanks a lot Thorbjoern! –  Aamer Alduais Jul 25 '12 at 9:20
1  
@AamerAlduais I think you can start by adding test case for your bugs you are going to fix, so it won't take much time and it's ensuring you that your bugs from now are not going to reoccur. –  tia Jul 25 '12 at 10:02

As you have also mentioned, first wrap-up your project and try to deliver on time as soon as you can. However, while delivering project replace dependencies on your so called "buggy library" through introduction of the Design by contract principle.

enter image description here

In some terminology it is called Programming with Contracts, where a contract merely defines the requirements of a particular class; it does not actually control the class implementation. The purpose of a contract is to make sure that the intended design specifications are satisfied and not at conflict with each other. In other words a contract helps identify design flaws.

share|improve this answer
1  
Wonderful idea! I will give that a shot with a small and simple application first! Thanks! –  Aamer Alduais Jul 25 '12 at 9:06
    
@AamerAlduais, sure no problem. This is also one of the best practices to follow. –  Yusubov Jul 25 '12 at 9:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.