Arieh's Weblog

In my position(s) at Sun I have been involved in the design and development of software for systems management (primarily storage, although not restricted to it).

In general, the nature of these systems has been that they are distributed, that many different projects end up contributing components that yield a composed system that changes over time with the addition of new components (for example, support for new devices, or additional/enhanced functionality added).

During the development process, I have found that many problems arise due to unexpected incompatibilities between the cooperating/collaborating/dependent pieces. Many of those are triggered by inconsistencies in API revisions, reliance on divergent versions of software used to develop, lack of communication and access to usable software units between teams contributing pieces.

I have found that once one understands the distributed/component-based nature of the software that is created and how it operates in the deployed environment, the implementation of specific development processes/practices that take that (component based) nature into consideration is bound to reduce the problems that will surface later (at the customer's site once the software is deployed), by catching those much earlier on, ending up with a better product that will satisfy customer needs and reduce maintenance costs.

I will enumerate a number of entities/processes that I have seen helping in developing for a component based architecture.

I view the establishment of a Common Build Environment (CBE) as a fundamental piece of the infrastructure to be set.

The goal of the CBE is to establish the shared infrastructure to support the process that the teams developing components will rely on, in order to:

• insure that appropriate revisions of dependent software are used (this may include the version of JDK and Java libraries that are determined to be used, as well as other 'systems-type' software)
• insure that components that have dependencies on other components have access to the latest-and-greatest (as well as to the previous) versions of the latter.
• insure that an individual developer compiles, builds, packages, regression-tests the software unit on which he/she is making changes as part of the ongoing development cycle prior to incorporation into the shared repository
• allow the development of nightly-builds (or appropriate period of choice) for each component, which coupled with validation smoke and regression tests that through their interaction with their dependencies, will allow to catch bugs early on, with reduced impact on the development.
• make sure that components that passed the validation 'smoke' and validation tests are promoted to be visible in the component repository for others to use/access.
• be able to develop integration-tests that allow to validate the system at development time to the extent possible.
• a system/process for tracking the workflow of development, in which a developer submits what I call a check-in request form through which the type of change to be made is described, annotations/approvals of design, code, integration into source trees are incorporated, as well as other types of relevant information. This workflow form (which could be as simple as a plaintext mail message that is forwarded and annotated) can also be used to indicate the correlation of the code change with a problem reported in a bugs database.

While understanding that Software Configuration Management (SCM) systems are able to address many of the above, I believe that organizational and engineering discipline are elements that even though being hard to enforce, if carried forward have the potential for enabling us to develop better software, in a more efficient and predictable manner.

We have all ran across skeptics that will argue that the apparent overhead is too costly in these times of rapid prototyping and development, we have too often seen that you can pay me now, or pay me later (more). To wit, I have seen enough cases when a developer's incorporation of just a tiny change to the source tree, ended up breaking the build and impacting the whole development team for a period of hours.

I will talk more in detail about many of the issues above in later notes.

I would like to hear from you about your thoughts on this topic.