When developing software, velocity is a key word and an important KPI. Delivery velocity depends upon many factors, including environment, choice of language, toolset, and the use of code written by others that has already been developed and tested. As we move up the code maturity model, this code is migrating
from the libraries that are compiled or linked into a project into calls to other services on different platforms using APIs to perform essential but non-core parts of the service.
As with the travellator at airports, some species of caterpillar increase their speed of travel as a group by moving in two or more layers. The bottom layer crawl along the ground, the second layer move along the backs of the bottom layer, at twice the ground speed. The caterpillars can increase their speed still further by adding a third layer. If you haven’t seen the clip of this in action, or any of the excellent Lego reconstructions they are worth watching.
So it is that in software development to increase speed of development, ROI and competitivity we must make best use of these lower layers and recognise that they too are moving.
https://www.geek.com/science/caterpillars-go-into-turbo-mode-on-video-1557211/
Why reinvent what is already available? It has probably been done cheaper than you can do it, is being tested by many other companies so ought to be more robust, and is subject to market forces, so will have competitors that should keep it honest and good value. Companies recognise that these services have more value by wrapping them in an API as a service rather than selling or providing the library. From the giants providing the platform & infrastructure to niche services providing email, SMS, logging, weather or flight and car information the knowledge of what is available as a service (PaaS, Iaas or SaaS) is as vital now as the knowledge of what is in a library.
The good development team will therefore look for libraries and services to avoid rewriting. By designing a good interface to these services, the team can also isolate themselves from any specifics and maintain their velocity allowing them to change providers as better, faster or cheaper services become available.
As with code, using the most efficient tools will ensure that this area of technical debt remains low. This frequency of switching will depend upon the tool lifecycle. In new areas such as automated deployment, where the toolset can be immature, the best tool might not be obvious, so the team should design to be able to swap if necessary. Whilst swapping tools will take time, it has the advantage of ensuring that the knowledge of the process is kept current, and that new patterns or practices can be implemented.
As a technology strategist I see and help many development teams that are still too keen to rewrite what is already available, using resources that could be better used to build more value into their product and therefore to the business.
As it was good enough for the £2 coin, I shall also borrow from Isaac Newton:
If I have developed faster, it is by standing on the shoulders of giants.
(image by A Bockoven)
By Chris Galley.
Contact us for further information