Development kits are the glue for developers
When I was being recruited by Storm, one of the first things we discussed was their SDK for developers to use on big projects — that just so happens to use conventions and NHibernate.
My first reaction was ‘oh dear lord, not SharpArch!’ But after learning it was developed in-house, and working with it after sealing the deal, my fears were diminished and replaced with keen interest.
It took me some time to grasp the concepts behind the kit, but it wasn’t until I had to strip the source code down – to see how to integrate a new component – that I truly understood and appreciated the ingenuity behind the work that went into creating it.
The parts work together in a way that, to someone in the dark, appears almost like magic.
A class, which might seem almost insignificant or useless, in fact fills a role that is crucial for the SDK to be even capable of existing.
It was a wonderful learning experience — knowledge one can obtain from simply getting to understand its source is vast! I would dare say that the SDK is a work of art. Flawed, still, in many ways – but a work of art nonetheless.
Recently our core development team decided to get started with porting the SDK to a new platform. Spare time in my stack gave me the opportunity to play around with recreating the core parts and discussing the process with other developers to get their feedback on changes and improvements.
This meant understanding the reasons for certain decisions in the first kit, such as the careful selection of design patterns, the clever use of nuances exploiting some of the mechanics in the core of the platform and language to solve tricky problems, and the chosen set of conventions to make maintaining each other’s projects easier and clearer.
The SDK is more than simply a collection of code to reduce development time.
It represents the collaborative effort of the developers. It represents their understanding of software development, of design patterns, of a set of almost unspoken yet unanimous agreements and contracts between them; the display of both passion for and skill in programming obtained through years of practice.
Working on a project from different developers thus, while retaining its easy navigation through conventional core, offers plenty of unique and alternative solutions to various other problems not covered by the kit.
Participating in discussions on how to change the inner workings of the SDK has brought some truly interesting concepts and ideas to the table. It has allowed even more knowledge and new information to be available for learning and becoming closer – by making mutual agreements and compromises as a team. At the very least, I have gained fantastic insights to the ways other developers think and work; to their preferences in coding, as well as their development-related interests. We needed a project to focus our collaboration and bring our individual skill sets together.
An in-house SDK can be a banner under which developers can stand proud together. Like a dictionary from which to learn. To contribute new ideas. To help and evolve. A common goal. Unity of effort. A team with one purpose.
Like the way we work as a dev team? We’re hiring — check out our current vacancies.