Burn-Down Charts: The Silent Value Killer

Spend any time with Agile development and you’ll come across the burn down chart. The premise is simple – if a team committed to delivering 15 planned innovations (features, user stories, or whatever you want to call them), a little gets done over time so the remaining work should “burn down” to zero at the end of the sprint.

While burn down charts are effective tools for tracking how a team is progressing towards finishing planned work, there is a sinister effect that happens in many organizations that learn to use them. Managers begin to primarily focus on the number of innovations delivered per sprint. Though they may be tracking other metrics, it draws their attention because it is simple to understand, and easy to communicate. It also feels like producing as many innovations as possible is getting the most value out of a team – common sense right?

Unfortunately, the goal of a business is not to do work. The goal is to grow and create economic value. As anyone who’s read Continuous Delivery or The Lean Startup knows, most of the innovations you plan and deliver do not produce value as expected. Though market and customer research, usability testing, and strategic planning are all useful tools; the only proof of value is whether customers actually use your innovations.

To find out which ideas are good, you’ve got to release them and be prepared to throw away the innovations you had that didn’t meet their needs. If you’ve invested in releasing in small batches and using a deployment pipeline, the delivery process is optimized for getting feedback. If you stop there however, you’ve fallen victim to process ceremony.

Once you start releasing more often, you also need to optimize for changing course based on what you learn from the increased feedback. The bad news is it doesn’t look as good on a chart.


The chart above depicts some of the effects on value for a team focused on innovation throughput as a primary goal. As each sprint progresses, the percentage of value is about the same. The industry standard being less than 1/3rd of the ideas you release will provide useful value to customers in established markets, much less in new products. If the theories businesses have about what their customers want before they deliver them were usually true, we’d see more successful startups.

Since what was planned at the beginning of the project above doesn’t change from one sprint to the next, there are no opportunities to course correct until the end. And each new feature that is released increases the maintenance cost since complexity goes up along with feature count.

In this sad state of affairs, the trends should be obvious: an appalling rate of value, decreasing innovation throughput, and increasing maintenance costs. In situations like this, it is alarming to experience how teams will subconsciously game the numbers so the number of story points (effort towards features) looks like it is going up. This is an unfortunate behavior that is unlikely to change with the motivation for measuring performance focused on innovation throughput.


The chart above depicts a more typical set of activities for a team focused on value instead of rate of innovation. The highest throughput of new features occurs at the beginning, when you don’t know how your customer will receive the minimum viable product. The team can focus mostly on delivering the first few new features.

During the second sprint, the first release is available to customers and they are providing feedback. To prepare for the change in direction that is inevitable with listening to this feedback, it is more important at this point that the features that were already delivered are of high quality. If any corners were cut, now is a great time to remedy that.  The team might do some refactoring, and plans for what features they deliver next will need to change to accommodate the feedback that was gathered.

When the third sprint rolls around, the team got rid of some ideas we delivered that weren’t right based on what we learned, made sure that what was in the prior sprint was stable, and are now working to deliver features that are closer to what the customer said they wanted. If the feedback we got was reliable (customers ask for things they don’t really want all of the time!) the value produced during this next sprint will potentially be higher.

At the fourth sprint, the team has a steady stream of feedback, and is working on a combination of new ideas and enhancements to adapt what was released to the customer’s desires. The number of features delivered is still lower than when the project started though because some refactoring may need to be done to keep the quality of features high since potentially dramatic changes to the design may have been made to release the most valuable ones. From here on out is a see-saw of increased value from releases, and intermediary releases where the team vigorously realigns the priority and structure of work to accommodate what they are learning. That’s right folks – finding market fit is messy. But this is what needs to be done to make real money in the industry.

Now some of you might be thinking “Can’t I just measure the time spent refactoring and maintaining so we can combine these together and have a clean burn-down chart? I need to show that our resources are fully utilized!”. And yes, you could do this, but why would you want to? I will tell you why – a lack of trust. When management overseeing a new product or initiative wants to micro-measure all aspects of the delivery process to ensure they are getting the most throughput there is an assumption that someone is not working as hard as they could be, and that this can be identified on a chart to “save money”.

The problem is that any process measurement system can be gamed. The only true measurement of progress in a business is profit, and the way to arrive at these moments of high growth is through the adaptive, difficult-to-quantify, collaborative approach in the second chart. Having a team able to work towards value in this way requires brutal honesty about what didn’t work, variation from one sprint to the next, and above all – trust.

So go ahead and estimate features you will deliver each sprint, and use the burn-down chart to see how the team is performing so they can do better at estimating. But stop penalizing teams for delivering a different number of features (or user stories) each sprint. You just might figure out the ideal features for your customers – and keep your staff around for the long haul ahead.

IT deployment standards: why now?

Much like what is happening in the “big data” space, challenges with interoperability in the IT deployment tool market are converging to create an opportunity for standardization. Before I go any further, let me introduce two terms that have no official meaning in the industry but will make this article easier for you to read:

Deployment Providers – These are command-line utilities, scripts, or other self-contained processes that can be “kicked off” to deploy some single aspect of an overall solution. An example might be a code compiler, a command-line utility that executes database scripts, or a script that provisions a new node in VMWare or up on Amazon Web Services.

Deployment Orchestrators – These are higher level tools that oversee the coordinated execution of the providers. They often include the ability to add custom logic to the overall flow of a deployment and combine multiple providers’ activities together to provide an aggregate view of the state of a complex solution’s deployment. Some open source examples of these are Puppet, Chef and Powerdelivery; and there are many commercial solutions as well.

With those two definitions out of the way, let me begin by describing the problem.

Do we really need deployment standards?

First, as more companies are finding that they are unable to retain market leadership without increasing release frequency and stability, having deployment technologies that differ wildly in operation as personnel move between teams (or jobs) creates a significant loss in productivity. Much like ruby on rails disrupted the web application development market by demonstrating that providing a consistent directory structure and set of naming conventions leads to less variability in software architecture and reduced staff on-boarding costs, so too is the IT deployment space in need of solutions for reducing complexity in the face of economic pressure. As developers and operations personnel collaborate to better deliver value to their customers, having a consistent minimum level of functionality necessary for Deployment Orchestrators to deliver the technology stack they’ve chosen provides the opportunity to reduce IT delivery costs that impact both of these job roles.

