Lambda vs Lambdas

This may sound like a superman character or a Hollywood movie brawl scene, with the good-hearted hero felling 10 baddies with a single swing of his arm. I could only wish if this was as defining as these fairy tales depict. However, the reality is far from it. This is probably one of the challenging situations most engineering teams implementing Lambda functions often go through.

Implement as a single big Lambda function or to break it down into multiple smaller Lambda functions? Trust me, this isn’t really a decisive good vs evil scenario, but this is something tangled between perfectionism on one side and pragmatism on the other. Or, better put it, it is down to Purity vs Practicality.

To set the context, here is an interesting situation

Young and enthusiastic software developer Joe Scriptor, often nicknamed as Mr Lambda, has been tasked with implementing a user-facing feature-rich Lambda function. This Lambda function is part of a synchronous call sequence and is expected to perform sharp and sleek.

Working in an agile and iterative development environment, Joe carries out his analysis and breaks the feature down into a number of independent smaller functions. Having succeeded on the first phase of the work, Joe now focuses on carrying out the implementation phase of the work.

For Joe, an admirer of the SOLID principles (as every software engineer should be), the first principle — Single Responsibility - passes through his mind. The way he identified the smaller functions perfectly matched with the very same principle. With a smile, he thinks he has found the perfect solution and starts churning out Lambdas.