100% design automation is generally unachievable. You’ve heard me say it before and I’ll say it again. 100% design automation is generally unachievable. And it is not the fault of the tools, it’s just the nature of process and automation. There will always be a balancing act between investment in time, money and effort with the value of business results. This fact can have some very significant and, to some, unsettling implications.

Let’s start by stressing the end of that statement about balance. We are balancing our efforts, the amount of time, sweat, money, lost opportunities, overtime, and caffeine that we consume against the business benefits. I’m going to stress that these are benefits to the business, to the value that we as a company provide to our clients, to our team members, our community or to bottom line profitability. This is often something that we solutions architects and administrators everywhere forget to take into account.

You can craft the most elegant, sophisticated, powerful tool on the planet, but if it doesn’t directly convert into a sufficient amount of value to the business, then it is a waste of time. Most often, what we are producing is in direct response to a business problem, but we still need to balance the time and money that we put into the solution versus the value that we are going to receive. We need to look at a variety of factors to determine that value. Some of those are a bit intangible, like customer experience, but they all will eventually come back to business benefit.

You’ve heard me drone on many times about the fact that you can’t save yourself into being a millionaire, and how the amount of time that you save with an automation tool doesn’t mean anything. What matters comes in how you use that time (ex. new product development), or how that shortened time frame affects the company (ex. higher sales volume). There is certainly a business benefit to improving job satisfaction for people by streamlining or reducing non-value-added tasks. But even that has a finite value to be balanced.

The other side of the equation lies in the amount of resources that you put into the implementation. The obvious part of this lies in the development time, software, hardware and related costs. If none of your customers are going to gain benefit from your automation, then there’s no reason to spend the time developing customer-focused user experiences or investing in more expensive web server hardware when it will only be a handful of internal team members using the tool.

Those examples are very easy to spot and to agree that some efforts will not result in sufficient business benefits. But the more contentious discussions arise when we get into the nitty gritty of the implementation. This most often occurs in two primary categories: product enhancements and solution elegance.

When we talk about product enhancements, we are referencing those constant “wouldn’t it be cool if we could…” and “while I’m in here, maybe I should just…” statements that we constantly make. There are three answers to these questions.

  1. First, if there is a solid business case for doing this immediately – remember, this must go back to business benefits – then go for it.
  2. Second is the case where the benefit is there, but it is not worth delaying the rollout of your tool. In those cases, we keep a parking lot list of all of these improvements that we want to make “when we have time.” We revisit this parking lot list regularly, prioritizing it as new items arise.
  3. The third and final case lies in those features that we just fund with the money in the business benefits. These are most often features that are nice to have, but will only provide a small benefit for a significant effort. In many cases, we’re really the only ones that will recognize the effort. While it is very hard to fight the urges to build these features, we need to maintain our focus on the primary benefit of delivering our tool into production.

The topic of solution elegance and development discipline can result in arguments. The question here is whether it is acceptable to use quicker methods to solve a problem when more elegant, some argue these as more “correct,” methods exist. Herein lies the difference in mindset between a programmer and an engineer. The mechanical engineer in me says that in many cases, we will substitute less expensive parts into a design for the sake of cost, weight or performance. If I can have someone in the shop do a quick, down-and-dirty welded bracket, then there’s no reason that I should invest in tooling and forge time and shipping and machining time for custom cast braces. Could the forged brace be considered the better or “correct” way to produce that part? Sure, but any engineer would state that the weldment is a perfectly valid approach since all of the design specifications are met or exceeded. And the engineers would further tell you that it is a better solution since it lets you roll out your product faster, with less manufacturing effort, and it’s cheaper.

The programmer in me, however, says that these are shortcuts and that if you know there is a better way, then there’s no excuse not to use that better way. Unfortunately, when I think this way, I come in over budget and past deadlines.

The answer is to fully understand the business benefits, to be able to quantize them and to be able to compare them to the realistic effort that is going to be required and the effects that this effort will have on delivering all of the other parts of your implementation. Engineers know that everything in design is a trade-off, that’s why there are so many cars. A Bugatti Veyron sacrifices gas mileage for horsepower. And Mercedes sacrifices aerodynamics for cargo space in their delivery vans. So you need to ask yourself, do you need to go 0-60 in 3.4 seconds, do you need four doors to pick up the kids at school, or do you need an eight foot bed to pick up full sheets of plywood? Because having them all is generally unachievable.