It’s the reason that Agile has utterly eclipsed Waterfall as the dominant software development process.

Why is smaller better?

Smaller is more understandable.

Smaller is more portable.

Smaller is more efficient.

Smaller is more performant.

Smaller is more robust.

Smaller is more flexible.

Smaller is more impactful.

Smaller is more communicable.

Smaller is more practical.

Smaller is more simple.

Smaller is more clear.

Smaller is more deliverable.

What kinds of things should you make small?

Development Process

Development team size.

Feature scope.

Number of changes per release.

Duration between releases.

User story scope.

Ticket/task size.

Architecture

Component contract size.

Number of changes required to add a new business rule.

Amount of external integrations.

Component responsibilities.

Cross-component messaging traffic.

Source Code

Project build times.

Class size.

Method size.

Abstract interfaces.

Suite of required development tools.

Amount of data encapsulated in an object.

Number of method arguments.

Source code files per namespace.

Deployment

Number of steps required to deploy.

Number of environment dependencies.

Number of subcomponents to deploy.

Number of people required to deploy.

There are numerous others.

Make It Small

Simple practical heuristics improve my life substantially. As a developer, the continual trend towards smaller has offered me tangible benefits. There are many different ways to improve your software developments process.

If you have lots of time and patience, go and read many software development books. Read all of the experts’ blogs. Learn the latest trends and methodologies. Write code that conforms to the SOLID principles. Become skilled at creating comprehensive automated test suites. Experiment with practical ways to reduce development pain points. This will get you the most value.

However, if you want to get the majority of the benefits at a fraction of the cost, then just follow this simple heuristic: Make It Small.