Often times knowing where or how to start is the hardest part of any task. Whether it's learning a new technology, starting a new project, or sitting down to write a blog post, the beginning always seems to consume the most time. When it comes to writing, the best advice I ever received was to just start writing. Even if it doesn't make sense yet, put the pen to the paper and start the flow. The same can be said for Test-Driven Development; just start writing code, test that code, then refactor it. Even if your first test is validating instantiation of an object, or the existence of a reference, start moving the cursor away from Line 1.

Taking this principle into dev project work, we all yearn for greenfield development, but I'm sure a majority of us can easily name one or two projects that suffered from analysis paralysis. This is why agile software development focuses so heavily on the concept of a Minimum Viable Product; get the code out and into the hands of stakeholders to start iterating.

minimal-viable-product-henrik-kniberg

Several years ago, I saw Cory House speak at a local conference on writing clean code. It was such an engaging talk, and it was my first exposure to seeing Cory speak. A couple years later I was at another conference, and I saw that Cory had a session. I wasn't 100% sold on the topic, but I was intrigued; and knowing what I knew about Cory, I figured it would be an entertaining session.

Cory spoke about The JavaScript Checklist Manifesto.

It was a great session, but being a C# developer, it was difficult for me to parallelize the points he was making. In .NET, a lot of our decisions are made for us. We know what our IDE is, we know what our package manager is, and a test framework is packaged with our project when it's created. Now, when you consider the evolving ecosystem of .NET and .NET Core, Microsoft is empowering developers to make these decisions; which makes this even more important. Regardless, throwing all of that aside, the concept of a Starter Kit or a Checklist can have a profound impact on a codebase, no matter if it's JavaScript or C#. This took awhile to fully sink in for me, but once it did, the light bulb went off brighter than it ever had.

When ASP.NET Core was still in it's infancy, Microsoft was leaning heavily on existing tooling to support the new platform. Creating a new project required installation of an npm package called yeoman. Yeoman is an open-source scaffolding tool that will spin up a workspace for you. It is driven by "generators" and there are a variety of them available. For awhile, a generator for ASP.NET was published, though it has seemingly since been deprecated based on the adoption of the .NET CLI. Though as you can see, it's fairly straightforward and has support for various project types.

Screen-Shot-2018-12-21-at-9.08.24-PM

The flexibility of yeoman allows you to have full control over not only your templating, but your tooling. Choosing yeoman over creating a custom Visual Studio project keeps overhead low (i.e. not waiting for VS to startup) and allows developers to use the tooling of their choice (Visual Studio, Visual Studio for Mac, VS Code, Atom, etc). Development teams are frequently in the CLI already using Git & NPM. Creating a custom generator allows you to establish project types and hit the ground running without much manual intervention. For example, a microservice project template can create all the base folders and files necessary based on internal convention, kick off dependency manager installs, run the project, and navigate to a page containing links for documentation on assets for the project ecosystem.

There are various other principles adopted as part of a starter kit that can give a more measurable impact, though the starter kit is the glue that holds it all together. Utilizing an internal package respository for custom NuGet & NPM packages (which are auto-installed via the generator depending on the template you select), or crafting various abstractions on tools such as gulp, can drastically improve the amount of time between project conception to the first deliverable.

I won't go into detail on how to create a yeoman generator, as the yeoman documentation does an exceptional job of walking through it. Rather, I believe the focus on this concept is more important. Take a step back from your daily development and try to identify areas of re-use. Abstract that into a library. Then work with your team to define the criteria that makes you successful. By removing the barriers to start a new project, it affords more time to automate other parts of the development pipeline and to research emerging technology. You can ultimately eliminate the need for Sprint Zero.

These principles can be applied to any language, any technology stack. Cory's tech stack just so happened to be JavaScript, which is a loosely typed buffet of decisions to be made. The starter kit is only one component of the checklist manifesto, but it is the most crucial. It will start the project out successfully, setting the precedent for all upcoming milestones and successes.

For more information on creating your own generator for Yeoman, please refer to: https://yeoman.io/authoring/

If you have questions on how to implement a starter kit, I would be glad to share more of my experience. Drop a comment below and let's start a conversation!

This post is part of the C# Advent Series. For more articles on C# and software development, please see https://crosscuttingconcerns.com/The-Second-Annual-C-Advent