Technical Debt in Student prototype processes

Technical Debt (TD) is a metaphor coined by Cunningham Ward to represent sub-optimal design or
implementation solutions that yield a benefit in the short term but make changes more costly or
even impossible in the medium to long term. It describes what results when development teams
take actions to expedite the delivery of a piece of functionality or a project which later needs to be
refactored.

The technical debt originates solely from the requirements analysis then into software implementation
up to the last phase of the software development life cycle.

There exists risks in student projects due to poor requirements analysis, lack of skills in using technologies and poor documentation,
all these and other factors lead into a technical debt of projects by these young teams.

It is very common for software engineering student projects to incur technical debt during the development
process because of many reasons but mainly due to prevalent shortcuts. However, its presence
in student projects can lead to risks that degrade the internal quality of the product.

Such problems caused by the prevalence of technical debt in student prototypes may include the following;

1. Difficulty in maintaining and updating the prototypes: If the code-base used for designing the
prototype is poorly structured or lacks documentation, it maybe difficult for the students or
others to understand and make changes to the project.

2. Reduced performance: Code for the prototype that is not optimized or that is built on top of
poorly designed prototypes may result in slower performance or bugs of not only the prototype
itself but also can manifest in the final project product.

3. Difficulty in adding new features: If the project prototype has a lot of TD, it may be difficult
to add new functionality without incurring more debt.

4. Difficulty in understanding the problem domain of the project: If the prototype is not well-
designed, it may be difficult for students to understand the problem they are trying to solve,
which may lead to poor decisions and sub-optimal solutions.

5. Difficulty in collaborating with others: If the prototype is poorly structured, it may be difficult
for other students to contribute to the project or for the students working on the project to
collaborate effectively.

6. Difficulty in meeting the project deadlines: If the prototypes have a lot of TD, it may take
longer to complete and may cause students to miss deadlines.

These risks affect the future prototype evolution through technical rework and improvements and
subsequently making such rework expensive in terms of needed resources on the project.
Identifying the likelihood of Technical debt as early as prototyping stage helps in managing
the risks that could cost the project.

Jan. 31, 2023, 6:43 a.m. | Authored by Mugoya Dihfahsih

create username To join the discussion