Component-based development, or CDB, is an established practice for companies that build complex embedded systems. It’s not hard to find tangible results of this practice. Use a smart phone, drive a car, play a game on a device and you’re likely making use of an embedded system that benefitted from some form of CBD. For such devices it makes sense to have exactly one piece of software, a component, responsible for interfacing with that gadget. With embedded systems, that approach is quite clear.
For additional thoughts on IoT, see our earlier article on this topic, "Surviving the Internet of Things Revolution."
Applying CBD to Pure Software
But CBD is also becoming more popular in large-scale "pure software" organizations such as data mining and Big Data analytics. Unlike embedded systems (where some form of CBD is needed on Day 1), with large-scale software organizations it’s a model to which organizations evolve. Organizations commonly seek to "break the monolith," splitting their large, monolithic code bases into modules. They do so seeking benefits such as greater code reuse, higher quality and less testing effort in order to meet increasingly short software deliver deadlines.
It takes a mature and sophisticated software organization to reach that same revelation: That you should have just one place where there’s code to interface with a particular software widget. Take something such as an FTP server to which you want to talk. With CBD, there would be exactly one piece of software that interfaces with an FTP server and everyone would use that. It would be written once and, although it would evolve over time, there would be one named component that people would seek and reuse—or at least consider if reuse was better than building from scratch.
Once they reach a certain project scale, organizations either plan or blunder their way into doing CBD (in the latter case, out of pure necessity). Today’s agile software environments and consumer expectations for higher quality software, faster, demand it.
The High Cost of Building from Scratch
In a typical large-scale, non-CBD software development environment, developers build from scratch all of the time. In the moment in which they need something, that method often seems most expedient. But, when they take a retrospective look, they find dozens of vaguely similar implementations of that FTP connector which different teams wrote at different times, all trying to do more or less the same thing. The different implementations will have varying degrees of quality and testing and are all separately maintained.
Ultimately, this approach costs the organization more time and resources to initially develop than if it had been built once and reused, and costs vastly more in time and resources to maintain over time. Re-inventing the wheel creates high-interest rates on technical debt and increases the risk of missing key development milestones.
Adopting CBD involves putting in place standards for defining and publishing components, establishing standards for APIs and data sharing protocols, and defining a clear producer/consumer model for software build systems. In some cases, adopting CBD entails introducing layers into the build infrastructure.
In systems with very large numbers of modules, it is key to make it easy enough to search for components so that developers might actually do so, rather than starting from scratch each time to re-solve the same problem someone else solved weeks, months or years ago. A good search engine is fine for seeking open-source options. But large, internal corporate repositories of code and reusable widgets also need to be searchable.
Increasing the Pace of Development
Commoditization of components such as light sensors, gyroscopes and GPS is accelerating the fruition of IoT, a term describing an Internet for sharing data among gadgets, sensors and robots rather than humans. The ideas aren’t new but the increased pace of development of IoT initiatives is exciting. It is a force driving the retooling and optimization of software development processes and standards well-suited for massive software development efforts.
Although massive overall, typical CBD implementations involve many small teams, with only a handful of individuals working on any given component. Often, there are only a small number of subject matter experts for any single component.
Single Source of Truth
Whether you’re developing for IoT or breaking a monolithic code base into modules, a common theme with CBD is that there must be one source of truth for all manner of configuration information, including:
- A list of products to deliver and components from which they are built
- A list of active development streams (branches) to maintain (e.g., a mainline and two maintenance releases)
- A lists of component versions needed for each branch
- A tool chain
- Work spaces for developers and official builds
The need for strong configuration management is clear when you consider that any of those items can change at any time. A new version of a component may require a change in the tool chain if a newer version of a compiler is required. Supporting an old release of a product means seeing the list of components that were previously used, possibly including older compilers or older build systems.
A key to successful CBD implementations is tooling. There are a lot of opportunities for mismatching the various permutations of complex dependencies. It’s so difficult for a developer to get right that it must be made almost impossible to get wrong. The genius must be in the tooling so that developers can focus on the job at hand.
For example, in a CBD world, a developer can simply indicate, "I want to work on Friendly Greeting System (FGS) v1.4," and then have that input translated into a ready-to-use work area, with everything needed to start coding in real-time.
Under the covers of a good CBD environment, everything is versioned: The files, the workspace definition and the dependencies of all of the components. Developers can ignore all that and just get to work checking out code and submitting changes. They might change code and they might change configuration (e.g., updating to a newer version of some component they use) and, sometimes, both together. It is important that developers be able to review both code and configuration changes in a similar manner, and be able to coordinate and commit changes to both as a unit.
A strong version management system is the core of CBD infrastructure. The more CBD features directly available from the version control system, the less custom work is necessary to develop and adopt CBD workflows.
Bringing CBD In-House
Most organization deal with third-party products by using a CBD-like flow of some kind, even if they don’t think of it as CBD. They want to specify version X.Y of some third-party software (think: component) that they know works with their stuff. Bringing a CBD flow in-house starts becoming advantageous when an organization writes so much software that it needs to begin breaking its own systems up into layers, with consumers of components treating things they consume almost as if they were third-party products—at least from the perspective of other components and products that consume them.
Avoiding Technical Debt
In the end, CBD is partly about achieving efficiencies of scale for software development. Software development will always differ from manufacturing where the goal is to mass produce a zillion identical widgets as cheaply as possible. Software development applies human creativity to produce a series of changes to software.
As the scale of development increases, the analogy of software development to a mass production line becomes increasingly relevant, with a software change set being the mass-produced widget. The larger the scale, the more critical it becomes to manage and institutionalize reuse of code in order to ensure the software development "production line" is meeting the organization’s needs and deadlines. Companies practicing CBD are aware of this value and they avoid the technical debt that accrues when software is rewritten over and over rather than assembled.
