Project Kickoff Chaos? No Thanks.
The New Project
Congratulations! You’ve been assigned a new project - to design and develop a green-field, custom enterprise software application. It’s going to be a significant undertaking. The team is expected to have several developers on it, and you have assumed (willingly or otherwise!) the role of Technical Lead.
You may be thinking that you are in an ideal situation - this is the inception of the project, unlike your last engagement where you were thrown into the mix somewhere around sprint 11. So now, you’ll get a proper introduction to the problem domain or whatever it is you’ve been tasked to achieve, and can offer your input and guidance from the start. And in terms of technology, you’ll have a blank canvas, brush, and palette in hand, to apply your expertise with various technologies, coding patterns, conventions and general best practices.
The reality is that this is a rather precarious situation, and it becomes apparent soon after the project kickoff. Your calendar looks like a Google I/O conference schedule, filled with meetings ranging in agenda from user role definitions to entity model designs to what the Accounting department dashboard should include.
When will you have the time to lay down all that core application architecture that’s floating around in your mind, that’s spread across the last three code bases to which you contributed, and in the tech site articles you read last month? You could do it after the kids are in bed. Maybe shoot the dev team a quick email and let them run with it. You don’t really know the 6-month contractors that were brought on board for this project, but it will work out, right? Perhaps your schedule will improve in the coming weeks and the developers are willing to remain idle until you’ve had enough time to vet all your great ideas.
These are terrible options. They all result in kickoff chaos. Resources will be sub-optimally utilized or team velocity will be compromised. You will incur technical debt that will loom until addressed later in the project. And then there’s the stress - either from the extra hours it took to get things going or from knowing that things weren’t laid out as you had hoped. This is not the way you envisioned the project inception. How could this be avoided?
A Solution (Template)
Custom enterprise software solutions typically have a lot in common with one another. The data-driven business applications that I have helped develop seemed to all have a need for well thought out code organization, a data access strategy, a persistence layer, an API, security features, a domain model, logging and exception management capabilities, a way to test that things are working, etc. What if you created and maintained a working application template, a codebase that exemplifies the implementation of the commonalities you frequently encounter - with the technologies, coding patterns, conventions and best practices that you find yourself using out in the wild?
Keeping such a reference template at the ready will alleviate a significant portion of the project’s initial technical demands, allowing you and the rest of the dev team to focus on the problem domain. Using a data-driven business application with a Microsoft technology stack as an example, take a look at Figure 1. There are eleven projects already, each containing vetted working code that can be introduced into your new project’s code base as necessary.
Require a database versioning and publishing strategy? Your Sql Server Data Tools Database project will guide you through that, complete with table seeding scripts. Need to set up your data access layer with an Entity Framework database context, EF’s Fluent API type configurations and dynamically add them to your model builder? You have that all worked out in the DataAccess project. What do your business services look like? How do they make use of data repositories? How will you handle data shaping, paging, and sorting? What’s the plan to map data models to business models? No worries, you’ve thought through all of that and have it implemented in your Service project. Security - that’s a fun one. The IdentityServer implementation of OAuth and OpenID Connect is popular. You’ve done that and can now reference it in your IdentityServer project and how it is applied to your REST API. Ah, the API - what do your controllers look like? How are you handling versioning? How about paging metadata - is it in the response body or returned in a header? It’s up to you. Just make sure that what you want is in your RestApi project for when you need to refer to it. Dependency injection? Web request and exception logging? Want that spun up as Http configuration filters in your OWIN middleware startup? Yeah, you’ve got that. Are you unit testing your API controllers? How about your services? Yes. And Yes. You have established those patterns in your RestApi.Test and Service.Test projects.
This example solution template happened to include a REST API. Taking things one step further, it might be helpful to have the use of that API documented somewhere. Using your preferred REST client, put together a suite of operations for interacting with your sample controllers. If applicable, don’t forget requests for your authentication and authorization services.
So that’s it. The idea is to get your heavy lifting (heavy thinking?) done before you actually need the result. Make sure you keep things fresh. Code begins wandering towards obsolescence as soon as it is written so take advantage of the downtime to make updates and introduce new concepts. Of course, your template solution won’t exemplify everything you’ll be doing on your next project, but it should help get you and your team on its way towards success.
To access source code, visit https://github.com/thirsh/SolutionTemplate