Feature Launch Postmodern

Postmodern

The first feature that I have developed at AWS taught me two things:

• Bad things will always happen, so when estimating the launch date, give it a bit more time than you expected.

• Launch a “perfect” feature or launch nothing at all.

Bad things will always happen

Here’s some explanation for the first thing that I learned. No matter how good you are, there is always something that you can’t control and causes some delay to your feature. Your code review could take longer than you expect because your colleagues are busy with their works and have limited time to review your code. The pipeline could be blocked due to unexpected issues such as organization campaign or sev2 ticket. Your deployment could go south and you might need to rollback your code. There are many many more issues that you could encounter, some of them can be anticipated but some of them can’t. It’s not the end of the world to delay the launch of a new feature, but it does cause some troubles to your manager and the product manager. Thus, estimate better, and always give a little bit more time to the feature at the beginning.

Launch a “perfect” feature or launch nothing at all

As mentioned above, there is always something that could delay the launch of a new feature, but when that happens, just let the feature be delayed. Do not rush the feature launch. It’s bad to delay a feature, but it’s much worse to launch an unready feature. Once it is launched, it will start to have customer impact, and the worst thing is to delivery a feature with bugs and got reported by a customer. Do not skip unit tests, integration tests, end-to-end tests to rush a launch. Do not try hacks to accelerate the development process. A “perfect” feature does not mean that the feature is absolutely flawless and meets all customers’ needs. It means that the feature is well-designed to meet a big chunk of customers’ requirements, well-tested throughout all stages and follows the standard development and deployment best practice. If the above could not be met, do not launch it, delay it, it’s worth the delay. Thus, launch a “perfect” feature, or launch nothing at all.

Standard Feature Development Procedure

Features development usually follows this timeline:

1. Identify the problem that this feature aim to solve.
2. Identify the scope of the project.
3. Obtain agreements to start this project.
4. Estimate time needed for this project and set a launch date.
5. Design the feature.
6. Get the design reviewed. Gather comments for the design doc and modify it according to the comments.
7. Start the implementation.
8. Get reviews for the implementation.
9. Deploy to all regions and test it in every stage.
10. Bake.
11. Release.

Every team has its own tenet, and the best practice for feature development. The above is only a general guideline and reference for feature development procedure.

Feature Launch

This blog is based my experience after we launched “Displaying sensitive data location in Amazon Macie findings” feature. Try it out, it’s really handy!

Written on October 13th, 2020 by Ted Wang