Automated development & deployment tools? Everyone loves them - right? Certainly seasoned developers and infrastructure engineers love to use time-saving tools that help them develop or deploy software faster and more reliably in a consistent manner – as long as those tools promote a proven or best practice or some recommended guidelines that the engineers subscribe to in their solution.
But even in today’s SW industry, there does not seem to be much of an expectation from SW professionals that we should have the ‘capability/tools to build our own tools’ that do much of the project work for us. I am not talking about the simple automation, things like rename/refactor or autocorrect, or intellisense and all that, I am talking about the kind of automation and tooling that writes or deploys software for us and saves hours, days and weeks of our time from handcrafting software solutions from scratch again. Custom tooling that is precisely tailored by us, for us to produce or deploy software exactly the way we want it on every project. Not necessarily all the software, but certainly the parts that we have pre-determined could be repeated the way we have done it before.
It is not clear what the appetite for this kind of tooling is today, certainly it makes logical sense to have tooling like this, but there is still a large proportion of engineers (typically the unseasoned) who like doing everything painstaking and expensively manually just so that they can rest assured that they control everything themselves, and putting their personal mark on their work. But judging by the size of the communities who do have the appetite for more automation and reuse, it seems clear that the broader software development/deployment communities are still largely happily-numb about not needing to be able to do automation very often or well in their work.
So what kind of tooling are we talking about here? We are all familiar with most of the basic toolsets that are provided to us by tool vendors along with the latest technologies. For example, you name it, the latest ASP.NET MVC tooling in Visual Studio that came with the release of the ASP.NET MVC 3 framework. Or the PowerShell console/shell for windows that came with the PowerShell engine. You name your favorite framework and toolset. Technology vendors spend heaps of time and money on providing these basic tools to be relevant to the mass audience, so that they can promote the use of their technology most broadly – that’s what brings in the bacon after all. Most IT experts (lets just call them experts for brevity here) who develop and deliver solutions built on these general technologies with these general tools get to know these tools back to front, and learn how to use them for their limited designed purpose somewhere in the building of real world solutions. Funnily enough, some experts are not even aware of a distinction between the technology and the tools that aid in programming it (e.g the .NET Framework versus Visual Studio, or PowerShell script from the shell). But in most software organizations those experts often come to a point in the mastery of those tools and technologies where they have created similar enough solutions for so long now, that they see overarching patterns emerge from their solutions, common themes, common strategies, common practices. And now they now desire to apply what they have learned previously to next projects using automation to get more consistent and supportable results – that ultimately save time and money in implementation and maintenance. And what tools do they have at their disposal that let them create this kind of automation to share with others? If you ask a developer to quickly create some automation, they will probably write a dedicated desktop/console application, or create a macro in their favorite IDE, or at best create a rudimentary plug-in. An infrastructure architect will almost certainly always create a *.ps script.
Inevitably, engineers start with what they know, and invariably go off in a dark corner and start cobbling together their automation with various bespoke automation frameworks, tools and technologies they are already familiar with – its creative. Its also super hard to do. They build tools that they think others would tolerate using, and could possibly use (with some degree of understanding) to apply what the expert has learned to be proven from their experiences on real projects. Tools that will often be parameterized to deal with variance in requirements of the solution. And these tools are accompanied by detailed documents explaining how to use them, and what they do. These kinds of tools we can generally refer to as ‘Domain Specific Tooling’ (DST). They are specific to only solving problems in a particular solution domain, for a specific audience, promoting/enforcing/implementing specific practices/principles/patterns/implementations given a specific set of requirements and technology assumptions, environments and constraints etc. The kind of tooling an expert takes on the next project to repeat what they learned on the last project, to save them doing it all from scratch again – reliably.
But in practice, these DST tools are often cobbled together across a jumble of platforms with technologies that don’t/won’t integrate well together. “no worries! , just follow the steps in the documentation!” brilliant! Usability is an afterthought, because the expert building the automation is often too consumed with the details and complexities of getting the automation to just work for them. To make up for that deficiency, the resultant tooling is often delivered with detailed step-by-step manuals to teach how to install and use them properly (without which, only the expert can use these tools). Those manuals typically aren’t very scalable across unskilled or uninitiated audiences, (and that’s even if you can find them – they are usually stored in a different location than the tool).
And what if you want to adapt the tool for the next project that has slightly different requirements? Often, these kinds of tools are so hard to learn, parameterize or adapt that they are simply discarded, and their value and expertise is lost entirely. Not really the intent of the expert who invests in creating them.
In larger, better funded organizations, these kinds of DST tools may ultimately result from policy pushed down to engineers for implementing on their projects to gain some semblance of consistency for supportability across the organization where support and maintenance has been recognized as a cost burden. This is usually the case when the folks in the ivory tower (who were perhaps once proficient in the field) get an opportunity to be creative and demonstrate how much they should know (or once knew), and what they know or think everyone needs to use now. They get license to create and manage long running programs that eventually deliver out of date tools and badly integrated automation that govern or enforce uncompromising guidelines that must be followed on all projects – no exceptions! But sadly, with this kind of governance, these kinds of ‘tools’ and guidelines are either designed to be too general to realize any productivity benefit, or too specialized or rigid to realize any value for the specific needs of the current project underway. They are designed by the people most furthest away from the customers problems, and built by people far away from the continually evolving solutions. They are often paid lip-service and simply ignored, or unjustified, moved out of scope, or worked around.
In practice, just due to just how difficult it is to build: good, relevant, up to date, usable, customizable DST tooling, and who should be doing it, the kinds of automation and tools which are being worked on become very unsupportable all too quick, and their value is lost to future generations of projects. Mission failed.
There are some very specific and critical requirements that have been missed in many of these attempts at supporting experts in building custom guidance and automation tools and frameworks in the past. Mainly due to the fact that those building the tools consider themselves the target users of their own tools, and as such they assume that if they find them easy to understand and use, so will all other users. Nothing could be farther from the truth of course. There are some key success criteria that are missing in almost all of these approaches, some poor assumptions, and some very specialized tooling missing that is needed to help dramatically increase the success of building maintainable and evolving DST’s. Let’s look at some of them here:
We recognize that the primary activities of the ‘expert’ when building a DST *should* be limited to:
Note, ideally, none of these kinds of activities should require any training in actual tool building or automation. But, in practice, beyond simple kinds of automation (i.e. generating of files and folders from templates, managing solution structure, executing scripts and that kind of thing) the expert may need to learn details of the automation framework to a level of detail that provides them the degree of automation and integration they may desire. But that level of understanding should not be necessitated by the experience of performing all other activities. It should be staged.
The primary requirements of any automation platform that yields, and executes DST’s, which would take the inputs from the above activities, would include:
These generated toolkits will need to support a core set of basic and standardized user interface and lifecycle features, so that the experts building them can focus on the solution domain, rather than how the automation is presented and managed, such as:
In this way, this class of DST toolkits can be easily generated from simplified descriptions, rule sets and assets provided by the experts, because the management, lifecycle, operation and integration of the toolkits has been standardized for consistency and usability. And so, because the experts can focus intensely on their solution domains and harvesting their assets; rich, highly-usable and relevant tooling can be generated (and updated) far more economically and reliably than using existing bespoke automation technologies.
By making the building and customization of DST tool building so economic, and giving the experts on the front line the capability to create and manage them themselves, the DST tooling that results is always open, always relevant, always up to date, and highly applicable for each project they work on. In this way, more experts start to trust and adopt the tooling provided by other experts, since they can provide their own input to it and continue optimizing it, slowly standardizing on agreed proven practices. As the tooling is so easy to customize and extend, it continues to evolve as the technology and practices do, freeing up the experts to focus on other areas of the solution development/deployment for automation. As a result consistency, quality, maintainability and supportability all increase dramatically. If organizations want to prescribe policies of solution development/deployment, they can invest in that also by building their DST tooling, and then the experts on the front line can take that tooling and specialize/generalize it just as easily for their projects, feedback their expertise in the tools themselves, realizing the combined value of the organization and individuals in their marketplace.
This was precisely the realization of the VSPAT toolset from when it was incepted back in late 2009. It was recognized then that just providing a powerful and flexible tooling framework was not enough to address the problem that software professionals faced with bespoke automation. Which was the incumbent thinking inside the Visual Studio team at the time. “Just give them powerful frameworks and they can use them!” was a position of grand arrogance, and presumed that every software professional (development or deployment) was an automation and tooling expert [in Visual Studio automation]. When the keys were in fact in bringing the automation experience to well within the grasp of all software professionals (both development and deployment). So that any tooling produced was so easy and economical to produce (and to customize or extend) that the initial (and ongoing) investments required to create and maintain great tooling were not prohibitively high, and very quickly achievable.
As well as that, making the toolkits themselves an open and extensible system, opened up possibilities for customization and tailoring previously not tackled in past generations of automation frameworks. If you didn’t like the toolkit, then change it yourself – no source required. A toolkit could just as easy be created from scratch, as modified and customized or extended. If you found a toolkit that was 80% of what you needed, you could open in the designer and customize the 20% to suit your needs just as quick. If you didn’t like the code that was generated by a toolkit, you could open it the designer and modify the code template to suit your needs. No longer did you need to invest in esoteric file formats or tinkering with aging automation frameworks, everything was graphically designed, related together in a simple view of your domain, and all programming extensibility points typed to your domain. You could even build toolkits iteratively and incrementally, and present them to users to try out every cycle without having to commit to all the automation, so that you could explore and experiment in their look and feel and function first.
If you wanted to build a toolkit, and have others implement some aspect of it, or perhaps enable someone to plug something into it (i.e. a technology variant, or architectural extension), then you shipped the base toolkit with a defined ‘extension point’ in it, and others in the organization/community shipped extension toolkits that plug into the extension point to allow the two toolkits to interact and collaborate. With this kind of customizability and extensibility, using the same experience as creating new toolkits, the traditional economic barriers to creating and maintaining such automation started toppling.
With the advances made in the VSPAT technology and the proven approach it has demonstrated over again, it now makes sense for all software organizations to make small investments in tooling as the software project progresses, as a parallel activity. This works especially well in agile projects, where the tooling and the automated software are changing rapidly together.
As an open source project, the VSPAT project is not finished by any means, there is more to learn and improve in the real world customization and versioning scenarios that communities may need. Now that this project is free of its corporate bonds, its can flourish in the wider development community, we are looking forward to many organizations realizing the potential of this technology and the project moving forward.
Please check out the VSPAT project site, and lets get the automation discussion and communities going strong again, and realize higher levels of consistency, predictability and supportability in bespoke software solutions.