I like working for startups. The main reason it that you create new things. Things that haven't been created before. The other reason is that you have a lot of freedom in your technical choices and you can choose the tools that are the most appropriate for the situation (which is not always the case in big companies).

However, working for startups brings many challenges. The main one is that you want to move fast. In software that often means you have to reduce code quality. That will slow you down over time, but...you have to move fast.

Another challenge is that you don't know your domain well and the problem to solve. Actually, you want to solve a problem, but you can discover that your users want to solve another problem with your product. Therefore, you might have to redesign things.

How Amazon Q Developer can help?

Amazon Q Developer is a GenAI Coding assistant, provided by AWS, which generates code from a natural language description, but it's also used explaining, refactoring, optimizing, securing, ...

As an architect, it's also a very good "architecting" assistant. It can generate code from a diagram but also a diagram from the code, which for me is a great new capability.

As of today, my intuition makes me feel it's a super powerful tool to increase code quality and ease software design evolution.

That's what I try to prove in this article.

The context

I recently worked for a very small startup, which needed to analyse videos and especially audios from these videos.

This doesn't sound difficult today, but it's not trivial to implement. Especially when you start from scratch and when the application will be used by real users one week later!

By chance the front end was already developed with a No Code solution, however a complete backend had to be built on AWS.

The Architecture starting point

When you start a project, people often come with a design of the solution and we can have the feeling that if you follow that solution, everything will be working well.

That never happens in software!

Here a simplified representation of the AWS solution that I was proposed before I started the project.

The foundational Architectural Decisions

Why serverless?

AWS pioneered serverless technologies, and it's not only lambda functions. For instance, Amazon S3 (the AWS object storage service) is considered as serverless, because you do not manage any server.

Not only you manage less servers, but you also manage less availability, less security, less scalability, less network, ... all these things are AWS's problems.

That makes it an ideal choice for startups which want to move fast.

Why a lambda-lith?

Building a distributed architecture based on events can be hard, but also difficult to maintain, debug and evolve.

I like the idea of "Monolith First", popularized by Martin Fowler, and I wanted to apply this to my serverless architecture, because I think it brings the same benefits.

So, I started to write the algorithm in one lambda only, instead of multiple lambdas.

Why the AWS CDK?

The CDK (Cloud Development Kit), is a library that helps you build infrastructure as code with imperative/Turing complete languages like python, java,... instead of declarative languages like Yaml, Json, ...

That brings more possibilities, and you can build things much faster with more safety because CDK components "encapsulate" multiple low level components and best practices.

Among many CDK benefits, I do not have the feeling that I spend more time playing with IAM Policies to apply least privilege principle than building my architecture.

For example, when I write

...

lambda.grant_read(s3_bucket)

...

This simple line of code will handle all the policy generation with just enough privileges. That saves a lot of time and brings more serenity.

The quick and dirty phase

The main architecture constraint was the performance of the analysis. Therefore, I first needed to create a workflow that would be realistic enough to prove the choices were the best regarding performance. I didn't want to discover the wrong choices were made after one week of work!

That's where lambda-lith is interesting because you don't focus on distribution first, you just concentrate an measure what is interesting for you. I know that distribution can increase performance, but do we need it now? I think that the old adage: "Premature performance is the root of all evil" is still relevant in the cloud!

This is where I started to use Q, and asked it to help me create my Infrastructure with the CDK V2.

@workspace generate CDK v2 template from the draw.io diagram

Since I had a bit of algorithm to develop inside the lambdalith, I asked Amazon Q to help me.

Then I tested the entire workflow and I proved we were under the expected duration.

Rewrite almost all code!

When the quick and dirty phase was finished and that I could prove performance was not an issue with this architecture I decided to rewrite most of my lambda code!!!

Remember I produced quick and dirty code, and leaving this code as is, was risky. After a just few days, it could have been more and more difficult to maintain or change because it's hard to code fast and keep good quality (at least it's hard for me).

But actually... I did not rewrite the code... I asked Q to rewrite it!

I did it in 3 steps:

• Generate the sequence diagram from existing code


• Generate new code from the diagram


• Generate tests from code.

create sequence diagram

First, I asked Q to create sequence diagram from my quick & dirty code.

The benefit for me is that Amazon Q is a better developer than I am, and I can see a better written and a better organized code very quickly.

Generate unit tests from code

Unit tests are a simple concept, they are automated tests that you execute to make sure your code is still working after you change it.

This is often something we wish we had. However, behind an apparent simplicity it's not easy to write them or to master techniques like TDD (Test Driven Development). Therefore, these tests are often overlooked.

But with GenAI, you have no excuse. Generating them is easy with Q:

write unit tests for that code

The feedback loop & code refactoring

With test harnesses you can put in place a very short feedback loop. Therefore, every change that breaks something in the workflow will be detected immediately and you can roll it back right away.

What's the advantage?

First, in the software development process, when you discover that something is broken one day or even one hour after the mistake was made, it's often much harder to fix it compared to fixing it when it was just introduced. Unit tests are a way to move faster.

Second, without test harnesses, even simple things like renaming objects in your code, and that can happen quite often when you don't know your domain well, can become very difficult, because you fear the application will break. So you don't take the risk and leave inconsistent names, making your production harder to understand and maintain. Unit tests are a way to redesign things with more confidence.

Setting up your environment for a short feedback loop

One trick I use is, each time I save a file, all my test suite is executed. With pytest I just add to install this plugin:

pip install pytest-xdist

So, now each time I modify a file, it runs all my tests automatically, each time I make a mistake I roll back immediately.

Here is an example of my test suite running when everything is green:

The feedback is very quick, and that's very comfortable.

Ask Amazon Q Inline chat to refactor your code

From my point of you, refactoring is at the heart of software development. It's very important, but almost never practiced.

Refactoring is a technique where you improve the quality/evolvability of your code, without changing its behavior.

Refactoring is not trivial, it takes time and requires reflection, but today you have a very good friend to help you out: Amazon Q Developer!

Q Developer has an impressive feature that I use to refactor my code: Q Inline Chat.

For example, I simply select the chunk of my code I want to refactor, then I press Ctrl-I, and type "refactor" in the dialog box:

Now that the code is refactored I can check if my tests are still passing.

Then, I launched the tests against my working code (the one I gave to Q), to make sure the test was green.

Then, I replaced my working code with the non working code in my function, and I ran the test again.

The test was red as expected, and it showed me differences in an input data format! In fact, this input data format was slightly different between the two versions of the code.

Here is what I really started with:

This architecture was built on time, it was production ready and has been used by real users!

That was a challenge I could overcome while keeping a good quality and evolvability thanks to my developing/architecting assistant. Maybe that will be normality in the near future, but today... it blows my mind!

Conclusion

This project was ideal to demonstrate the benefits of Amazon Q Developer to kickstart new and innovative projects with good practices.

With Amazon Q Developer, I could rewrite dirty code, add unit tests and put in place a short feedback loop. I also used it to refactor my code in order to keep a good quality and allow evolutionary design. I don't think that would have been possible without it in such a short amount of time.

Of course, I don't think we can overcome all startup challenges with Amazon Q Developer, there are many other dimensions. I am also wondering if that could apply each time or to bigger projects. I don't have enough experience with it yet. But again, that looks very promising!

Links

https://martinfowler.com/bliki/MonolithFirst.html