Secondly, as the number of technologies that need to be deployed increase exponentially, more organizations are struggling with having a means to get the same quality of deployment capabilities from each of them. While Deployment Orchestrators often include off-the-shelf modules or plugins for deploying various assets, the external teams (often open source contributors or commercial vendors) that create the Deployment Providers rarely have the financial incentive to ensure their continued compatibility with them as they change. This places the burden of compatibility on the Deployment Orchestrator vendor. These vendors must then constantly revise their modules or plugins to support changes originating from the downstream teams that deliver the Deployment Providers, and this coordination will grow increasingly difficult as the technologies that they deploy are also released more frequently through industry adoption of Continuous Delivery.

Standards create their own problems

Whenever one speaks of standardization, there are a number of legitimate concerns. If history repeats itself (and it often does), the leading Deployment Orchestration vendors will lobby hard to have any emerging standards align best with their product’s capabilities – and not necessarily with what is right for the industry. Additionally, as standards are adopted, they must often be broken for innovation to occur. Lastly a committed team of individuals with neutral loyalties to any vendor and a similar financial incentive must be in place to ensure the standard is revised quickly enough to keep pace with the changes needed by the industry.

Scope of beneficial IT deployment standardization

What aspects of IT deployment might benefit from a standard? Below is a list of some that I already see an urgent need for in many client deployments.

Standard format for summary-level status and diagnostics reporting

When deployment occurs, some Deployment Providers have better output than others, and having a standard format in which these tools can emit at least summary-level status or diagnostics that can be picked up by Deployment Orchestrators would be advantageous. Today most Deployment Providers’ deployment activities involve scripting and executing command-line utilities that perform the deployment. These utilities often generate log files, but Deployment Orchestrators must understand the unique format of the log file for every Deployment Provider that was executed to provide an aggregate view of the deployment.

If Deployment Providers could generate standard status files (in addition to their own custom detailed logging elsewhere) that contain at least the computing nodes upon which they took action, a summary of the activities that occurred there, and links to more detailed logs this would enable Deployment Orchestrators to render the files in the format of their choice and enable deep linking between summary level and detailed diagnostics across Deployment Providers.

More Deployment Orchestrators are beginning to provide this capability, but they must invest significantly to adapt the many varying formats of logs into something readable where insight can occur without having to see every detail. A standard with low friction required to adhere would encourage emerging technologies to support this as they first arrive in the market, lowering the burden of surfacing information on Deployment Orchestration vendors so they can invest in delivering features more innovative than simply integration.

Standard API for deployment activity status

When Deployment Providers are invoked to do their work, they often return status codes that indicate to the Deployment Orchestrator whether the operation was successful. Deployment Providers don’t always use the same codes to mean the same thing, and some will return a code known to indicate success but the only way that a problem is determined is by parsing a log file. Having a consistent set of status codes and being able to certify a Deployment Provider’s compatibility would improve the experience for operations personnel and reduce the complexity of troubleshooting failures.

Standard API for rolling back a deployment

Deployment in an enterprise or large cloud-hosted product often involves repeating activities across many computing nodes (physical or virtual). If a failure occurs on one node, in some situations it may be fine to simply indicate that this node should be marked inactive until the problem is resolved, while in other situations the deployment activities already performed on prior nodes should be rolled back.

Since rollbacks of deployments are typically executed in reverse-order and need to provide each Deployment Provider with state information needed to know what is being rolled back, today’s Deployment Orchestration vendors don’t make it easy to do this and significant investment in scripting is necessary to make it happen. A standard API that Deployment Providers could support to allow them to receive notification and state when a rollback has occurred, and then take the appropriate action would allow for a consistent behavior across more industry solutions and teams.

Standard API for cataloging, storing, and retrieving assets

When a failed rollback occurs, Deployment Orchestrators must have access to assets like compiled libraries, deployment packages, and scripts that were generated during a prior deployment to properly revert a node to its previous state. Additionally, it is often desirable to scale out an existing deployment onto additional nodes after the initial deployment already completed to meet additional capacity demands.

Depending on the number and size of the assets to store, number of revisions to retain, and the performance needs of the solution; anything from a simple network share to dedicated cloud storage might fit the bill. A standard API abstracting the underlying storage that Deployment Providers can use to store their assets and Deployment Orchestrators can use to retrieve the correct versions would enable organizations to select storage that meets their operational and financial constraints without being locked in to a single vendor’s solution.

Standard API for accessing a credential repository

In addition to Deployment Providers needing to publish assets as a result of deployment activities, they also often need to access security credentials that have been given permission to modify the infrastructure and components that are configured and deployed to when they execute. On Linux and OSX this is often provided by SSH keys, while on Windows a combination of Kerberos and (in double-hop scenarios through Windows PowerShell) CredSSP. Rather than each deployment needing to implement a custom method for locating keys on the correct servers, a credential repository where these keys can be stored and then securely accessed by trusted nodes would simplify the management of security configuration needed for Deployment Providers to do their work with the right auditability.


With these standards in place, Deployment Orchestration vendors still have plenty of room to innovate in their visualization of the state of nodes in a delivery pipeline, rendering of status in their own style and format for the devices they wish their users to support, and the coordination of these APIs to provide performant solutions across the Deployment Providers that would adopt such a standard. As a team bringing a new Deployment Provider to market, it would improve the adoption of the technology by having the option of adhering to a standard that would ensure it can be orchestrated consistently with the rest of the solution for which their technology is but one part. When standard APIs such as these are made available by a single Deployment Orchestration vendor without first having been established as at least a proposed standard, it is very difficult to motivate the broader community that creates Deployment Providers to do any work to support proprietary APIs themselves.

What do you think? Has the industry tried various aspects of this before outside of a single vendor? Has the market matured since then where the general audience might now see the value in this capability? Would it be too difficult to provide an API in enough languages and formats that orchestration could occur regardless of the platform? Let me know your comments below!

Photo: “lost legos 1/3” © sharyn morrow creative commons 2.0

Selecting a Deployment Pipeline: 10 Considerations

While a team must adopt a customer-guided, acceptance criteria-driven culture to begin releasing IT assets frequently and with high quality, eventually an investment needs to be made to create a Deployment Pipeline. Put simply, this is a technology that enables an organization to use automation to eliminate manual processes necessary in the release of their IT assets. The industry is full of automation tools and many organizations will need to use a combination of several to achieve one-click release of assets into an environment, enabling Continuous Delivery.

In no particular order follows a list of considerations I encourage you to take into account when selecting technologies for building your pipeline. These considerations are rooted in guidance outlined in the Continuous Delivery book.

#1 – Does it work with your source control systems?

When engineers check-in IT assets to a source control system or some other asset repository, the delivery pipeline should automatically trigger some actions. These actions might be things like compiling code, running unit tests, configuring servers and deploying assets. If you have one team that uses Github and another that uses Team Foundation Server and both teams’ deliverables are combined to produce the final product – you don’t want to get into a situation where someone needs to manually push and pull code between the two repositories.

