Clear Measure Blog

hidden fees.JPG

“How much will it cost to do ___ software project?” That’s a reasonable question you are probably asked all the time if you are a software leader. If you are a division executive or otherwise responsible for a P&L, you’ve confronted all the costs associated with custom software. If not, there are five hidden costs of custom software that you should understand. It’s straightforward to estimate the costs of building a new piece of custom software if you treat it as a pure build project. We can see building projects all around us. The houses/apartments we live in, the cars we drive. We also understand the building software is not like building a car or anything else mass produced. Of any vehicle produced, software is more like a fire engine. Fire engines are built one at a time by dedicated teams, and fire departments pay the cost of having them built, but they also shoulder ongoing costs of operating and maintaining them. Here are the five hidden costs of custom software.


The minute you hire software developers, project managers or any consultants on a...


As a software leader, you compete in this market for in-demand developer talent. You understand the pain that was caused the last time one of your key developers resigned their position for another opportunity. If you tracked the resultant onboarding time and time to become similarly effective, then you understand the cost better than most. If you don’t remember this pain, learn from others and start planning for this eventuality so that it doesn’t represent an unmitigated risk for your organization.

Expect and plan for turnover

While past generations might have worked for the same employer for thirty years, don’t expect that from your workforce, especially since you probably don’t offer the lure of a guaranteed pension to get them through a lengthy retirement. Along with this general change in the workforce, the technology and software development fields are so new that the workforce is experiencing exponential growth. Stack Overflow’s developer survey...


You run a software organization that develops and runs several mission-critical applications, all custom-developed. Your team is friendly, and the office culture is uplifting. Problems happen with the software, but you and your team always rally and overcome them. You all take pride in what you do. But a vacation is out of the question.

As spring break approaches, the idea of a vacation sounds great. And, terrifying. Your business – and your customers – depend on these key applications. If the software goes down, your business goes down. How does it look if you’re nowhere to be found? It’s hard to fight fires while sitting on the beach.

Why is the software so dependent upon you – and your deeply-held knowledge? Why can’t the team function and resolve issues without you? Why is it you never quite know what could go wrong?

If this story sounds familiar, you’re not alone. But you shouldn’t feel tethered to your software systems – and your business operations – like a ball and chain. Here are several underlying problems and solutions we use at...


In this blog series, Bob Walker from Octopus Deploy explores automating database deployments and walks through the process of setting up database lifecycle management. He provides some real-world examples using a variety of database deployment tools and discusses some common pitfalls you might run into.

  1. Automated database deployments series kick off - An introduction to the challenges (there’s quite a few) and benefits of automating your database deployments.
  2. Automated database deployments iteration zero - Exploring the different approaches to automating database deployments, moving to dedicated databases, communication, and building trust.
  3. Automated database deployments using state based Redgate SQL change automation - A detailed tutorial on how to set-up an automated database deployment pipeline using the state-based approach and Redgate tooling.
  4. ...

I’m excited to announce I’ll be speaking at a few events here in Austin:

  • March 11, 2019: Austin DevOps Meetup. Austin DevOps is a community of practitioners who strive to improve through sharing the experiences and expertise. Learn more about the group here.
  • May 22, 2019: SQL in the City Summit. Hosted by Redgate, SQL in the City Summit Austin brings together 100+ database, IT, operations and development leaders together to discuss Compliant Database DevOps. Learn more about the event here.

This month we are continuing our webinar series, which we designed to help you and your software teams to move fast, build smart and run with confidence. Our webinar schedule is as follows:

  • Thursday, February 28: A DevOps Roadmap for Software Releases in Hours (Registration open!)
  • Thursday, March 7: A DevOps Roadmap for Low-Risk Application Modernization
  • Tuesday, March 12: A DevOps Roadmap for Launching a New Project
  • Thursday, March 28: A DevOps Roadmap for Software Releases in Hours

If you have questions on the above, please don’t hesitate to reach out to Rayne Fulton,


1. Cost

2. Supportability

3. Security

4. Reliability

5. Forward Compatibility

Download to Read More


Your path to a successful DevOps implementation..... just a checkbox away......

Download The Checklist


1. You’re not a dedicated software company

2. Your needs don’t change suspiciously often

3. Your requirements are super specialized

4. You've had a hard time recruiting developers

5. You're at the mercy of auditors or regulatory commissions

Download Now!


Most apps start small.

Small is nice. Small is simple. Remember when your applications were small and nice and simple and… manageable?

Me neither. It happens so fast.

At some point along the way, somewhere between tiny-little-projecty-idea-thing and commercially-viable-business-with-real-customers, things get complex. While our business teams are celebrating “scaling”, your development teams is acutely aware of the challenges that arise from growth -- exponential increases in infrastructure and system complexity, code volume, and technical debt.

So, we go into “Management Mode”. And we think “hey, all of these services we’re using, they provide event streams -- this will be fine, I can get the data!” I can measure it. Then you realize capturing and interpreting all the data streams are really time consuming. What may start as a single script using the Github API can quickly grows into event streams from hundreds of developers. Suddenly, you’re building a full-blown internal tool for development team...