Challenges of working with a shared codebase

Ghanam et al. (Ghanam et al., 2012) conducted an ethnographic study among a large number of software teams working with and creating reusable components. According to Ghanam et al.

2.3. What is working on a shared codebase? 23 Team 1 Team 2 Shared codebase Component Component Component Feature backlog Feature 1 Feature 2 Feature 3 Feature 4 Feature 5

Figure 2.4: Feature-driven development.

the following challenges structure exists in these environments:

• Business challenges

– Business strategyTo accommodate new products when the business strategy shifts towards a new market segment, changes may be required to the platform which can affect the support by the platform of other products.

– Product-driven/platform development

∗ Instability Some components may not be stable enough to be used in the plat- form and causes problems among products, for example when they are updated frequently or contain a lot of defects.

∗ Dominance of a mainstream productWhen there is one main revenue gener- ating product, the priority of the development effort may be tightly coupled to the need of that product. This may cause the platform to become under-engineered. ∗ Competing goals Business goal (for example: fast delivery) may conflict with

the adoption road map of the platform by products (technical road map).

• Organizational challenges

– Communication

∗ Among platform teamsRequired to (1) assign responsibilities to components (2) resolving dependencies among components (3) agreeing on protocols and in- ternal interfaces (4) synchronizing releases (5) arranging sharing of resources

∗ Between platform teams and application teamsProduct teams for example

need to no how to access platforms in order to integrate components

∗ In distributed development For example: physical separation of teams may lead to communication deficiencies .

∗ Between business units See silo’s.

∗ SilosA silo can be seen as the result of an organizational structure where business units or teams act as independent entities having their own local management and no motivation to adhere to a centralized decision-making body or to share information with other units.

∗ Decision-making On what organizational level should decisions regarding the platform be made? Centrally or leave it up to the teams?

∗ Stakeholder involvementWho to involve in the decision-making process and design of platform components?

– Agile culture

∗ Feature vs component teams Agile development is more focused on teams

having end-to-end responsibility of features whereas component based focuses on teams working autonomously on some sub-system. From the research conducted by Ghanam et al. it seemed that a combination of both was needed in order for the subject company to be successful in adopting a platform strategy.

∗ Team autonomyThe risk of having high autonomous teams together for a long time is that they turn into silos.

∗ Business-value thinking When working in an agile environment, companies tend to have a ‘deliver direct value for the business’ perspective. Moving to a platform strategy then has zero visible value for customers, hence the organization has to motivate teams and justify the investment required.

∗ Product ownership thinking Teams can be protective of their assets which then makes the transition to a platform difficult.

∗ Agility versus stabilityAgile is focused on accommodating change, which may cause trouble when also wanting a stable platform.

– Standardization

∗ Of documentsWhen documentation standards are not consistent across team- s/business units, people are less likely to refer to them

∗ Of practicesSoftware reuse requires code conventions and testing standards in order for developers to be willingly to reuse code of others.

∗ Of tools and technical solutions Reuse can be difficult if different version control systems or testing platforms are used.

∗ Of acceptance criteria When components are proposed to be added to the

platform, standardization of acceptance criteria is required.

• Technical challenges

– Commonality and variability

∗ Reuseduring development developers constant need to look for opportunities to reuse and detect redundancy in the platform.

∗ Variation sources Variation required to support by the platform may have different sources; for example business needs or customer needs.

∗ Cross-cutting concernsA change may be needed in not all products, but for example a sub-set.

– Design complexity

∗ Different actors Variability can be driven by the business trying to target different market segments.

2.3. What is working on a shared codebase? 25 ∗ Requirement of combinationsThe requirement from the business to combine

components and services to build unique products.

∗ Requirement of maximizing reuseFor example when designing a platform for different hardware platforms, components must be as general in use as possible. Developers must be agnostic to this aspect.

– Code contribution

∗ Accessibility/retrievabilityVisibility of assets, either code or documentation. ∗ Platform qualityWhen different teams change different parts of a platform on regular basis, quality of the platform may be affected. An audit program can resolve this, but without standardization of acceptance criteria across teams and business units this is difficult.

∗ Platform stability Changes, ideally, need to be tested against all products which requires a technical solution where the build is forwarded to all environ- ments.

– Technical practices

∗ Testing What should be tested in the platform and what in the context of the specific applications? Should a change be tested on all instances of the platform? ∗ Continuous integration Updates need to propagate to all environments. ∗ Release synchronizationSynchronizing releases of different components; what

component is supported by what version of other components?

• People challenges

– Resisting change Adopting a platform strategy may be difficult when people are not seeing the value of the change, perceiving the change as irrelevant, or having to make adjustments for the new work environment.

– Technical competency People need a specific set of skills to write platform code, because it requires knowledge of reuse patterns and design paradigms.

– Domain knowledge Engineers need to have domain knowledge in other to make

decisions regarding what is important for the platform and what for a specific appli- cation.