Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
What do you think is an important skill to have when in a role or wanting to be in a position that requires making decisions around software architecture and design? There was a phase in the middle of my career that changed my point of view. I’d like to explain what is an underrated skill that I credit for making various technical decisions, including those around architecture and design.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Budget
This tweet resonated with me because there was a phase in my career where I created proposals, quotes, and estimates for software development projects. If we landed the work, then it was executing and building the software and the entire project lifecycle.
Understanding the budget, the actual costs (mainly time), while the project was being worked on was eye-opening for someone that never really thought about the bottom line.
Independent consultants that do project work will understand this however, if you aren’t exposed to revenues and costs, you’re likely oblivious to the bottom line.
Bottom Line
There are many ways to structure software development projects around an interactive design, change orders, value-based pricing, etc. I’m using a simple example to get the gist across.
Let’s say you are an independent contractor and provided a quote to a client for a software project. You’ve established some deliverables for some fee. How you came up with a fee (your revenue) was likely based on the number of hours you think it will take to complete the work, multiplied by an hourly rate.
40 Hours x $100/hr = $4000
So your fee for the deliverable is $4000, based on the assumption it will take 40 hours of work. What happens when the project ends up taking 80 hours? You still get paid $4000, but you’ve reduced your hourly rate to $50/hr. You’re affecting your bottom line.
This may seem obvious and trivial. It is. But most developers have little to no thought or insights into how their work affects the bottom line. Depending on your context, knowing how it affects the bottom line could be irrelevant. I’m not suggesting you absolutely must know. However, it could significantly impact your decision-making if you should be aware but and don’t have the skill as a developer to understand the trade-offs.
For example, if you’re working in a startup with a limited runway, time is of the essence. Making decisions and moving forward is critical. Bike shedding gets you nowhere. How often have you worked as a developer for a company, seeing people bike shed for hours or days over something that has little to no value? It’s just a waste of time.
I genuinely believe in Parkinson’s law and some of the corollaries.
“Work complicates to fill the available time”
The reverse can also be true.
“Work contracts to fit in the time we give it.”
Barber, Cam. “How to write a speech in 15 minutes”. Vivid method. Retrieved 11 November 2014.
If you have a task that should take 4 hours, but you only have 1 hour available, you’ll find a way to get it done within an hour.
Value
Why do thinking about revenue, costs, and time matter? Well, because it affects ROI. And my decision-making is often around ROI. As much as developers love thinking about code, tools, libraries, and frameworks, you’re likely writing software to provide value. Being able to make decisions around this is a skill as a developer.
If you’ve used Scrum and done sprint planning, provided story points, or done any type of estimating, someone else determines the ROI. Determining based on story points if something is worth implementing is the ROI is high enough. You won’t work on a feature that will take a long time to develop but has little value.
Technical Debt
When I talk about technical debt, I’m not talking about what someone thinks is crappy code.
Technical debt is an explicit choice.
You’re deciding to incur debt now so you can get further ahead, right now. That comes at the cost of needing to repay that debt in the future. In a startup, you often take on technical debt now, so you have a future. You don’t want to gold plate anything. You want to develop to “good enough” and move forward.
If you don’t have any concept of costs, time, or value, how could you decide to incur technical debt?
Join!
Developer-level members of my YouTube channel or Patreon get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.