If one deliverable is a dependency of the other, create a pipeline where the production environment of the first team’s deliverable is a located someplace where the dependent team can consume it. This might be a UNC drive, rubygems, NuGet, or Chocolatey repository (public or private), or a host of other options. This allows the first team to make changes in their own development environment, do their own acceptance testing, and then choose when they feel they have a build solid enough to push to the other team. The dependent team can then move their own assets and the associated dependent team’s assets through their own pipeline and eventually into the production environment where users will consume it. This technique is sometimes known as a cascading deployment pipeline.

#2 – Does it move assets between environments without recompilation?

One important principle of Continuous Delivery is to never deploy different binaries to different environments. If you compile or generate assets that are deployed to production differently than the copy in the UAT environment, you open your team up to an unnecessary risk of defects. Your deployment pipeline should be able to deploy the same assets to multiple environments with the only difference being their configuration.

#3 – Is it approachable by operations personnel?

To achieve the organizational alignment of bringing development and operations personnel together through DevOps, operations personnel will assist in the creation of and ongoing change to the delivery pipeline to support the value needed by the IT offering. If your operations personnel are not object orientated programmers well versed in polymorphism, domain-driven design, functional programming and other product development skills; you will have a challenging time getting them to adopt and contribute to the pipeline if those are the skills needed to work with it.

I recommend considering the selection of automation technologies that use scripting languages such as Windows PowerShell, bash, or ruby to automate. These languages have a lower barrier to entry, can execute without needing to be compiled first, and don’t require purchase of an expensive Integrated Development Environment (IDE) to modify. A good list of powerful tools that are built on these languages to start investigating might be Puppet, Chef, Capistrano, Rake, Powerdelivery, and PSake. I can’t honestly recommend MSBuild, Maven, or Ant for the pipeline (though they are fine for compiling things) because XML tends to be too fragile and difficult to comprehend for building even the simplest of conditional logic.

#4 – Are deployment assets versioned along with deliverables?

Because the deployment pipeline will be undergoing change, it will contain configuration and logic meant to deploy the assets of a release at a given moment in time. To enable rollback (I’ll talk more about this later) and reduce surprises, it is preferable to find a way to version the pipeline’s actions along with your deliverables. This is fairly easy to do with most of the technologies I cited above, but there are some other tools on the market that don’t lend themselves well to this important tenet.

#5 – Is it possible to write rollback procedures should aspects of the deployment fail?

Automating the “backing out” of changes made during a deployment, also known as a rollback, is an important step in gaining the confidence necessary to release to customers more frequently. This is the process of returning a deployment to its prior state if a failure somewhere along the way occurs. If your rollback process is manual, you introduce the chance of errors and troubleshooting an improperly performed rollback while the production system is down can cause immense levels of stress.

Look for technologies that keep track of actions performed and if there is a failure, either have “hooks” to let you write your own rollback logic or perform the rollback actions (in reverse order of when deployed) automatically. There’s a good chance you will need to create some of the rollback functionality yourself.

#6 – Does it prevent skipping of environments when deploying release candidates?

The reason teams create dedicated development, staging (or user acceptance), and production environments is to isolate changes being made from their customers and staff performing acceptance testing. One of the highest costs in deployment that kills a team’s ability to release more frequently is when the configuration and deployment of assets to these environments is manual. This is because it is simply too easy for a person to forget to make a change consistently in all environments.

Look for a technology that keeps track of which releases have been deployed to which environments, and will prevent a build that has not been tested from being pushed into production, for example. This is one of the reasons I created powerdelivery, because there isn’t a tool in the Microsoft ecosystem for putting quality in gates into automated deployments between environments, and the Windows Workflow Foundation technology upon which automated builds in TFS were created is too unwieldy and slow to keep up with the needs of a team that is frequently releasing.

#7 – Is it possible to use security to control who can initiate deployments into each environment?

Most teams put a policy in place that determines who is allowed to deploy releases into each environment. This is still a good practice, and should be agreed upon and communicated when planning to begin continuously delivering any IT offering. To help meet Sarbanes-Oxley (SOX) regulatory compliance and prevent mistakes, it is often not enough. Look for technologies that allow configuration of who can promote a build from development to test (often a QA resource) and from there into production (often an operations resource).

#8 – Does the technology provide access to compilers, deployers, and test frameworks you use?

You may have read some great story about how a darling start-up in silicon valley implemented Continuous Delivery using javascript, but if you can’t use it to compile, deploy, and test YOUR code you will end up fighting it. Look for technologies that include support out of the box for the tools and frameworks you use, or have a low barrier of entry to integrating them in.

#9 – Does the technology provide access to infrastructure automation for the on premise or cloud platforms you use?

Continuous Delivery is more than automated deployment – you also need to be able to spin up servers or virtual machines on premise and in the cloud depending on your requirements. If you are using Amazon Web Services, Windows Azure, Heroku, or any of the other popular hosting platforms; make sure your pipeline technology can utilize the best APIs from these vendors. If your technology allows you to deploy a website or mobile application but not harness the rich features of your hosting platform for example, you might be missing out on the ability to automate your entire infrastructure and benefit from things like automatic scaling of your application based on demand.

#10 – Is it possible to replay activities consistently across multiple nodes?

As more IT offerings are able to scale out their processing and storage across multiple physical or virtual computing nodes, deployment technologies that enable Continuous Delivery need to have first class support for parallel activities. If your ASP.NET MVC or Ruby on Rails website will be hosted on a cluster of nodes, look for a technology that can accept the DNS names or I.P. addresses of these nodes and perform deployments seamlessly across them, rolling back the nodes that were deployed to if one fails. If your projects are automatically compiled every time a developer checks in code but the deployment process requires repeating manual steps across multiple nodes – you are in for a long road of troubleshooting configuration mismatches and surely will have a way to go before you can reduce your release cycle time to be more agile in your market.

Hopefully this list of considerations helps your team think objectively about some of the hype out there around deployment pipeline technologies, and you can better take into account some of the additional costs of development and maintenance necessary to get them to work for your particular IT offerings.

Have you read the Continuous Delivery book or are you starting your journey towards reduced cycle times? Let me know some of the struggles and successes you’ve had around deployment pipeline selection and implementation below!

Continuous Delivery is about failing faster

If releasing to customers once a month, once a week, and even several times a day were easy – everyone would be doing it. Getting IT assets that generate revenue released faster is clearly an advantage. However, the biggest return on investment of Continuous Delivery is a little more subtle.

