About reinvention of a wheel, Agile and Linux way

How often in software development you think about rewriting some 3rd party module from scratch? Popular vision of the problem says that we should not reinvent a wheel and use existing paid or free components. That is right in general. How often something existing exactly fits needs of your project? From my experience I would say, “never”, especially if we are talking about some complicated UI elements. If my post is too long for you, you now can go to the summary.
Usual evolution of the problem looks like following. Product owner defines some requirements. Of course the project is moving with Agile approach, which means that there are no so clear requirements at the beginning, just amazing idea. Developers got the requirements, found huge 3rd party library with a lot of perfect features (let’s call it the Library further) to meet requirements and estimated integration in 16 hours. Everybody is happy, and even more happy after first 3 sprints, because application become a working prototype and everything is done quickly. Even more it seems that budget is big enough.
At this point product owners shows the project to his investors, friends or even some future users and discover that there are a lot of small things that should be changed. Bring all these things to dev team and got estimate for changes in the Library for 100 hours, more than two weeks of work. Why? We have used only 10% of the Library potential? Dev team answers that unfortunately they should change the source code of the library, because 10% of requirements are not covered by the Library. Fortunately the Library is open source. After 100 hours of modification of the Library QA team discovers a lot of defects in functionality related to the Library. Let nightmare begins…
Before fixing the defects somebody from dev team say we have to rewrite the Library from scratch it doesn’t fit our needs. But all other team members and product owner say, “No! It contains 10k lines code we have no budget and no time for rewriting it”. After that dev team will start permanent fixing of bugs and try to make the Library work in the way product owner wants. From now the Library will never have required level of quality. However at the very begging it was quite stable. If the Library is a part of key functionality of the project, the whole startup will most probably fail. In case of commercial Library we will have endless discussions with support and endless workarounds.
Is it familiar tale?
Another story is about startups which do everything from scratch to not depend on Microsoft, Google, put your favorite big company name here. They usually fail because they never create even working prototype.
Is there any solution? My answer is yes!
First you should accept that any open source or commercial library does what it does and nothing more. If you have access to it’s source code it doesn’t mean you can change it easily. If library contains 10k lines of code, it means that if you change something you probably will have regression in whole 10k lines of code.
Second. You should think about that 10k lines of code. Most huge libraries are too universal and you may not need every line of these 10k. Maybe required functionality can be implemented in 1k lines of code.
Third. Big universal components like UI libraries are very good, but they are good as is, as they are shown in demo applications. They are extremely good for MVP. But they are things in themselves. Changes or unusual application will be painful.
Now you ask what’s that got to do with Linux way. Linux way is “do one thing and do it well” this principal is also know as Unix philosophy – philosophy of modular software. Small and often old libraries are absolutely different things in comparison to huge libs. You can combine them in different scenarios and you will never change them, just replace one with “brick” with another.

1. Be quick with big all-in-one “Swiss knife” libraries or heavy UI control libraries, especially to create MVP. But never try to change them or apply them in unnatural way.
2. Don’t afraid to create even complicated thing from scratch. But do it with experienced and more important well educated developers.
3. Always try to use small and stable libraries to build bigger solution. You should understand that it’s absolutely different case in comparison to 1. There are a lot of small libraries and you always can build something big and complicated from this small bricks.
4. Always keep in mind that more lines means more regression after changes even if you change only one line. If you can throw away and rewrite JavaScript file with 5k lines of code – do it!