On Software Module Foundation
tldr;
Build on top of other’s shoulder. If you have to bring in true innovation, do it smartly. Incubation. A name, a gatekeeper, and a release cycle of its own.
We’ve all experienced it. The project we are working on as a new requirement. Easy as pie. Most likely a couple lines of code, merely wrapping some other library, or maybe bring in true novelty into the game. We wrote that piece of code several times over and we’re getting tired of it. Or we’ve seen things us people wouldn’t believe. Let’s give our team a new module to its foundation. So that other team members do not have to write that piece of code tomorrow, or next week. A little gift maybe. But wait.
Minimize Waste
First, lets reflect on our team’s core values and competencies. If what we’re trying to build is not part of such — yeah writing a template engine, a scheduler, a thread pool, or yet another logging framework is not as easy as it may first seems — maybe it would be a good hint to look for existing 3rd party instead. That should always be your first bet: build on top of other’s shoulders. Moreover, a piece of code that you don’t have to write is a piece of code that you don’t have to maintain, support, document, release and such. Let’s minimize waste.
Incubation
Now we have come to realize that while there are so many 3rd party options, none are tailored to our requirements (We are 80% sure!). That’s how innovation comes in. Our new module should be first developed as part of a bigger project. We’ve seen enough project developed in an ivory tower where no real user are thought of, or exposed to the end result. Once your module has incubated and matured for some time within your bigger project, now might be a good time to let it go free. Just make sure you are not Over-DRY (See Over DRY).
Live Free or Die
Once your module stands on its own and has its own life, you have to find it a home to grow nicely and cosily. It remains imperative that this module is attended to and is not left aside to rot, otherwise it quickly becomes a pile of junk, a pain in the ass to maintain, and better off plain dead:
- Give it a name! While it might sound overkill or ludicrous, a brand surprisingly brings in team bonding and generates enthusiasm, proud and satisfaction while leaving no one indifferent. Look around for your favorite open source project name, from big to small: spark, sinatra, backbone, brew, chef, docker, atom, kafka. Those certainly started as in-house modules. javascript-build-system? Meh. gulp!
- Someone on your team needs to be the gatekeeper, one that is in charge of making sure that module evolves in the right and coherent direction. Because it is always tempting to add more and more functionalities, discarding unnecessary additions is paramount. Feature creep is always around the corner. There is nothing to be proud of in a pile of incoherent junk that no one really master.
- Because that module can now be integrated into several other project, it needs to have a release cycle of its own, that is, not only a versioning scheme adhering to semantic versioning, but also the usual literacy such as a change log, issue tracking, documentation, and a roadmap.
Go on, give your team a gift, but a nice one.
Updates:
- Fixed typo