If you build it, they don’t always come

When a business has an idea for an investment in IT, they do market research, calculate costs and return, forecast customer adoption and get stakeholder buy-in – but often wear rose colored glasses without even knowing it. This isn’t any different from a start-up that is pitching its first business plan. Even with conservative estimates, many assumptions are made and there’s really no way to know how the investment is going to pay off until it gets delivered. There are no sure bets in product management.

As a product manager or business owner several of the ideas you have for your customer will turn out to be useless to them.

Over the 19 years that I’ve been working with companies to deliver IT products and services, I’ve never been satisfied with the waste I see in the processes that many organizations use in bringing ideas to their customer. So much time is spent prioritizing, evaluating costs, scheduling, and tweaking the efficiency of resources but a healthy dose of humbleness is often the key ingredient missing from the equation – and the most costly to ignore. When sure bets turn into failures, the cost of the investment and decisions of engineering are often where the finger is initially pointed. The reality is that as a product manager or business owner, several of the best ideas you have worked out with your customer will turn out to be useless to your larger audience. Customers may even tell you it’s the best thing they have ever seen, sign up to be early adopters, and give you positive feedback on what you’re thinking of charging. But by the time you release it to them, you’ve spent heaps of capital and it can cost you your job (or your equity) to find out you were wrong.

Taking risks in the market is necessary for a business to thrive. Innovation in small businesses drive the economy of the world, despite what larger corporations would have you believe. When a tiny idea explodes to have a big impact, we all benefit as new opportunities are created that result in exceptional economic growth. But even large organizations can have innovative, disruptive ideas flourish as pockets of entrepreneurial spirit win internal support to try something new. The barrier that must be overcome is risk aversion. With the biggest opportunities for growth requiring us to take some chances, why would anyone want to go about delivering their IT offerings using a process that penalizes change and the risk of unexpected outcomes?

Stop the bleeding

“Mr Corleone is a man who insists on hearing bad news at once” – The Godfather

The good news is that it doesn’t have to be this way. When a product that requires physical manufacturing is getting ready for market, everything has to be solid in the design and any changes along the way can bankrupt the idea. If a design change is needed in a new mold for carbon fiber parts that costs millions and the first one has been manufactured, the entire cost of the mold is lost. IT assets aren’t at all like this, though companies continue to think in this mindset. The inventory in an IT asset is information, and information is cheap and easy to change.

Despite the low cost of information as inventory, the time invested to create and change that information is still a concern. If an IT asset is delivered to the customer and found to not have market fit, the more that was invested in that idea, the more that is lost. Knowing this, we should seek delivery processes that let us know as soon as possible that what we’re delivering is not on target and enable us to make changes with the lowest possible loss. Many organizations employ usability studies and surveys to give them validation that an idea is viable before delivering it, and this is certainly a great practice. However I’ve seen customers rave about a design on paper, or a prototype – and then hate the product once it was delivered to them. You really need to deliver an actual, working idea to measure adoption in the market and get feedback.

The challenge

To deliver IT assets more frequently requires organizational change, relentless communication, investing in some technology, and the ability to handle the increased volume of customer feedback that comes with doing so. This isn’t something that can be done all at once, and a challenge I deal with when helping clients is to balance keeping momentum going with the changes needed and not being too disruptive to existing business. When I’ve seen teams attempt to do this without outside help, the politics and lack of experience with cross-functional collaboration can doom it to being looked at as just another pet project of an ambitious employee who didn’t understand “our culture”.

So many ways to fail (and be profitable)

When a team uses Continuous Delivery to move towards frequent releases for their customers, they invest in the creation of a deployment pipeline – which is essentially an automated release process. This is more than an automated build, which may compile some code and deploy it somewhere. Does someone ping the web servers every time you do a release, to make sure things are up? Automate it. Does someone change a setting in a configuration file to publish a mobile app to the right store? Automate it. Do a group of three people have to approve a build before it goes into production? Automate moving the build further downstream with their electronic approval.

With the pipeline in place, there are dedicated stages that each build of your IT assets go through prior to being released to customers. Along the way, an increased level of automated scrutiny is placed on it to fail as soon as a problem indicating that this version is not ready for prime time is found. Here are just some of the ways a delivery pipeline can help you be more profitable by causing failures to occur earlier in the release process.

Failure Cost Remedy
Defect found in production Must rollback system to good state, interrupt new work, and repair customer confidence. Automate acceptance tests in deployment pipeline that run in environments prior to production
Flawed design pattern identified All assets that used that pattern must be changed and re-tested. Initially release a small number of assets that use the pattern to customers.
Reduced desire for feature Lost investment in what was built. Invest only in a minimum viable feature before releasing to customers.
Slower output from team than expected Must adjust forecast delivery dates, must improve capability of team. Don’t commit to dates for sprints far in advance, measure team output more frequently, get training or make hires.
Insufficient performance at capacity Must purchase new hardware, optimize IT code or assets. Automate performance acceptance tests in a capacity testing environment.

These are just a few examples of how a delivery pipeline, and a team that has been organized to continuously deliver IT assets while aligned with their customer, can save money by failing faster. You can see here that the cost of finding a defect prior to production is less than if it were. The cost to change a design pattern that has low penetration in the overall architecture is lower than if it were identified after applied broadly. The cost to find or train resources to better support the needs of a team is less than not knowing they need this help and utilizing their low throughput over the lifetime of a product’s development. All of these early identifications of failure lead up to dramatic savings in the overall cost of finding that critical market fit, and working in a sustainable fashion to support the needs of the business.

By reducing the cost of failure, the ability to handle risk goes up and the opportunities for efficiency are numerous. If your organization is not taking steps towards a more fluid release process, it is only a matter of time until your competition’s agility will enable them to blow past any market advantage you currently have.

Tips for Estimating Continuous Delivery

Ahh, estimating. We all hate to do it, but it’s critical when releasing more often. The good news is it’s not nearly as important to get it “just right” for an entire effort, but it is important that the current sprint is estimated well. The following article should help you understand what’s different about estimating a sprint (release) when you use Continuous Delivery as apposed to using a SCRUM/Agile process where the work is done in small iterations but not actually released.

Because delivering IT assets is a highly variable process (if it weren’t every task would take the same time just like creating parts on an assembly line), it is highly likely that one or more estimates will be off by some amount. When your team starts a sprint of work using Continuous Delivery, the goal is to actually release something at the end. Because of this focus, we need a way to accommodate variability.

The problem with “buffers” in tasks

