The AWS CDK offers an elegant way to share code across teams. However, when developing shareable AWS CDK libraries, it is crucial to consider the potential impact on downstream projects if the library is modified or misused by downstream developers. This blog post focuses on essential best practices for creating resilient AWS CDK libraries that prevent project breakdowns and ensure seamless integration in downstream projects.

In a tweet that I * *shared**, I highlighted the profound impact of agile in stimulating our brains to achieve our goals, while emphasizing how the waterfall approach can stifle our creativity and hinder the emergence of the best ideas. Agile, in essence, harnesses the remarkable data processing capability of our hippocampus. Let's consider Test-Driven Development (TDD) as an example: as we diligently write tests, the process triggers a free-flowing stream of code design from our unhindered hippocampus. By shifting our focus from the code itself to the tests, we effectively remove the obstacles that impede the hippocampus's signal transmission to the neocortex—the conscious part of our brain—allowing ingenious ideas to emerge. This phenomenon is not unfamiliar to us as humans; we often experience it when we step into the shower, go for a walk, or engage in activities unrelated to our work. Actively and consciously fixating on a specific matter can block the valuable signals from the hippocampus.

Modern agile embraces the concept of not estimating work, and one of the key reasons behind this lies in the infinite complexity inherent in software development. When we refer to 'infinite complexity,' we acknowledge that neither we nor the users possess a clear understanding of the eventual outcome. Attempting to speculate or plan without practical experimentation leads to an overwhelming number of potential outcomes. Consequently, many renowned software developers worldwide recognized that the traditional waterfall approach simply couldn't meet their needs.

Allen Holub does a very good talk about not using estimates for prediction. In an agile context, there are far better ways of predicting how long things will take. For example, predictions can be made through continuously working. As we add stories to the product, and complete stories for the product, we begin to see trends of when the completion dates will be. This is due to two reasons.

I've been discussing agile concepts with various folk. Here's some of my thoughts. Some of them are reiterations of things I've already said, but it doesn't hurt to rehash important concepts. :D