Choose technology for the team after handover

Who makes the next change?

A technology decision also concerns the team maintaining the application after handover. Can they change the right source, check it and trace problems? This question complements functionality and the effort of initial development.

Google’s code review guidance explicitly considers developers who will use the code later. For tool selection, we therefore suggest walking through a typical later change with the intended maintenance team.

Example: the same address addition, different workflows

This plan is fictional. The options are a widely used framework familiar to the future team and a custom form generator currently understood by the delivery team. The generator is expected to speed up initial form creation; no measured time saving is available in this example.

Both options need runtime details, package sources, checks and understandable documentation. With a generator, where lasting changes belong must also be clear. A manual correction in generated files may be lost on regeneration. Check this instead of automatically treating delivered files as maintainable source.

Make maintenance part of the choice

SEI includes modifiability among key architectural qualities. Record who maintains dependencies and tools, what support is needed and how cover works. A documented introduction can close a knowledge gap; file access alone cannot.

A custom generator can be justified for suitable tasks with dependable maintenance. A widely used framework also requires knowledge, updates and clear ownership. Evaluate both against the same later task and document remaining dependencies.

Sources

• Google: What to look for in a code review

• SEI: Software architecture