About reinvention of a wheel, Agile and Linux way
How often in software development do you think about rewriting some 3rd party module from scratch? The 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 the following. The product owner defines some requirements. Of course, the project is moving with an Agile approach, which means that there are no so clear requirements at the beginning, just an amazing idea. Developers got the requirements, found a huge 3rd party library with a lot of perfect features (let’s call it the Library further) to meet the requirements, and estimated integration in 16 hours. Everybody is happy, and even happier after first 3 sprints, because the application becomes a working prototype and everything is done quickly. Even more, it seems that the budget is big enough.
At this point, the product owner shows the project to his investors, friends, or even some future users and discovers that there are a lot of small things that should be changed. Bring all these things to the dev team and got an estimate for changes in the Library for 100 hours, more than two weeks of work. Why? We have used only 10% of the Library’s potential. The 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, the QA team discovers a lot of defects in functionality related to the Library. Let the nightmare begins…
Before fixing the defects somebody from the dev team say we have to rewrite the Library from scratch, it doesn’t fit our needs. But all other team members and the product owner will say, “No! It contains 10k lines code, we have no budget and no time for rewriting it”. After that, the dev team will start permanent fixing of bugs and try to make the Library work in the way the product owner wants. From now, the Library will never have the required level of quality. However, at the very begging, it was quite stable. If the Library is a part of the key functionality of the project, the whole startup will most probably fail. In the case of a commercial Library, we will have endless discussions with support and endless workarounds.
Is it a familiar tale?
Another story is about startups that do everything from scratch to not depend on Microsoft, or Google, put your favorite big company name here. They usually fail because they never create even a 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 the library contains 10k lines of code, it means that if you change something, you probably will have regression in the 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 the 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 principle is also known as Unix philosophy — the 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.
Summary
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 an unnatural way.
2. Don’t afraid to create even complicated things from scratch. But do it with experienced and more important well-educated developers.
3. Always try to use small and stable libraries to build a 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 these small bricks.
4. Always keep in mind that more lines mean more regression after changes, even if you change only one line. If you can throw away and rewrite a JavaScript file with 5k lines of code — do it!