This is Part 1 of a three part series on "What to Expect When You're Expecting (Software Development)." Stay tuned for Parts 2 and 3!
Software development is a complex space, and can frequently be very overwhelming. If this is your first time expecting software development, then this article is for YOU, more than anyone else. Read along to learn about three concepts you should expect to come up during development. If you've been here before, still take some time to read through this, as there may be some new details to you that weren't outlined for you in your previous experiences.
At Aloa, it is our goal to ensure you not only are provided with a guided experience, but that you understand what comes with this journey. Thus, it is important that we outline what to expect and prepare for when jumping into the custom software development world. Sit tight and read along!
Understanding Technical Debt, Third Party Limits, & Bugs
As a new member of the Aloa Family, it is our goal to ensure that you are well prepared for your project. It is our responsibility to ensure that we've done all we can to help you know what to expect during development and not be blindsided by anything. A key step in this preparation is building proper expectations for your software development experience.
There are three main concepts in software development that are very important for you to understand: technical debt, third party limits, and bugs. We will explain these concepts with the analogy of writing a research paper.
Technical Debt
It's your senior year and you have your final thesis waiting for you. You know your topic and what argument you want to take, now you just need to write it.
One extreme: iterate quickly
There are two extremes in approaching how to write your paper. On one hand, you can begin your paper with bullet points and keep iterating on each point to eventually write out your full thesis. It starts rocky, but you can build the meat of the paper very quickly and flesh it out later.
Pros:
- Quickest and easiest way to write your thesis. It takes the least amount of time, effort, and stress to get something on paper to start generating feedback.
- Your paper will still be functional. It will serve its purpose and the reader will conceptually understand the paper.
- It is super quick to go in and make edits. You can edit paragraphs or sentences independently and don't have to worry about, for example, APA formatting. It is the easiest way to iterate.
Cons:
- The paper lacks depth of understanding from the start. The concepts are there and it works, but the bullet points you began with may not always make sense alone. It requires iteration.
- You may not begin with complete sentences and structure. This means you will have grammatical, syntax, spelling, etc. errors in your paper that you are bound to have to fix at some point.
- It isn't a perfect paper from the start.
On the other side of the spectrum, you are writing in picture perfect form from the start. As you start paragraph one, you write it perfectly, following the right format, spending time crafting your sentences etc. You get your first paragraph peer reviewed and make the necessary edits before moving onto paragraph two.
The other extreme: make everything perfect the first time
Pros:
- You're about to write the best damn paper you've ever written in your life.
- It will be really easy to expand upon, add details to, and build in new arguments/topics.
- It is very thorough; you can read it from any view/perspective and it will ultimately make sense and work well. The paper works, no matter what angle you approach it from.
Cons:
- My oh my, grab your coffee and block out the next months of your life. With each sentence you write you are reviewing and re-reviewing testing syntax and flow, etc. This is going to be very time-consuming and require a lot more effort.
- If you want to make an edit, it isn't going to be so simple. You need to make sure your edit doesn't disrupt the existing flow, follows the same logic of thought, etc. A simple edit might require you to read the surrounding paragraphs to make sure your argument still makes sense.
- Did we mention it is going to take a lot of time and effort?
Okay, so what does this all mean? In software development, the former approach is analogous to a lean, bare bones MVP (Minimum Viable Product) that you need to build and pump out quick to get users to start testing the functionality and proving the concept's value.
The latter is analogous to an enterprise-caliber product that is ready to take over the world and can withstand anything thrown at it. Your MVP is built with technical debt. The enterprise product is not.
What if I don't want to go to either extreme?
Together, we are going to discuss where you fit on this scale. If an MVP is a 1 and enterprise-level is a 10, maybe you want to be a 5, or a 7, or a 3. Let's chat together and have a conversation to understand where you see yourself fitting on the scale so we can discuss the trade-offs.
Technical debt is like any other debt: you'll have to pay it back somehow. As a startup, it commonly makes sense to build with technical debt. In fact, we strongly recommend it.
Since your focus is on speed, iteration, and getting the product in users' hands as quickly as possible, technical debt is not only your friend, it is a luxury that startups have and big corporations can't afford.
Even at Aloa, we build with technical debt in our platform for the purpose of ease of iteration. As you use Aloa Manage, you'll see that the platform works, quite well actually. Will you encounter some bugs once in a while? Sure. Will we squash them quickly? Yup. Can we respond to new feature requests in weeks instead of months? Certainly.
Ultimately because of our decision to build quickly and with technical debt, we can make quick fixes, and more importantly, pump out new features more quickly to keep you happier. As we grow, we'll have to continue to optimize the code to support greater bandwidth. Is that a bad thing? Absolutely not. It is paying back your debt. It's a beautiful growing pain and is faced by tech companies every single day.
Third Party Limits
If you've ever written a research paper, you know that you are at the mercy of various third parties. A common resource for research papers is online libraries, but if the online library suddenly has an outage or decides that you violated their Terms of Service that one time you pirated an article three years ago, you'll be left hanging without access to that library.
If you are going to be interviewing someone for a first-hand account, then you better be sure that person isn't going to change their mind. If the purpose of your entire paper is to be published and submitted to a specific journal, then you better be sure that you know the exact requirements that are needed to be accepted.
These limits apply to software, too
As we plan your software development project, it is important to take into consideration and prepare for the external variables that we may or may not have control of. If there is a third-party whose information you want to access, we need to make sure that what you're trying to do is feasible. By identifying all the third-party dependencies early, we can help you know what to expect as development proceeds.
For example, if you want someone to be able to login to your application through Facebook, we need to be sure that Facebook allows for you to access their API for this specific function.
Sometimes, third parties will change their limits/restrictions. For example, let's say you wanted to incorporate Spotify into your application so users could listen to songs from their playlists. You've done your research, called Spotify, and they gave you the thumbs up.
This is doable and all should be well. However, two months later, they changed their mind. Spotify updated the limits/restrictions of their API and your feature can no longer function as intended.
This is a super unfortunate situation, but there is nothing we can directly do for you there. You are building your platform banking on the permissions of a third-party, so that is a risk you must recognize.
How do I protect myself when I have third-party integrations?
What we CAN do though is help you brainstorm through possible alternative solutions or backup plans. Maybe we can incorporate SoundCloud or Apple Music instead of relying solely on Spotify.
Maybe we can have users upload playlists so everything is housed within the application. It won't be perfect, it won't be what you originally expected, but all we can do for you, as Aloa, is help you adapt and pivot.
Lastly, when submitting an application for review/acceptance, you again are bound to their discretion. For example, the Apple App Store has very vague guidelines as to what indicates a failed guideline adherence.
Why does Apple do this? It's so they can retain control and make an argument to reject any app they want from their store. While most apps actually get rejected the first couple times, with perseverance and adaption to Apple's feedback per rejection, apps commonly get approved.
However, there is always the off-chance that Apple will continue to reject the app for reasons we can't predict. This isn't an end all be all situation, as again, we can work to adapt and pivot. However, it is important that we articulate that some things we simply don't have control over.
Your Strategist is there to help you understand how all the moving parts will fit together for your product. There are lot of aspects we can't control, such as how long it takes Apple to approve a new version of your app, but if we know what to expect ahead of development, we can properly plan for delays and have backup plans in place.
Bugs
You've heard the term bugs. They're common. They're normal. Going back to the Research Paper example, a bug would be similar to the squiggly red underlines that Microsoft Word automatically identifies for you. Sometimes the punctuation is off and makes the reader gather the wrong understanding of the sentence.
Let's eat Grandma. — Let's eat, Grandma!
A woman without her man is nothing. — A woman, without her, man is nothing.
This is a bug in the punctuation, leading to the wrong output for the reader. So, the writer has to go back in and correct it! Bugs are incredibly common and aren't reflective in any manner of a bad coder.
In fact, Google identifies dozens of bugs per day in their programs. If you're lucky, some bugs will be found as you write the paper, and you can edit it yourself. Oftentimes bugs won't be found until your work is peer reviewed. Sometimes bugs won't be found until you publish it for others to see.
The more complex the paper, the more bugs there could be. Sometimes errors in writing (not following APA formatting or even grammatical errors) aren't picked up by Microsoft's auto-check, making the review/editing process a bit more challenging.
What is different with software, compared to Microsoft Word, is that software doesn't squiggly red underline any of your errors. So, all bugs found are either going to be identified by the developers during testing, or a user during testing.
When we find a bug, that is a good thing! That means we are getting closer to getting them all out of there. So, as bugs appear, don't fret, just log them in Aloa Manage so we can keep moving along.
What to Expect During Development: Technical Debt, Third-Party Limits, and Bugs
We hope we've given you a good overview of what to expect during software development. Not every project will run into the three concepts we've outlined above, but it's good to be prepared to encounter them at some point in your product's lifetime.
We don't bring up any of these points to scare you, just to prepare you. We'll develop a good technical debt plan with you, adapt to any possible hurdles that are thrown our way, and squash the bugs as they appear. Above all, we'll help you understand what to expect during development before you begin your project. This is just the nature of software 😊
This is Part 1 of a three part series on "What to Expect When You're Expecting (Software Development)." Stay tuned for Parts 2 and 3!