Most folks remedy variability by putting “buffer time” into their estimates to account for unknowns. If you put buffers into tasks, there are two problems that occur. The first is that psychologically, those assigned to the tasks have a misplaced sense of “extra time” left to complete their tasks. You do not want individual tasks to be scheduled to take any longer than what’s expected. If your team doesn’t understand a user story well enough to describe verifiable acceptance criteria to demonstrate it works, don’t put it in the sprint! If you do this, you are making it highly likely that you won’t release at the end.

The second problem with putting buffers into individual tasks is that you have just scheduled all of your tasks to essentially be as costly as they can be. You can’t track to a realistic estimate and are essentially planning on each task taking as long as possible. I can’t stress this enough – don’t use buffers in task estimates for sprints when you want to release the work at the end.

Why high capacity utilization is dangerous

Because the goal of most IT value chains is to deliver value as efficiently as possible, it can be tempting to load resources to high capacity utilization. Because we don’t want buffers in our tasks but the work is highly variable, the proper place to accommodate this is by scheduling resources with excess capacity. By leaving excess capacity, resources that finish tasks early are freed up to help others with theirs and it is more likely that having multiple people working on a problem will still get it finished on time than asking a single, highly utilized resource to “just work faster”. The risk of any one member blocking the entire release by variability encountered in getting their task done goes up exponentially as you pass 70% utilization. If you don’t leave extra capacity for resources, you are all but ensuring that you will not be able to release the work at the end.

Sprint “Zero”

The first sprint of an effort that will employ automated continuous releases is the place to estimate and complete tasks that are hard to do once the entire team has started work. The following is a list of some things to consider scheduling for the first sprint (or several depending on the size of the effort to be worked on) to prepare for the entire team coming on board.

  1. Time to setup infrastructure like servers, security accounts, and opening of ports
  2. Time to setup source control for any change controlled assets
  3. Time to build an initial website, database, business intelligence data mart, mobile application, or whatever you will be delivering that is either empty or has just one page or set of data
  4. Time to create an automated deployment process for deploying changes through your various environments (development, UAT, production etc.)
  5. Time to create a policy for who will approve release candidates to be promoted from one environment to another
  6. Time to populate and prioritize the backlog and do business analysis necessary for agreeing on the acceptance criteria for the first sprint where the team will work on functional deliverables

Functional Sprints

Once the larger effort gets underway and the team is brought in, the list below includes some things you should consider when estimating work that will be released at the end of the sprint. This is by no means a comprehensive list but includes some things you might normally put off until the end of a larger “iterative waterfall” project where the team builds functionality in sprints but doesn’t release it until a stabilization phase at the end.

  1. Time to implement new features or changes
  2. Time to test features or changes
  3. Time to fix any defects found during testing
  4. Time to change anything about the automated deployment or testing process needed to support the features being delivered
  5. Time to update user documentation that describes the new features or changes
  6. Time to hold the sprint review meeting, accommodate feedback, and release to production
  7. Time to hold a sprint retrospective to capture what went well and what actions will be taken to remedy problems found

Hopefully this article helps you to consider some of the changes needed when estimating work to release more frequently. The team will complete less functional volume than you might be used to, but the trade-off is that at the end – you can release it. As a parallel effort to the ongoing sprints of releasing new IT offering functionality, Product Management can work with early adopters of the new system or customers to integrate their feedback into the backlog to make adjustments keeping the team’s efforts in line with their needs.

How frequent releases help you satisfy and retain your best employees

Think back to the last time you released to your customers. There was probably a brief feeling of satisfaction, hopefully a validation from the customer that you delivered what they wanted, and your team learned a thing or two about how effective they are at deploying and testing the changes that were delivered with the release. Soon afterwards, the team gets to start all over again and these lessons are forgotten.

If you think about a long term relationship, when two people haven’t talked for a while they can get nervous. “Does he still remember what I said about what we were going to do?”. “I wonder if they still feel the same way about me?”. This phenomenon is also present in product development, and the longer your team goes before releasing, the bigger impact these psychological (and measurable) effects have on the profitability of your business goals.

Keeping delivery staff satisfied

When a change is delivered to the customer that meets their needs, the team gets a big boost in motivation. The team is thanked and hopefully rewarded for their efforts, and sales and marketing have a great new story to tell. During this period of “delivery afterglow”, staff are intrinsically motivated to work harder as they feel a responsibility for and purpose to their job. After a while however, staff can revert to their instincts to question how important their job really is, leading to the “I’m just a cog in a wheel” mentality. “Was what we delivered really that big of a deal?”. “I wonder if we can repeat that success again?”.

When release cycles are short enough, this feeling of satisfaction becomes constantly present and creates the environment where people love to do their job not just because of their compensation, but because of the satisfaction they get out of doing it through regular positive feedback. An environment like this is contagious – staff outside of the successful team want to learn their methods and repeat their success, and staff on the successful team are happy to talk about it with friends and potential customers.

What have you done for me lately?

From the customer point of view, they also experience similar emotions that have an impact on the profitability of your delivery efforts. If a long period of time has elapsed between when the customer got a release with changes, they may begin to wonder if you still understand their vision. “Do they know what’s changed in my market since last time we met?”. “I hope they understood what I said!”. “I wish I could talk to them more without bothering them!”. When release cycles are long, this risk of changing priorities and incorrect assumptions has a higher cost. When a manufacturing plant releases a part on to the next station that has a problem, it is often caught via quality gates when assembled as part of the next process to stop the line from moving it forward. In product development information is our inventory, and our customers are the quality gate that matters most.

If an incorrect assumption is made about a change or feature and not validated with the customer early, hundreds of other changes can be based on this incorrect assumption and they are all impacted if the customer finds them to not be valid once released to them. Engineers can lose motivation dramatically if they release a big feature that took a long time to implement only to find that it all has to be reworked. It makes both economic and behavioral sense to release more frequently to ensure that the relationship between the team and its customers is aligned as often as is reasonable.

Practice makes perfect

When releasing changes to the customer, there are delivery costs that are only incurred at the time of release. These usually include things like deployment, user acceptance testing, updating user documentation, and gathering feedback. When release cycles are long, these activities are infrequent so there is low motivation to getting better at them. If a team only releases to their customer once every 6 months, they feel the pain of these activities infrequently and so they are willing to see it as such – a necessary evil that isn’t worth the time to improve. When releases are more frequent, the cost of manual or inefficient delivery processes is more apparent and staff can more clearly see the need for making them as efficient as possible.

