Deployment Confidence

Deployment Confidence

Deployment Confidence is a measure of a change’s likelihood to break the production environment. Some changes are trivial, and after code review and testing have little to no chance of breaking the production system. Other changes, especially when they are sourced from long-lived branches and involve many changes, would be riskier. The higher the risk, the lower the Deployment Confidence is.

Experience Required

It doesn’t take much skill to identify changes that have a high likelihood of breaking production, but it does take some experience. In general, things to look for that should decrease your Deployment Confidence include:

  1. Many changes made without deployment (thousands of lines of code changed with over 10 non-atomic commits)
  2. Long-Lived Branches (likely a result of #1)
  3. Complex database migrations
  4. Major refactoring
  5. Environmental Drift: staging != production != local dev

Versioning Strategy

Versioning Strategies can range from virtually non-existent (Git) to Complex. As always, you’ll want to [choose the right tool for the job].

SemVer or Semantic Versioning

Semantic Versioning is a methodology for identifying changes over the course of time. Version x.x.x is the popular recommended format, with each number in the release having a particular meaning.

MAJOR versions by definition imply that this version includes breaking changes when compared to the last Major version.

Semantic versioning is most useful when you are distributing a software package that many people rely on, such as in Open Source Software. The easily identifiable Semantic Versioning can quickly alert developers to potentially breaking changes. This versioning is also widely adopted in the Ruby, Python, and NPM ecosystems. Developers frequently “pin” dependency versions to ensure compatibility. As a default, you should take care when upgrading software dependencies, and SemVer makes it easy to identify breaking changes (assuming that you trust the developers doing the versioning)

Sizing Software Work Appropriately

Sizing software work appropriately has some challenges and pitfalls, but there are a few simple guidelines you can follow to help raise your level of confidence in your team delivering on time. First, you should [Make Sure You’re Building the Right Thing]. Next, [Learn How To Estimate Software Work]. We encourage you to use [Fibonacci Estimation for many reasons].

Assuming that much is straightforward (which it isn’t), as a team, you need to take work on that you can reasonably expect to complete.

How to Eat an Elephant

Step 1. Butcher the Elephant. Cut it up into tiny pieces.
Step 2. Cook and eat the pieces one at a time. Size each meal so that you can finish it in one sitting.
Step 3. Ship it.

In software, [Agile Methodologies] encourage us to break work down into small chunks. Much like eating the proverbial elephant, it’s not likely to go supremely well on your first go of it. Perhaps it won’t ever be done perfectly, but you can follow some guidelines to make sure that you have a high probability of success.

How Big is Too Big?

Your team’s estimation accuracy is likely to increase over time. When you start a project, there are too many Known Unknowns and Unknown Unknowns. There is much uncertainty — and uncertainty never contributes to accuracy. You need to start somewhere, which is why we say an estimate of a 1 is the simplest of all tasks. As you progress up the Fibonacci scale, by the time you estimate a task at a 5, you’re looking at 4 ordres of magnitude in complexity. That’s approximately 10,000 times more complex than the most straightforward of changes.

So why on earth would you be willing to take on a task estimated larger than a 5 on a Fibonacci scale?

Stop. Keep It Stupid Simple.

We strongly discourage any team from taking on a task estimated at more than a 5 in Fibonacci estimation of complexity. As the complexity of a task increases, the chances of Unknown Unknowns being encountered increases. If your 8 or 13 point task is the most important thing on the docket and “absolutely must” be completed in the future, you should know what to do:

Break It Down

Take your 8 or 13 point task, and start talking through the approach with your team. Split the item into as many individual tasks as appear reasonable and necessary to achieve the goal of the original story.
Start by breaking down the item, focusing the team’s conversation on what is involved in achieving success for the original task. Once you have an accurate picture of what the technical pieces in need of execution are, Once you’ve worked thoroughly breaking the item down into its discrete parts, have the team go through another round of estimation.

Important Side-Note: help your team avoid context switching by handling the breaking-down and the estimation of tasks separately. Once you hit a 13 pointer in the backlog, it’s worth breaking it down right away, because the team’s shared context has switched to wrap their head around this item. Proceed to break the item all the way down into seemingly reasonable parts. Once you’ve accounted for all pieces of the work item, then move back to estimating the discrete parts. [Humans are Terrible at Context Switching] so help your team out by avoiding it.

A typical 13 point story could likely be broken down into 5-8 different individual tasks. You may be surprised to find that as you break the issue down, the sum of the parts is equal to more than that of the original 13 point estimate. It’s typical to see estimates of the tasks involved in the delivery of a 13-point story to break down as 5+3+3+5+2+1=19. There’s nothing quite like taking something complex, making it simple, and then realizing there’s more work involved than you originally had thought.

Why Does this Matter?

When a developer sits down at their computer for a day’s work, (let’s say it’s 8 hours), it’s reasonably likely they can complete a 5 point item that is well defined and has few unknowns. As soon as you pass beyond the 5 point threshold, the uncertainty begins to increase and the likelihood of the work extending beyond one-day increases. It’s essential that the work not extend beyond one day because it’s easier to get work done when you feel like you’re accomplishing something every day. Long, slogging tasks are disincentivizing.

By keeping your team’s work items small, you should see higher team morale, not to mention more easily testable code with more isolated changes.

Choosing The Best Git Branching Strategy for Your Team

Choosing the best Git Branching Strategy for your team helps to deliver value to your production environment quickly and with a high degree of confidence. Generally, the best advice we can offer is to start simple. Don’t over-optimize your git branching strategy before you have something in your workflow that needs improvement.

Branching Strategies

If you find yourself as the only developer on a project, using a branching strategy that is less-than-the-simplest-tool-for-the-job is likely to be [premature optimization]. A single dev working on code should be able to get a single task into production within one business day from the time they start working on it. Yes, the code needs testing, so are including that time in our metric of “deliver value within one business day.” Tasks need to be small enough to be shipped in one day for this to be achievable.

The three primary strategies range from simple to complex in the following order: GitHub Flow, GitLab Flow, and Git Flow.

Start with the simplest thing that works.

GitHub Flow

GitHub Flow is a vastly simplified workflow compared to the process that Git Flow recommends. GitHub Flow is usually best for small teams that don’t need to manage several different environments or versions simultaneously.

GitHub Flow is trivially simple. You start from the master branch, checking out a new branch to do your work. When you’re ready for your work to be reviewed and merged, open a pull request to master.

Even if you’re a solo developer on a project, we still recommend you go through the process of opening a pull request, as it serves as a record of changes submitted. The work should be tested (on its feature branch), and when it is considered ready for deployment, the code is merged to master and deployed with due haste.

GitLab Flow

GitLab Flow is the newest popular branching strategy. It’s great for the case where you have multiple different environments that you need to support. In GitLab Flow, master is still your base branch, and the code is branched from master when you are working on features. Additional branches are release-purposed for different environments.

Example: Perhaps you have an iOS project, so you can’t control when your production releases are made (due to Apple’s review process). In this case, you’d cut a release branch at the time you want to deploy it, and employ some versioning strategy that makes sense for your team.

Work can continue regardless of changes from the appropriate release branch and cherry-pick those changes back into master. This workflow minimizes [drift] as much as you can, considering that you can’t control production releases.
It’s also useful if you need to deploy a series of changes to a staging environment. You’d cut the staging branch from master until the QA process is complete.

Advantages of GitLab Flow include the workflow still being simple. Master is your base branch, and [you shouldn’t merge untested code to your base branch]. If there’s a problem with a release, you can handle the changes in the appropriate branch, and promulgate those changes back to master.

Git Flow

Git Flow, the original article from 2010 proposed that master should be your production branch and that you should set the base branch to development to avoid confusion. While there’s nothing inherently terrible about this, due to the nature of changing the defaults, it does come along with some cognitive load for the team to consider at all times.

In our experience, Git Flow encourages [drift between environments], since development is by definition not equal to production. We’ve seen Git Flow abused such that broken code is merged to development and is allowed to make roost there for weeks before deployment.

Advantages to Git Flow are a highly rigid process. If your paranoia level is high for a good reason, Git Flow does provide some added protection. Compared with the other branching strategies, Git Flow increases the number of hoops that developers need to jump through in order to release code to production. If you have a rigid QA process and infrequent releases, Git Flow may be right for you.


Additional resources on Git Branching Strategies and when to use them

What are the Pros and Cons of Git Flow vs. GitHub Flow
Git Flow Considered Harmful
GitFlow and When You Should Use It
GitHub Workflows Inside of a Company
The 11 Rules of GitLab Flow

Quality Assurance

Quality Assurance (QA)

Does every change need to go through a thorough quality assurance process? The answer is likely to be yes; however, you need to [choose the right tool for the job]. It’s unlikely that a cookie-cutter QA process takes into consideration [Deployment Confidence](/software/deployment-confidence). If it takes 30 minutes for a developer to merge and deploy changes to the staging environment for testing, then a QA tech can access those changes and test for another 15 or more minutes, you’re looking at about three-quarters of an hour worth of work.
Before anything even reached staging, there should have been a code review, which perhaps took another 15 minutes of a different developer’s time (assuming that the code review was perfect).
Perhaps the Product Manager already reviewed the changes in her local environment, consuming another 15 minutes of time.
All and all, we’re looking at a total of 1.25 hours of work spent on quality assurance in this case. Over an hour of quality assurance, all for one change.
What is the added value of the 1.25 hours of Quality Assurance? Did we stop to consider the Deployment Confidence for this work item? If the risk of breakage was low, the 1.25 hours spent on QA was probably overkill. The work item only needed a code review and perhaps a spot check by the Product Manager to make sure that the software behaved correctly. We could have avoided the staging deployment, in this case, avoided the use of a QA tech, and we could have delivered value to production faster.

Standard QA Process

  1. All team members should rebuild their environments on a regular basis, usually when pulling in new changes from the remote repository.
  2. Developers should test their code to the best of their ability before they submit their work for a peer’s code review.
  3. Someone else on the team performs code review: Code review means you read the code carefully and you pull the code into your local environment to test that it is working. Bonus points if, as a developer during code review, you have the time to test the specific feature change to ensure its behavior is appropriate.
  4. Review each pull request for a measure of Deployment Confidence: This isn’t an exact science, but a rough risk estimation is possible:
    • Low Deployment Confidence: the app needs thorough testing in a staging environment before deployment to production. This staging deployment should mimic, as much as possible, the deployment to production: including running migrations or other “launch-checklist” type items. The goal here is to surface any issues that may are likely to be encountered during the production deployment.
    • High Deployment Confidence: Code review and local testing is enough time spent before production deployment.
  5. Production rollbacks must be quick and painless. If you can’t easily revert changes in the production environment, spend time on this first. Production stability is paramount, and if production is fragile, then breakages will occur no matter the complexity of changes made.

It’s a better use of time to improve production stability than it is to add extra layers of process and time spent to deploy each change to production.

Deliver Exceptional Value and All Else Will Follow

Focus on Delivering Exceptional Value and All Else Will Follow

Working with software teams is an exceptional challenge, and it can be a heck of a lot of fun. Software is fun to work on when the team is winning, the client is happy, and the users love the product. If you have all of those things, you hopefully can make a decent living too.

Building high-performance teams are not that complicated, but it takes discipline. You need the right mix of talent. The team needs the right direction. It Takes Trust. The team can only operate as well as its weakest links. We aren’t football players, and we don’t need the likes of Bill Belichick to get our teams performing at a high level. What we do need is a profound commitment to our teammates to Always Be Delivering Exceptional Value.

We’d love for life to be more straightforward, but just because you work some hours doesn’t mean you can bill for them if you don’t create value.. Software is all about change, and things take time to complete. There are continually changing dynamics on a software project: from the state of the industry, customer needs, client demands, or toolkit changes. Workflows can usually be improved to add even more value to the team’s ability to deliver working software more reliable and faster.

If your team is five people with different knowledge and expertise, consider who is the weakest link, based on:
1. Skills and experience?
2. Team Dynamics?
3. Client Dynamics?
It may be that three out of the five teammates are weak for this project, all for varying reasons.
Faced with the possibility that over 50% of your team is weak, you might imagine they must not be delivering value. However, this very well could be a highly performant team. The team needs to be nurturing its weakest links, not ignoring them, hoping they’ll somehow improve.

Hope is not a strategy

What is Value Creation?

Value creation is the primary aim of any business entity. Creating value for customers helps sell products and services, while creating value for shareholders, in the form of increases in stock price, ensures the future availability of investment capital to fund operations.1

What is the Definition of Done?

The definition of done will vary slightly from team to team. Typically, we recommend that Shipped to Production means the task is done.

shipped === done

That’s all, nothing to see here, move along.

How long does it take to move something from Todo to Done? How many steps are there? How can we reduce friction for the team to be able to move things from todo to done even faster than before? Are we getting better at completing things more quickly? What is the constraint on the value pipeline — is it that no one is quick to do code review? Is it that the client is slow to do acceptance testing on the staging environment? Are there too many changes in each pull request, causing painful migrations and merges, blocking the team from being able to ship their pieces to Production?

There are fewer than a million ways that things go wrong on software projects on a value delivery level. Most problems smell like the ones listed above, and they are all resolvable.

-If the team goes a week without shipping anything to production, you have some explaining to do.
-If items take than 24-48 hours to complete, you need to reduce the complexity of each work item, to deliver the pieces more quickly.
-Team members must feel that they are able to win.
– Team members must be able to work through the process quickly and efficiently, delivering their value additive changes to production in less than a day’s work.

It Should Take Less than 8 hours to get something to production.

The “soft” skilled members of the team, such as Product Managers or Designers are not that different. The product manager delivers value by keeping the team fed with well-articulated work items that they can complete and quickly move through QA. The designer creates artifacts and iterates on them by working with the team. “Done” doesn’t mean shipped to production in these cases, as the end state is a work item that can be delivered by the dev team.

How does an Agile Coach Deliver Value

Agile Coaches or Scrum Masters are a meta value add. They’re there to ensure that the team is staying on track and is capable of completing it value delivery in a reasonable manner. The Agile Coach is there as a safety net to surface any apparent process related issues that the team would heartily proceed to ignore due to their inherent conflict of interest.

In more disciplined and experienced teams (meaning that this team has worked together, effectively, for an extended period), an Agile Coach won’t be necessary, because the team has grown in their shared discipline. If this team is capable at this time of operating a regular Sprint Cycle without a Scrum Master, they may be ready to graduate from scrum to kanban.

The value added by the Agile Coach is keeping the team on the rails. In sporadic cases are problems not foreseeable or preventable. It’s the Agile Coach’s job to keep the team on track.

Conflict of Interest

There is a pure conflict of interest that each developer faces on a software team. Their work is already challenging, and it’s in every developer’s best interest to make their job easier. Many of the technical debates that take place on a software team stem from this simple fact. If you have two approaches to a problem, perhaps one places more workload on the backend developer, and another puts the workload on the front end developer. How do you determine what the right call is? The answer, as many CPAs will tell you, is “It depends.”

Enter the Agile Coach. Having this person around to assist the team from a non-partisan perspective is where they add their value. The developers are not only trying to identify the most value-additive way to deliver their work, but they are also subconsciously optimizing for their workload. If the “Easy” way sacrifices user experience, developers will go unchecked if the Product Manager or Designer are not advocating for Great Ux*.

What’s the Value?

All of the technical minutiae of a software project boils down to this: What value is this pull request delivering?

  • [ ] The client asked for it && it makes sense
  • [ ] It satisfies a technical requirement from the client && that technical requirement makes sense.
  • [ ] It makes our users happy
  • [ ] It’s necessary to reduce the Technical Debt && Reducing the Technical Debt is the most important thing to do right now
  • [ ] It meets the acceptance criteria
  • [ ] It’s an objective improvement to the system
  • [ ] It will improve team velocity

If you can’t say yes to any of those checklist items, we’ve got problems. I don’t know how we’re going to be able to expect the client to pay for that.

That’s how we think about providing value for our clients. We know that as long as we are delivering exceptional value, then all else will follow.

* This is, in no way meant to shame developers. We used to be there writing code alongside you.

Building Trust on a New Software Project

Building trust is essential to teamwork. It’s critical to working with clients and vital to survival in human nature. Show me a team that doesn’t trust each other, and I’ll show you a team that doesn’t operate at capacity.

Trust is a Prerequisite for Value Delivery

Building trust is the first step in delivering value. Don’t believe me? Here is a strange example, (stolen from Seth Godin) but it illustrates the point. Try this:

Go up to a random house in your neighborhood, (someone you don’t know that well). Knock on the door, and offer them a 10 dollar bill for free. What will happen? They’ll say no, close the door, and peer back at you from between the blinds to make sure that you’re leaving. They will immediately start thinking that you are trying to give them counterfeit currency. “Why is this nut trying to give me money for free?”

Next, pick a different house, and put a 10 dollar bill in their mailbox. The next day, do it again, and again the third day. On the fourth, knock on the door and say “Hey, I’m the person who has been sticking $10 bills in your mailbox. Here’s another one.” This time, they’re likely to take the cash from you with a smile and say “thank you,” because now they know you’re crazy. You’ve built the trust. Now you can deliver the value.

Applying Trust to Software Delivery

Let’s make this more applicable to the software value delivery pipeline. You build a software application, and low and behold you’ve somehow magically delivered every one of your client’s requirements — it’s exactly what they asked of you. When it comes time to do your demo, will the client accept the work?

We don’t know. How much trust is there between your team and your client? If the client has convinced themselves beyond a shadow of a doubt that you are incompetent, incapable of delivering, and intentionally trying to screw him, will it make a difference if your work is of high quality or not?

Are there undiscovered bugs in the system that prevents it from functioning in the way that you understand it too? If there is a lack of trust and transparency within the software team, you probably can’t know the answer to this.

Build Trust First

You only get one chance at a first impression, but the last impression is the lasting impression. In the critical early phases of a new software project, it’s essential to do a few things well.

Empathize

Take the time to understand the situation of your client fully. You’ll want to figure out the following, but you might not be able to ask these questions outright.
– What is their business situation?
– Their place in their organization?
– Who is the person who pays the bills?
– Are they trying to make themselves look good to their boss?
– Are they trying to make their boss look good?
– What is their motivation?
– What is the business goal of the software project?
– Where have they been as a business?
– Where are they headed now?
– Where do they want to be in six months? A year?
– How does your project fit into their picture of reality?

As you increase your effectiveness working with clients, you will eventually learn to be able to answer all of the questions listed under “Empathize” within the first two meetings. You should document this information in an appropriate locale that your team will have access to as they come onboard to the project.

Define

A high-level overview of what the client is looking for is a good place to start. As you begin to unpack the project at a high level, pay attention for ways that you can deliver exceptional value as a team within the shortest possible timeline.

Questions to answer

  • What are the most important features that must work for the project to be a success?
  • What’s a rough estimate of how long it would take to build out those features as a functioning proof of concept?
  • What are the important dates in the future we must hit to be successful as a team?

ProTip™: There is always a deadline. You may have to ask three or more times, each time in a different way before your client finally spills the beans on the drop-dead date.

Get Early Wins

On a Blue Field project, don’t start with Authentication. User authentication is not value-additive, it’s table stakes. If your team is unable to deliver authentication in the first week, it doesn’t mean that your team is terrible, it proves that authentication is a table-stakes feature which includes a constellation of sub-features and every client is going to assume that authentication works (for most web-based applications). There are third-party libraries that you can leverage, but the bottom line is that building Authentication is not value-additive for the client’s software project. If you want to prove your team can build the software the client is paying for, focus on the features that are unique and cannot be serviced by off-the-shelf software packages.

Deliver exceptional value and all else will follow

Depending on the Frame of the Project this phase will always look a bit different, but some things don’t change.

Ship something in the first week.

If the project isn’t running on the internet, that’s not a deal breaker, as long as it’s easy for someone to run the project locally. As developers come online to the project, it’s important to give them the same sense of accomplishment by giving them an opportunity to deliver something to whatever the “production” environment is within the first day of joining the project.

Keep Your Client in the Loop

As the course of the project proceeds, there will be good news, bad news, and discoveries that your team makes along the way.

To build trust, it’s critical to keep the client well informed.

I don’t know a whole lot of people who think delivering bad news is fun. You need to give unpleasant news to clients as quickly as possible. Being quick to disclose adversity will help to prove that you’ve got their best interests at heart. Hesitating to provide a lousy update can easily be misperceived as your willingness to be untruthful. Clients need to know that you are working for them with their best interest in mind. That means keeping them informed in an extremely timely manner especially when things are going poorly.

Good news can always wait a couple of days or over the weekend. Clients will already be happy with good news so if it takes you a few days to deliver it, there’s not much risk of the interaction going poorly.

The amount of time that passes in-between when you learn of bad news and when you deliver that report to the client is inversely proportional to the amount of trust you will receive in return.

Kanban is for Ninjas

Several times, we’ve run into teams that are working off a Kanban board but are not productive. This experience has illustrated that in 95% of cases, Kanban is too undisciplined for an inexperienced team.

The term inexperienced team may sound like an insult to the team’s cumulative skill set; however, we’re talking about the team’s experience with each other more than any single contributor’s abilities.

For Kanban to work, the team members must be capable of aggressively clearing the value pipeline on a regular basis. If any item on a kanban board is remaining in place for over a business day, extreme measures should be taken to ensure that the team is still on track and capable of delivering.

Kanban reduces Scrum Discipline to an illusion. Humans are not good at performing one task at a single time, and although our computers allow us to attempt to do so, this is the ill-fated decision for any human to fall trap.

The singular act of focusing on the performance of one task is the state of flow. Kanban is reserved for teams that have proven they can stay on target together as a group, self-policing each other along the way.

Advantages to kanban on its face appear to be the relative lack of management necessitated for it to promulgate. Disadvantages include:
– The improper illusion that planning is irrelevant
– Incorrect sizing of work items
– The tendency for the team to take on well beyond what is possible
– Merge conflicts
– Inability to ship tasks to production
– Creation of work silos
– Excessive use of direct messaging
– Other symptoms as yet determined by the Sturgeon General.

The state of Flow.

For a team to progress to a sufficient capability to use Kanban, they must first prove they possess the skills as a group to run a scrum board effectively. The team must be capable of performing without a scrum coach, they must be disciplined enough to keep each other in line, under the gun, to Always Be Delivering Value

Don’t think you’re a ninja

Communication is critical, and remember you’re not infallible. Just because you know the ways of the warrior does not prove that the team around you does. You must show you are ready to graduate to kanban. You must determine that you are all capable of policing each other with the calm of a stormtrooper persuaded by the light side.

Then will you be ready to operate without the much-needed training wheels of Scrum. It’s not your ability, but the cumulative operational fitness as a unit that dictates if you are ready to take your discipline into your own hands.

The Zen of Determining Billable Hours

As an independent contractor working on software projects, nobody is standing over your shoulder that you can call “boss.” There isn’t a strict set of coworkers around you. You won’t always know what to expect from day to day. Priorities will forever continue to change, but you still need to be focused on delivering exceptional value for your clients.

Who exactly is your client? A false Trichotomy:

  • The Product Owner / Person paying for your work?
  • The Product Owner’s Users / People who will use your software?
  • Your teammates / People whose success depends on your delivery?

    All of these people are your client in one-way shape or form, but the only person whom you have contracted to work with and be paid by is the Product Owner.

Tracking Your Time

When should you be tracking your time? Always. No matter what you’re doing, you need to find a way to fit regular time monitoring into your workflow. Without the ability to consistently track your time, it will be impossible for you to have an accurate record of what you spend your time on.

Time tracking is essential. Are you checking email? You should have a time log entry set up for that. You probably check email every day, so track that time.

Slack Driven Development

What about reading slack? It’s tough to track your time as you flip thru slack channels, and no one is going to pay for that. An excellent question to ask yourself is “What am I working on right now?” As you get better at tracking your time throughout your work day, this will begin to come naturally. It will become more comfortable over time, and this discipline will improve your productivity, due to heightened focus.

As soon as you find yourself diving into a particular slack channel, you should quickly be able to identify the task that you need to give your focus. Start logging time to it, and keep on that task until it’s complete. As you move through your work, it may become reasonable to switch to another function within the same project. Context Switching comes at the expense of productivity, so it’s important to do your best to stay focused on task once you start the clock on it. Over time, you’ll find yourself consciously assessing the tradeoff between switching projects and merely continuing on the project that you already started on.

Always Be Delivering Value

While you’re flowing through your tasks for the day, you may notice that you are already .75hrs into a task and you haven’t been able to create any value in the time you’ve spent thus far. It could be a good time to pause and consider the work that you’re doing and the reasons for the apparent lack of production during this time.

In some cases, you may find that this can be an indication that the approach needs to be re-thought. Many times I’ve seen myself in this situation, only to re-assess, and within the next .25hrs, discovered a new, more straightforward, more efficient way to deliver the same value that I had intended to when I sat down to work on that task. I’ve now managed to spend 1 hours and provide what I expected to. I’ll undoubtedly bill this full hour to my clients because I spent the first 45 minutes discovering how to deliver the value in the first place.

In other situations, after 45 minutes, you may realize that you’ve learned enough to produce some artifact from your findings. This artifact can also suffice as value delivery in the right circumstances.

What If You Didn’t Accomplish Anything?

Sometimes, you’ll spend 45 minutes of work on a task that a client didn’t ask for, but you wanted to take the initiative. You should scrutinize this sort of work very carefully. How does the client receive this value?

If you can’t answer that question well, then don’t log the time to the client’s account. There is some risk we take on as freelancers, and if you’re not producing value, you cannot bill the time. Take what you learned from your investment of your time, reintegrate it with your understanding of the solution you’re implementing, and bring it to your team for consideration. Perhaps the team can find a way to make your initial research valuable, and if that’s the case, you’ll likely be the one tasked with working on the new deliverable.

First Do One Thing Well

First do one thing well. A simple rule, sure, but profound. Every disaster of a software project likely ignored this simple truism. By focusing on doing one thing well from the start, you’ll increase your confidence, your client’s confidence in your team, and your likelihood of success.

In general, business owners want software developed because they are in search of revenue. Maybe that revenue comes in the form of added internal efficiencies, or maybe it comes in the form of new customers. The fact of the matter is that the needs of the technology will continue to evolve. Your perfect software system from last year surely could use some improvement, still today.

Do One Thing and Do It Well

The rare case that this appears to be invalid is Unix tools. Most of these have been around since the 70s, like wget, sed, awk, curl, less, cat, etc. These tools have sustained their viability as long as they have due to their simple purpose and their persistence of reliability. These comparatively ancient tools should give us some insight into how to build software to last.

As a software team, the goal must always be to deliver working software. It can’t take six months. Every day when you sit down to write some code, by the end of that day, you must have some portion of some working software. Hard stop.

Six months of work won’t ever fit into a single coding session; however, if you don’t have a single portion of a functioning software, I mean what did you spend your time doing?

Sitting at the computer, physically writing code is only a fraction of the time. The other portion is called planning — and, it may be quite involved. Spending time with your colleagues to digest system requirements is fundamentally valuable time to determine your best approach for building a software system.

Remember, the goal of the system is to generate revenue for the business in some way.

By the time your plans are in place, you and your team must take the time to break down the work into small chunks. By sizing work appropriatley, you’ll increase your team’s ability to deliver. If each task can’t be completed in less than a day, the tasks aren’t small enough to be worked on.

In our experience, this is by far the most effective and reliable way to ensure that all time spent coding is productive and value producing. As long as you’re producing value on a daily basis, generally, client relationships should be easily maintainable, and there shouldn’t be much conflict.

Never manage to a failing goal.

It’s just that simple. As soon as you take $250,000 for a six-month project and plan to deliver the software at the end of six months, without frequent successful value delivery within the first week of adding coders to the project, red flags ought to be going off.

Setting up the underlying infrastructure to support value delivery

Getting from scratch to a fully operational CI/CD system capable of scaling up to hundreds of thousands of users will take months: It necessarily requires a feedback loop to improve. Before you go asking your contractors to build you this sort of ecosystem reliability, be sure to ask yourself: “Do I have hundreds of thousands of users? How many users do I have right now? How many users will I hope to have in a best-case scenario, six months from now?”

Any improvement that is made to a system away from the system’s constraints is an illusion.

If the best case scenario is you’ll have 100 users, then you should forget about your non-existent scaling issues. You can solve your scaling problem when you have a scaling problem. Paul Graham says to Do Things that Don’t Scale. If you need bank-level security, that’s great. Does your software do anything yet?

Bank level security is not a feature if you don’t have working software. Start at square one, not square nine. Once you have a fully functioning system, then you can start to work through security and scaling. You don’t even know if the software team was able to build what you wanted yet. Would you rather have bank-level security and a non-functioning system, or would you prefer a functioning software system that needs to have its security upgraded before launch? Trust us; you want the later.

So, if as a client you can’t understand that, then I’m sorry, I don’t know how to work with you. We won’t be successful, and although we’ll make some money on the project, it is a waste of everyone’s time.

Time is the only thing you can’t buy.