Have you ever wondered why software takes so long to build, why it costs so much, and why it always seems like a lot gets done really fast, but then things seem to slow down as development continues? As a senior software engineer with over a decade of experience, I answer these questions for our clients because if I were in their shoes, I would want to know the answers myself! Anytime I make a large purchase, whether it’s for a service or a consumer item, I try to do as much research as I can - but at some point, you need an expert in the field to help you understand how it all works. That’s what we’re doing here. I want to help you understand some of these “tough to answer” questions when it comes to creating software and to help us, we’ve created something called the Wobble Diagram.
The Wobble Diagram aims to answer three questions:
By the end of this post, we’ll answer all of these questions - but for now, we need to explore how the Wobble Diagram works. The Wobble Diagram is named as such because as a software application is in its development and early release stages, it needs to be supported by what are called “stabilizers,” or else it will “wobble” due to “threats.” For an application to be deemed successful, it needs to continue growing until a certain “threshold” is met.
We just dumped a handful of buzzwords on you, so let’s pause for a minute to explain what everything means.
Wobble - Wobbling refers to an application failing to grow, and thus failing to generate more business value - which nobody wants to have happen.
Threats - Threats are external factors that can stunt your application’s growth and cause problems - and if bad enough, cause irreparable harm. A threat could be something giant like a hack that destroys all of your data, or as mild as a slow web page that you wish was a bit faster.
Stabilizers - Stabilizers are what keep your application from wobbling, and as your application continues to grow, so do your stabilizers. Stabilizers can commonly include concepts such as testing, security, analytics, addressing feedback, and more. In combination with your application itself, stabilizers make up the X-axis of the Wobble Diagram.
Thresholds - Thresholds are points in time of an application’s development lifecycle used to identify the progress of the application. Examples of a threshold that you may be familiar with could include early development, “alpha” / “beta”, or after an application has been released for a certain period of time. Thresholds help us visually understand how close an application is to reach a certain point of progress.
Now that we have an initial understanding of the key concepts, let’s see a full-blown Wobble Diagram in action:
It’s important to note that the Wobble Diagram doesn’t aim to show exact numbers or values. What’s important is how your application relates to other key data points in areas such as resources (such as time or cost) and progress, and that’s the focus of this diagram.
Seem like a lot? Let’s break down how we got to this point.
When building a software application, there are 3 main thresholds that Clevyr focuses on when assessing progress:
To describe these a little bit more: MVP needs to have enough progress to showcase the application as a whole, but does not need to be tested or prepared for release; initial release needs to be ready for everything, including handling average usage from users as well as protecting against nefarious behavior such as hacking; and lastly, we measure when an application is officially profitable, which accounts for all updated business requirements and needed modifications that are learned and/or prioritized after the initial release. Profitability here refers to business value, and not necessarily direct revenue; many profitable applications could be internal products that help support revenue generation for your business (i.e. think of a company intranet or an ERP tool like SAP).
At first, our Wobble Diagram will look mostly empty, aside from our “App” label (referring to our application) on the X-axis, and our visible thresholds.
For the rest of this post, we’ll create a case study for a web application called Flower Boss, which allows users to place orders for flower deliveries. Flower Boss will then tie the orders into a third-party dispatching system that will handle delivering orders to their designated addresses.
After having established our thresholds, our first deep dive into building Flower Boss is to build our MVP application. As time goes on, the developers build Flower Boss at a rapid pace. Both front-end and back-end work are going well, the three test users all have different roles that work well, and the ability to place orders through the prototype web application is nearly done. Within 1-2 months of starting initial development, MVP seems to be reached, and Flower Boss is demoed to the client. Everyone’s happy and wants to move full steam ahead.
At this point, our Wobble Diagram looks very similar to our previous version, except the “App” bar has fully reached the MVP threshold. The size of a bar in a Wobble Diagram reflects the number of resources (i.e. time/cost) used for the topic.
MVP was a breeze to reach - and we keep moving at the same rate as before, right? Yes, this is true - but this is where things start changing and become increasingly important to communicate to the client what forward progress will look like. It’s true that the rate of development won’t slow down - but as we approach the initial release threshold, there are other concerns that we need to consider besides just the core features of the application.
What if after the demo, the clients realize that something didn’t work right; maybe certain flower orders need additional fields in the order form, or maybe they need a user with a special role to approve and dispatch the orders or perhaps they want to be sure Flower Boss will pass a security audit so they can market that on the homepage.
Now we’re starting to get into threats - and if we don’t consider addressing these threats, then our application will begin to wobble as it continues to grow. As an example, let’s assume that Flower Boss continues focusing only on the remaining application features that were determined at the start of the application, and not on any of the new feedback from the client. Here’s that wobbling in action:
This isn’t good, and if left unaddressed, then Flower Boss will fail to continue growing - and will likely ultimately fail as a product. So how do we address these threats? We add some stabilizers.
To address the threats mentioned above, we need to stabilize the application with concepts such as “Security” and addressing real-time “Feedback” from the clients. While these stabilizers will help the application continue to grow, they are not directly related to adding in new features that were originally anticipated - and thus they won’t directly grow the application. Time is still spent on these concepts however, and time is dedicated to the stabilizers which will help prop our application up. After we spend time addressing security and feedback, our application will become stabilized:
Now let’s review why it’s important to communicate to the client here. We added stabilizers for “Security” and “Feedback,” and remember that the size of the bars is directly related to the amount of resources spent on those topics. For any client, whether outsourcing work to a consulting firm or developing a project in-house, time is the same as money - so it’s important to communicate that while the application itself didn’t grow, additional resources need to be spent in non-feature related areas in order to allow the application to continue growing, and this is expected. This is the start of understanding why the “appearance” of progress seems to slow down when in reality the rate of development is remaining the same; there are other concepts that need to be addressed for an application to be successful, and if ignored, the application won’t be successful.
Continuing on with our case study, the client is happy with our changes to security, new modifications from their feedback, and were also understanding of the additional resources needed for the application because we communicated to them early on. Again, communication is key here. Now while our application continues to grow towards the initial release threshold, realistically we will run into additional threats:
Without addressing these threats, our entire app including the current stabilizers will wobble:
But if we address these threats by spending time to increase our “Security” stabilizer and add “Testing” and “third-party integration” stabilizers, our application can successfully reach the initial release threshold:
We’ve officially launched our application! Did it take us longer to go from MVP to initial release than from the beginning to MVP? Yes, it did, and that’s how the process works. And if you think it will take us less time to become profitable, then I have some bad news to break to you. Once an application is launched, that becomes a “sink or swim” moment for the application. The fledgling applications without any support to continue growing will likely sink and fail to produce business value; however, the ones that are ready will be able to make that leap. How do you get ready? You communicate with the development team over your future goals and be prepared to collaborate in order to continue towards profitability.
All of this translates into growing your application, identifying more threats, and adding and improving stabilizers to support your application through those threats. The number of threats can be infinite, but some common concerns an application may experience during this phase are:
In reality, every application is different, and thus every application’s Wobble Diagram will be different; for Flower Boss specifically, once the application itself becomes profitable, it’s safe to assume that it’s final Wobble Diagram may look like the diagram shown at the beginning of this post:
In the end, while Flower Boss reached MVP status in 1-2 months, it may have taken 8 months or more to reach profitability, with only half of the time having been spent on the actual features of the application. This is why software takes as long as it does to build, and why progress “appears” to slow down throughout the application’s development. In reality, there was no speed loss - there was an assortment of other concerns that needed to be addressed for the application to be successful.
If there’s any lesson to gain from the Wobble Diagram, it’s that quality custom software takes time and resources - but in the end you really do get what you pay for. If you want a profitable application that conforms to your unique business requirements, then your Wobble Diagram will probably be substantial - but it will be a long-lasting application and easier to update when things change in the future (and they always do). On the flip side, if you need to be budget-friendly at first - then that’s absolutely fine, we can focus more closely on reaching a lower threshold such as initial release. Then, as the application naturally appears to become popular, you’ll have a better argument to increase investments into the project in order to make it profitable.
If you would like to create a custom piece of software and see what kind of Wobble Diagram we will build for you, get in touch with us through email or our contact form. We’d be happy to help you and learn about your vision!