Optimizing release process costs is doubly profitable as it both reduces the cost of performing the process, and reduces the time for return on investment due to enabling more value to be delivered per release since a smaller percentage of the effort that goes into a cycle is taken up by these processes. It also increases staff job satisfaction because more time is spent delivering value that is the direct result of the innovation inherent in the creation of IT assets, not simply drudging through excessive process overhead that hasn’t been optimized due to low motivation to do so.

Motivating for excellence

A final important consideration that impacts staff retention and job satisfaction is the opportunity that frequent releases create for evaluating competence. When releases cycles are long, staff are able to report being done with tasks but this is not truly verifiable until it is released to the customer. Many organizations realize the inherent value in retaining top talent but struggle to know how best to help them grow. One of the best ways to help our employees be more effective is to have regular checkpoints during which to measure both quantitative and qualitative outcomes. An IT asset release is a perfect time to do this.

The SCRUM methodology encourages teams to hold a sprint retrospective meeting during which the team can be candid about their successes and opportunities for improvement since the last iteration. When iterations of effort are reported as “complete” at the end of each sprint but not released to customers, unchecked problems with deployment and missed alignment with customer needs is not caught and can leave a team with a misplaced perception of success. This perception is then aligned when the release actually occurs, and the reset between what was perceived and what is reality can be harsh and demotivating.

Rather than delay the inevitable, by releasing to customers more often before starting new work, leaders that evaluate their staff have a better gauge for where staff are doing well and where their skills may need help. An effective manager will use this period to both reward and compliment staff on their improvement and be courteous in helping them see where they need to improve. Though this increased confrontation with competence can initially be met with feelings of uneasiness, it soon becomes a regular part of work and employees begin to expect honest feedback and to be complimented and rewarded when they improve.

Top 5 business myths about Continuous Delivery

When a team decides to try reducing the time it takes for their ideas to get to their customers (cycle time), there are a few new technical investments that must be made. However, without business stakeholders supporting the changes in a SCRUM approach that delivers frequent releases, decisions and planning are driven by gut feel and not quantifiable outcomes. The following is a list of the top 5 myths I encounter (and often address when I provide coaching) to help staff that are not solely technically-focused when they begin adopting Continuous Delivery.

#5: By automating deployment, we will release more profitable ideas.

Automating deployment of IT assets to reduce low value activities like manual configuration and deployment (with risky error-prone manual human intervention) certainly can eliminate wasted capital as part of the process of releasing IT offerings, and is a key practice of Continuous Delivery. However, if the frequency of releases is long, the cost of delaying the availability of those releases to customers adds risk in that their viability in the market may no longer be what was theorized when it was planned.

Once release frequencies are improved, measurement of customer impact and proper work management (specifically appropriate capacity planning and calculating the cost of delay for potential features) must be done to ensure that ideas that turn out to be misses in the market stop stop being worked on as soon as they are identified as bad investments. It is this harmony of smart economic decisions with respect to investing in the idea combined with the technical benefits of building an automated deployment pipeline that transforms the profitability of an IT value chain.

#4: We must automate 100% of our testing to have confidence in automating releases to production

Utilizing automated quality checks to ensure that changes to IT assets do not break existing functionality or dependent systems is certainly a good practice. A long manual test cycle is doubly problematic: it delays releases and adds risk since many teams try to get started on new work while testing is underway. When issues are found with a release candidate build or package being tested, engineers must stop what they are doing to troubleshoot and attempt to fix the problems.

On the flip side, automating the entire testing effort has its own risks as the team can cost the business large sums by having to change and maintain tests when they make changes to the design which happens frequently in Continuous Delivery. Deciding on an appropriate test coverage metric and philosophy should be treated with importance and not included in work estimates as separate line items to discourage removal in an attempt to cut costs. Cutting quality is often the final dagger in the throat of a struggling IT offering.

#3: The CFO requires us to release everything in the backlog to report costs

Many businesses treat IT investments as capital expenditures since they can take advantage of amortization and depreciation to spread the cost of that investment over a longer time period. However, this assumes that the value in the investment provides a consistent return over the lifetime of it being used to generate revenue. A SCRUM process for delivering IT assets aligns better with being recorded as operating expenditures since a minimum viable offering is typically released with a low initial investment in the first few sprints, and the business makes ongoing “maintenance” changes to the offering as the priorities of the market and customer needs change. This is especially true today with everything moving increasingly to cloud based models for value consumption.

#2: We need a “rockstar” in each role to deliver profitable offerings

Many IT offerings that start with an idea are initially implemented with an expert in a particular technology or aspect of delivery, and the team leans on them early on for implementation and expertise. As the complexity of a solution expands, the biggest drain on the profitability of a team is no longer the availability of experts and the high utilization of people’s time – it is the time work to be completed spends waiting in queues. There are several ways to reduce wait time when work with a high cost of delay is held up in a queue. The two methods I see with the most value are to reduce the capacity utilization of team members, and to enable staff to work on more than one discipline.

When team members are highly utilized (their planned capacity is over 60%) this leaves no room for the highly-variable process of delivering IT offerings to account for unknowns that were not identified during planning or design of a cycle of implementation. If the cost of delaying the availability of an idea is high, the cost increases when the date planned for release is missed. Rather than loading resources up to a high capacity, leave them with reasonable overhead to collaborate, tackle unforeseen challenges, and help each other if they finish early.

When team members are specialized, the probability of one member being blocked from continuing by another goes up dramatically. Work to be completed spends more time in a queue wasting money and not moving closer to being made available to customers so it can realize a return. Though you will always have team members that have expertise in specific areas, resources that are willing to test, make informed product priority decisions, and help with deployment and automation are more valuable as part of an IT value stream than specialists. Use specialists when the work requires it, but scale more of your resources out across multiple disciplines for sustainability.

#1: Until we release everything in the backlog, we won’t succeed with our customers

This myth is driven by the manufacturing mindset of looking at IT offering delivery as though all features must be identified up front and misses the point of agile methods entirely. The backlog is a set of theories on what customers will find to be valuable at any given point in time. Any offering that takes more than one release to complete will have a working minimum viable product available to some audience where feedback can be gathered before it’s done.

Since the point of frequent releases is to get that feedback and let it impact the direction of the IT offering, planning to release everything in the backlog leaves no capacity for taking action on that feedback. If you only plan to release everything the business thinks is a good idea at the beginning of a project before letting customer feedback influence priorities, you are simply releasing milestones of planned up-front work – which is a classic waterfall delivery process.

Overcoming your quality debt to enable continuous delivery

If you want to release software faster, it’s a given that you need automated deployment capabilities, and an incremental product change process like SCRUM – but you also need confidence in the code base. This confidence comes from having agreement on what the application currently does, and being able to verify quickly at any time that it still works as users expect.

