This time around, instead of offering some advice or action items related to running a real estate business (I'm hardly an expert in that regard, anyway), I wanted to explore some of what goes into developing new functionality in the DeltaNET®. Specifically, we run into hurdles when designing the functionality before any technical ones even come into play.
We love to build out new functionality based on customer feedback and requests. After all, our customers are the ones actually using the platform and working in the industry it's meant to support, so they are the ones most likely to see its shortcomings or where the opportunities for growth lie. However, some challenges to this software development approach weren't immediately obvious to me as my role at Delta Media Group® changed from one related to support and training to one that is more deeply ingrained in the direction of the DeltaNET itself. Simply put, "you don't know what you don't know."
My time in technical support has made me deeply familiar with the concept overall. If you really don't know anything about an issue or a process that's having a problem, you don't even know what questions to ask to troubleshoot it. It turns out that the same concept applies to designing new functionality. For example, if I wanted to design software that simulates the flight path of paper airplanes, but I knew nothing about paper airplane flight mechanics, I wouldn't know what the software should take into account when creating the simulation. This is where the research begins.
If there is some existing software out there that does something similar to what I'm trying to do, I can start my research there. Not to make my own version of what they're doing (because what would be the point?) but to gain some insight into the context of the problem I want my software to solve. This isn't always an option, though. Sometimes, you are designing something completely novel, so there's nothing in existence with which you can compare. In that case, you move straight to the next step, and you consult an expert.
Software developers are experts in developing software, not necessarily the industry where that software is meant to be used. Therefore, they need to rely on the expertise of people that work in that field to know what to build and how to build it. It sounds straightforward enough, but in practice, that's where some interesting issues come up. It turns out that, in addition to not knowing what you don't know, when you're an expert on some subject matter, you often don't know what you do know either.
To stick with our paper airplane example (because who doesn't love a good paper airplane?), if you're out there designing and flying paper airplanes every day, much of what you do to make one fly well has become automatic to you. Suppose someone came to you and asked, what are the most important elements to consider when designing a new model? In that case, you might be able to point out the shape of the wing and the weight distribution from the folds in the paper immediately, but you've been folding in the tip of the airplane on every model for so long that it's become second nature. You then leave out that detail because it's just so obvious to you that it doesn't come to mind. This leads to version 1 of the software leaving it out, too, so nothing flies quite right. This is why it's so important to think through every element of a feature in as much detail as possible when designing something new.
Try as you might, but you'll never think of everything the first time around. That's why it's important to create things with as much flexibility as possible. And even if you do manage to think of everything the first time around when designing new functionality, times change. Maybe a few years down the road, a new kind of paper will hit the market that turns the whole paper airplane-making convention right on its head (it's a bit of a stretch, but you get the idea). We need to be able to account for those kinds of changes.
Even though many of our features and revisions come from customer feedback, unfortunately, not everything can make the cut. Keep in mind that something that sounds like a good idea on paper might either not work or not be particularly useful in practice. More commonly, ideas will come in that just lack insight into the bigger picture. It's a great idea by itself, but when it comes to implementing it into the larger platform, it either doesn't make sense or just doesn't make sense exactly as presented. In an ideal world, everyone would get exactly what they want, but when it comes down to it, leaving out some things will result in a more reliable and well-rounded system overall, to the benefit of everyone using it.
We have to make this tradeoff to have the best overall platform. So just remember, if you're one of those customers sending us your feedback and good ideas, even if we don't implement your idea, that doesn't mean there isn't value in it. Elements of your idea influence the platform and how we think about what we add to it. Also, consider it an idea that might not be a good fit today but could still become one in the future. We may never find perfection, but we'll never stop striving for it, either. And every idea, suggestion, or bit of feedback gets us closer. So, keep them coming.