The road to one point zero

Tristan Morgan
May 20, 2019

Screen Shot 2019-05-20 at 10.07.13 am

To commemorate the release of awskeyring 1.0, this post is about the path taken to get there and the learnings along the way. 

I stared building out awskeyring to help solve the problem of storing credentials for multiple AWS accounts in a safe way. Being a consultant having to go between multiple client sites, I had to manage credentials for multiple client environments. The default AWS way of storing it in a text file on the file system leaves a lot to be desired. Being a macOS user, it made a lot of sense to use the builtin keychain to manage these credentials, and after not being able to find a tool that met my use case, I decided to build my own, the blog covering that can be found here.

Some projects slap a 1.0 on their first mostly working release, others take a significant amount of time to let things settle in before calling it 1.0 and live in the 0.XX.XX versions for years.

I have started with a pretty clear goal of what this project wanted to achieve and after 7000 plus downloads I am ready to call it 1.0 feature complete. Not saying that bugs won't be found and features may be added but I have completed what I set out to do and with feedback from others it does what its supposed to do.

Speaking of others, they are very important. Without others using your software you will never find those edge cases and other uses that you the developer would ever think of. "If you build something idiot proof they will just build a better idiot". I'm not calling the users of the project idiots, far from it, but there are just different ways people use things. You really need to release it and get feedback to really make something handle those edge cases.

I built this project to satisfy my own need but even then over the year or so of using Awskeyring, I found more use cases I didn't think of at the start. I found and fixed a couple of bugs that only came up when I had to use it from behind a proxy that I could have sworn it worked before. Having a clear set of goals also meant I could limit scope creep and say to some requests that it is not the aim of this project and if they'd like to start another project I'd be willing to help, but its not for this one.

Being a tool that I still use it also means I have a vested interest in keeping it running. Each time I updated my software or a dependancy is updated I will ensure it keeps working and even make small improvements that I learn on the way. Good testing also helps let me know when I might inadvertently break something so help prevent bugs getting in the hands of my users.

The lessons learned from all of this is a clear goal gives you direction that you can target specific functions. Your users will help you shape those goals. Add testing to ensure those goals are never broken and the tests will allow you to tackle each component in an iterative process, never loosing sight of the big picture. Finally, don't store sensitive keys in plain text on your computer! (people never learn)