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?

  • What does your management think about the library? Do they know it isn't good?
    – superM
    Jul 25, 2012 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
    Jul 25, 2012 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, 2012 at 8:53
  • That's true, plus, we have a testing phase which will make it even uglier!
    – Aamer
    Jul 25, 2012 at 8:59
  • "85%" is not very close to completion (unless you've written fully tested code, ready for shipping)
    – user1249
    Jul 25, 2012 at 9:07

3 Answers 3


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.

  • 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, 2012 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
    Jul 25, 2012 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
    Jul 25, 2012 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, 2012 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.

  • 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
    Jul 25, 2012 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, 2012 at 9:17
  • This is actually quite close to "Designing by Contracts" which you like in another answer.
    – user1249
    Jul 25, 2012 at 9:18
  • 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, 2012 at 10:02
  • @Tia thanks to you, I will start adding the tests.
    – Aamer
    Jul 25, 2012 at 10:48

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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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