Setting Expectations in the Uncertain World of Software Development

07-25-2024

It’s been ages since I’ve felt like I had the time to write another blog post. Between the demands my personal life and my work, both within and outside of my day job, along with my desire to revise the site (hope you like the new look, will have an article on that soon), writing these posts has been placed on the back burner. However, going forward I plan to start writing at least one post every month on a technical topic, with the hopes of increasing that rate gradually to once every week.

What I did in the last sentence of that paragraph was a form of expectation setting, the topic of this article. Setting appropriate expectations is both extremely important and extremely challenging in the world of software development, even more so when working independently. Last year, I took on some independent contract work for small start-up and learned a few hard lessons on this topic that I would like to share here, so that maybe you might not have to learn/relearn them the way I did.

Expectation Setting from the First Interaction

Setting expectations early is critical to having mutual understanding with others. This is especially true for non-technical colleagues and clients. Over selling will set you up for failure and under selling will often lead to not gaining new business, lower perceived worth, and potentially even losing rapport. Try to be as spot on as you can from the moment you engage.

Resetting expectations is an up hill battle

Expectations are easy to increase, but far harder to decrease, with the reverse being true for the other party. Trying to go back on expectations or raise your expectation of another once you’ve already set one leads to distrust and dissatifaction that is often disproportionate to the impact of the change.

Murphy’s Law

Murphy’s law is a simple concept that is quite easy to disregard. The law states that “Anything that can go wrong, will go wrong.” If you could get sick or have other engagement can could get in the way, which is relivent to literally everyone, plan for it as much as possible. If you rely on a cloud provider with 99.999% availability, expect that that 0.001% will happen at some point. Literally, anything you can think of that could go wrong, probably has a higher chance of occurring than you expect. Include them in the expectations that you set with others. And please, use version control and push your code somewhere other than your computer at least once a day. Hard drives fail and liquids exist.

Don’t be afraid to say “no” or “let me get back to you”

Sometimes a deal just doesn’t make sense. Especially in the negotiation process, make sure that you are satisfied with the agreement. If you are unsure, take your time and get back to them. If the deal doesn’t work for you, counter offer or turn it down. I definitely should have done this early on in that engagement when there was a substantial misunderstanding about the financial aspect of the contract.

Expect Scope Creep

There is a good chance that the product owner will desire more work done that is clearly defined. Leave room for some of this to saftify the business needs, but push back when it could be a detriment to the overall timely success of the project.

Overestimation is better than Underestimation

If you think that you’ll be able to complete a task in a week, give yourself three. Something will eneviably come up, the code won’t compile, or you’ll have an issue that AI and StackOverflow can’t solve. Give yourself room to breath. I absolutely underestimated some aspects of the project, not on it’s difficulty per se, but absolutely on the time it would take and the change requests from the client.

Do not commit to deadlines without discovery and clearly defined acceptance criteria

Honestly, deadlines are the enemy of anyone who has them. Unfortunately, they are a necessary evil that is often unavoidable. Before committing to a deadline, understand the full scope of work and make sure that you are fully aligned with the expectations from the business. If you feel like you need more clarification or don’t believe that the deadline is reasonable, then no not commit to it and suggest alternatives.

Prefer hourly and upfront payments over milestone pay structures

This is a big one. Milestones might seem reasonable on the surface, however, there is a level of uncertainty that shouldn’t be underestimated. Hourly rates ensure that you are compensated for the time that you put in and upfront payments have the benefit of scale, which is often undervalued, i.e. almost everything cost less when you can pay for it upfront, removing debts today prevents interest tomorrow, and proper investment of funds gains interest.