Acceptance defines how you demonstrate it is working

Even in an agile development process such as SCRUM it is of the utmost importance that you define acceptance criteria that can be quickly verified. When the business and the team agree to implement something in a sprint, coding shouldn’t be started until a description exists in English of how to demonstrate that it works properly. This description provides both a script for the developer to demo the functionality to the business, and a set of steps to guide the developer or a QA resource to implement an automated test that verifies it works correctly without requiring manual testing.

It is important that the acceptance criteria leave as little room for interpretation or the need to get more info from the author of the criteria as possible.

Bad acceptance criteria

Go to the products page. Click on a product and enter in purchase details on the next page. Submit the order and make sure there aren’t any errors.

Good acceptance criteria
  1. Go to http://mydevserver/somepage
  2. Click the product “My Test Product”
  3. In the page that appears, enter the following values:
    1. Name: Test
    2. Quantity: 6
  4. Click the “Submit” button
    1. On the page that appears, the message “Product ‘test’ was added to your cart’ must appear on the page.
    2. An email must have been sent that includes the subject ‘About your order from XYZ corporation’. The body should contain the message in the attachment to this user story where ‘Product name’ in the attachment is replaced with ‘Test product’ and ‘User’ is replaced with the account you were signed in as when you made the purchase.

Quality products are not an accident

When you haven’t defined acceptance criteria that is either written up or contained in an existing automated test that is self documenting, there is functionality in your application that is subject to change at any time. It can change in that if refactoring is done, the existing functionality can break without catching it with a manual test – but even worse, there is nowhere the team can go to understand its original intent and the reason for its existence in the first place. This leads to incorrect assumptions when enhancements to it are made, disagreement between team members in communicating its operation and intent, and a deceptive view on its completeness.

In a green field project, it’s easier to enforce automated acceptance testing being done as you can hold back kicking off the next sprint until all acceptance tests can demonstrate passing and the features are demoed and accepted by the business. The business and the team get used to the velocity needed to do so, and the rate at which new features are available.

In a brown field (existing) project, chances are there will be significant functionality that already exists for which no automated tests exist, verifying it must be done through manual testing, and in a worse scenario; it may not be tested regularly at all and the business has lost clarity on its behavior and operation. To automate verification of it working properly will cause the velocity of the team to slow down.

When this happens, a team gets into what I like to call “quality debt”. The more features that exist in the application that are unverified, or the longer it takes to verify those features, the more investment it takes to ensure quality of the application – and in turn the slower you can release. This situation is in direct opposition to continuous delivery, and to get your product ready for quicker cycle times a strategy for paying down this debt is crucial. The higher up this scale you are, the lower your debt.

Evaluating acceptance readiness for continuous delivery in existing functionality

If you are on a brown field project and want to set a goal to reduce your release cycle time, the team needs to evaluate each function of the software to determine how far along this progression of acceptance readiness it is.

  1. Implemented – the software does something in the code, and it was demonstrated at some point. No tests or documents exist that describe it however.
  2. Partially verifiable – a document or test exists somewhere that describes how the function should work, but it has grown out of sync with changes over time of the feature, or is incomplete and does not cover all cases.
  3. Acceptance testable – a document exists somewhere that describes how the function should work, but it takes manual effort to verify it each time a release grows near.
  4. Automated acceptance – Acceptance tests exist that can be run automatically on demand and report their success or failure. They cover all implemented aspects of the feature as of the current sprint.

Pay off existing debt

If your project’s features are not at phase 4 (Automated acceptance), you will need to schedule time in coming sprints to help them get there. I would caution against jumping from implementation to automated acceptance without establishing the acceptance criteria again. If there is no document or test that says what a feature should do, automating it without making sure it meets the needs of the business (and that what it does is understood) is dangerous because your are investing in automating something that is more likely to change. Revisit each existing feature with the business and come up with acceptance criteria first, then automate.

Don’t add new debt

In addition to scheduling a portion of the workload of the sprint to pay down the existing debt, avoid adding to it by defining better acceptance criteria in user stories scheduled for completion that relate to new work. Also require that automated acceptance tests be built before the conclusion of the sprint that prove proper operation of those stories. You will find that you can get less done in the sprint, but at each one’s conclusion you have features that can be released to users with confidence as they can be verified automatically at any time.

The pain only lasts as long as you want it to

The harsh truth is that the more your existing application does that is not automated for acceptance, the more painful it is to get out of debt. An organization can continue to go about business as usual without addressing it, but doing so leaves them at a competitive disadvantage as they take longer to get to market with new functionality. Organizations with better discipline around managing their workload and establishing automatable acceptance processes will respond more quickly to changes in the market, deliver features that meet the needs of their customers faster, and deliver them with more consistent quality.

Put all your environment-specific configuration in one place for a pleasant troubleshooting experience

Most software applications leverage a variety of third party libraries, middleware products, and frameworks to work. Each of these tools typically comes with its own method of configuration. How you manage this configuration has an impact on your ability to reduce time wasted tracking down problems related to differences in the environment in which your application runs.

Configuration as it relates to delivering your software really comes in two forms. The first of these is environment-neutral configuration. This type of configuration is necessary for the tool or software to work and doesn’t change when used in your development, testing, production, or any other environment. The second type is environment-specific configuration and is basically the opposite.

When your application is delivered into an environment, whether on a server somewhere or your users’  devices, troubleshooting configuration problems is much easier if all environment-specific configuration is in one place. The best way to do this is to create a table in a database, or a single file, that stores name/value pairs. For example the “ServerUrl” configuration setting might be set to “localhost” in the development environment. Where in production, it’s some domain name you probably purchased.

The problem with adopting this at first glance is that most tools have their own method of configuration, so to make this work you need to find a way to populate their configuration from this database or file. Do this with the following process:

  1. Create a table or file named “ConfigurationSettings” or “ApplicationSettings” for example, that holds the name/value pairs for environment-specific configuration. You can use nested pairs, or related tables if you need more complicated configuration.
  2. Create a build script for each environment (T-SQL, PSake, MSBuild, rake etc.) that populates the table or file with the values appropriate for it. If you have 4 environments, you will have 4 of these files or scripts.
  3. When you target a build at an environment, run the appropriate build script to overwrite the configuration values in that environment with the ones from the script. Note that I said overwrite, as you want to prevent people in the field from changing the configuration of your environment without doing a build. This is because configuration changes should be tested just like code.
  4. For each tool or asset that you want to configure, create a build script (PSake, MSBuild, rake etc.) that reads the values it needs by name from the table or file populated in step 3, and updates the configuration in the format needed. An example would be updating a web.config file’s XML data from the data in the table or file, or applying Active Directory permissions from the data in the table or file.
  5. Create a page, dialog, or view in your application that lists all of the data in the configuration table or file. This can be used by your personnel to easily see all the environment-specific configuration settings in one place.

