To package or not to package - that’s the question in a digital agency (???)
Oliver Wang Hansen
Founder of Tidsmester ? | Tech Advisor ?????? | Board Member ??♂? | Empowering Startups, Scaleups, VCs, and Companies to Achieve Technical Excellence
On one hand a package helps your team optimising the time to market with a feature or functionality that you use over and over again. That sounds great! Less work..! Yes, BUT if you are a digital agency that develops custom solutions based on clients specific demands, then packages sometimes becomes a bottleneck.
Let me explain a little further..
As an example: let's say that you and your team decides to create a package that handles some business logic like “discounts on products” - the package will most likely be developed to accommodate that specific project / client that it has been build to.?
When another team then have to create some functionality in regards to “discounts on products” for a different client, then most likely they only need 50% of the logic that the initial package build have, then we have the headache.?
Should the package then be upgraded to also handle the new business requirements or should it just not be used? What developer / team will be in-charge of doing the update??
Another important aspect is also in regards to testing. Lets say that this “discounts on products” package have been used on several projects and a new feature gets released for the package.. Then we now have to ensure that it doesn’t break anything in the several other projects. Of course good testing and not just releasing blindly helps here.
So, should a digital agency never create packages? I would highly recommend not developing packages that is intended to solve business logic or anything that have been super specific to one particular client.
But, what can you then do to optimise features time to market - and what packages could you do??
Packages:
I have had good experiences with developing packages that are super loosely coupled to any business logic. Packages that more works as an abstraction layer for some boiler plate code. Another good way of using packages is to make interfaces with third party services for a service that you keep on implementing again and again. In this way then when the service provider updates and API or implementation, then the package layer can be updated and pulled down on each project that uses it. Once again, be aware of not binding ANY business logic in there.
Last but not least, then sometimes a generic interface component or library can be handy.?
领英推荐
The all over kicker to get success with packages in an agency environment is the ensure that the packages have extendableness. Because the likelihood of someone in your agency are in need of extending something is very very high!?
General templating:
Something that we use a lot in digital agency’s are templates that ensure that you start each new project with the necessary boilerplate code. One of the cool things by being in an agency as a developer is that you get to work on a lot of different projects. So the last thing you want to use your and the clients time on is re-writing the same boilerplate code over and over again - instead of focusing on the actual business logic of your clients. Boilerplates/ templates can be used both for server setups, project starts, support / misc classes etc.?
The good (and bad) thing with templating is that you aren’t restricted to only follow x logic like a package. On the other hand, then it also can give you grey hairs when you find a bug in something from a template that you have implemented on multiple projects. This mostly happens if something around your projects have changed, such as OS’s or alike.
Good places to share code / templating:
The most obvious is obviously on GitHub. Not sure I need to explain all of the reasons why this is a given (please feel free to DM me if you want the pointers)
Another up and coming platform that can help both organisations (such as agencies) and individual developers with code sharing of templates is something called https://snippet.codes. This little nifty tool basically comes with an array of different plugins to your favourite IDE’s and more to enable you to share snippets (or boilerplate) code between you and others. The awesome thing about this tool / service is that you also just can use it for yourself. I have all my life had a big GitHub repo with lots of different helper functions etc etc that helped me produce faster - but now with snippet.codes you can just build your own small library up and / or share it with a colleague or a friend.
-
So, the point of it all is like everything else within software development - There are no silver bullet, so use your brain, community and experience, then everything will be just fine.
Happy coding and packing (or not)!