This may seem like a hoop to jump through considering Microsoft and other vendors already provide environment-specific configuration files for some of their technologies, but I still encourage you to do this for the following reasons:

  1. When something goes wrong in one environment that works in another, it is much faster to look at a page with a flat list of configuration settings than to look in source control at a bunch of files or scripts that can be anywhere in your source tree.
  2. When environment-specific configuration is stored in source control as scripts, you have an audit trail of how those changes have occurred over time in the history of each file.
  3. Whenever you need a new environment, you can simply create a new script with data for that environment and you already have an automated means of populating the configuration mechanisms used by all of the tools and libraries you leverage.
  4. When you need to provide environment-specific configuration for a new technology, you can script setting it up and not worry about whether it supports environment specific methods out of the box.

Pay off your technical debt by preferring API clarity to generation efficiency

I’ve built the technical aspects of my career on combining technologies from Microsoft, that are easy to sell into enterprises that require the confidence that comes from their extensive support contacts and huge market footprint, with open source technologies that steer the direction of technology ahead of the enterprise curve – eventually to be embraced by them.

Microsoft has always provided powerful tools for developers in their Visual Studio product line. They focus on providing more features than any other vendor, and also having the flexibility to allows developers to design their software with the patterns that they find make the most sense to them. Because of this, the community is full of discussion, and there are always new ways to combine their technologies together to do similar things – but with quite a bit of variance on the architecture or patterns used to get them done. It can be daunting as a new developer, or a new member of a team, to comprehend some of the architectural works of art that are created by well-intentioned astronauts.

After I learned my first handful of programming languages, I began to notice the things that were different between each of them. These differences were not logic constructs, but rather how easy or difficult it could be to express the business problem at hand. Few will argue that a well designed domain model is easier to code against from a higher level layer in your application architecture than a direct API on top of the database – where persistence bleeds into the programming interface and durability concerns color the intent of the business logic.

In recent years domain specific languages have risen in popularity and are employed to great effect in open source projects, and are just starting to get embraced in Microsoft’s technology stack. A domain specific language is simply a programming interface (or API) for which the syntax used to program in it is optimized for expressing the problem it’s meant to solve. The result is not always pretty – sometimes the problem you’re trying to solve shouldn’t be a problem at all due to bad design. That aside, here are a few examples:

  • CSS – the syntax of CSS is optimized to express the assignment of styling to markup languages.
  • Rake/PSake – the syntax of these two DSLs are optimized to allow expressing of dependencies between buildable items and for creating deployment scripts that invoke operating system processes – typically command-line applications.
  • LINQ – The syntax of Language Integrated Query from Microsoft makes it easier to express relationship traversal and filtering operations from a .NET language such as C# or VB. Ironically, I’m of the opinion that LINQ syntax is a syntactically cumbersome way to express joining relationships and filtering appropriate for returning optimized sets of persisted data (where T-SQL shines). That’s not to say T-SQL is the best syntax – but that using an OO programming language to do so feels worse to me. However, I’d still consider its design intent that of a DSL.
  • Ruby – the ruby language itself has language constructs that make it dead simple to build DSLs on top of it, leading to its popularity and success in building niche APIs.
  • YAML – “Yet another markup language” is optimized for expressing nested sets of data, their attributes, and values. It’s not much different looking from JSON at first glance, but you’ll notice the efficiency when you use it more often on a real project if you’ve yet to have that experience.

Using a DSL leads to a higher cognitive retention of the syntax, which tends to lead to increased productivity, and a reduced need for tools. IntelliSense, code generation, and wizards can all cost orders of magnitude longer to use than to simply express the intended action using a DSL’s syntax when you’ve got the most commonly expressed statements memorized because the keyword and operator set it small and optimized within the context of one problem. This is especially apparent when you have to choose a code generator or wizard from a list of many other generators that are not related to the problem you’re trying to solve.

Because of this, it will reduce your cycle time to evaluate tools, APIs, and source code creation technologies based not on how much code your chosen IDE or command-line generator spits out, but rather the clarity in comprehension, and flexibility of that code once written. I am all for code generation (“rails g” is still the biggest game changer of a productivity enhancement for architectural consistency in any software tool I’ve used), but there is still the cost to maintain that code once generated.

Here are a few things to keep in mind when considering the technical cost and efficiency of an API in helping you deliver value to customers:

  • Is the number of keywords, operators, and constructs optimized for expressing the problem at hand?
  • Are the words used, the way they relate to each other when typed, and even the way they sound when read aloud easy to comprehend by someone trying to solve the problem the API is focused on? Related to this is to consider how easy it will be for someone else to comprehend code they didn’t write or generate.
  • Is there minimal bleed-over between the API and others that are focused on solving a different problem? Is the syntax really best to express the problem, or just an attempt at doing so with an existing language? You can usually tell if this isn’t the case if you find yourself using language constructs meant to solve a different problem to make it easier to read. A good example is “Fluent” APIs in C# or VB.NET. These use lambda expressions for property assignment, where the intent of a lambda is to enable a pipeline of code to modify a variable via separate functions. You can see the mismatch here in the funky syntax, and in observing the low comprehension of someone new to the concept without explanation.
  • Are there technologies available that make the API easy to test, but have a small to (highly preferred) nonexistent impact on the syntax itself? This is a big one for me, I hate using interfaces just to allow testability, when dependency injection or convention based mocking can do much better.
  • If generation is used to create the code, is it easy to reuse the generated code once it has been modified?

You’ll notice one consideration I didn’t include – how well it integrates with existing libraries. This is because a DSL shouldn’t need to – it should be designed from the ground up to either leverage that integration underneath the covers, or leave that concern to another DSL.

When you begin to include these considerations in evaluating a particular coding technology, it becomes obvious that the clarity and focus of an API is many times more important than the number of lines of code a wizard or generator can create to help you use it.

For a powerful example of this, create an ADO.NET DataSet and look at the code generated by it. I’ve seen teams spend hours trying to find ways to backdoor the generated code or figure out why it’s behaving strangely until they find someone created a partial class to do so and placed it somewhere non-intuitive in the project. The availability of Entity Framework code first is also a nod towards the importance of comprehension and a focused syntax over generation.

%d bloggers like this: