Solutions-First Software Engineering

When companies have a problem to solve with software development, sometimes it’s tough to figure out where to start. The wrong approach can be time-consuming, expensive, and can miss the mark completely. We’ve worked with some of the world’s fastest-growing technology companies for the past two decades. Here is a tried-and-true approach to solving software engineering challenges.
Team looking over computer

When companies have a problem to solve with software development, sometimes it’s tough to figure out where to start. The wrong approach can be time consuming, expensive, and can miss the mark completely. We’ve worked with some of the world’s fastest growing technology companies for the past two decades. Here is a tried-and-true approach to solving software engineering challenges.

 

Let’s start with a key question: What’s the first thing you ask yourself when you have a problem to solve? I’ll give an example that’s not software related to simplify.  Let’s say the problem you need to solve is that it’s dinnertime at home, and you’re hungry. The FIRST step is figuring out the meal you’re going to make. The SECOND step is to pull together the ingredients you need to prepare the meal.

You wouldn’t go from “I’m hungry” to immediately assembling a random set of ingredients, right? Or (in an even more ridiculous instance) say, “I’m hungry” and then select only one ingredient. I think we can all agree this is silly and probably won’t result in a meal we will actually want to eat!

Let’s apply this example to software development. Why do people go from identifying a problem to immediately choosing specific technology or one programing language? They’re missing a critical FIRST step! It’s much more advantageous to first focus on how to solve the problem: what are the business requirements, what are performance requirements, what are the most important features to deliver first to make the most impact? Once these questions are answered, the SECOND thing to do is identify the best tech stack to use to deliver on those requirements.  

Typically, product teams skip step one and go directly to step two because they’re limited to the knowledge, they have on their small development team. If their development team is experienced in a certain tech stack, they are reluctant to select a different tech stack even though it could be a better choice for this solution. This happens because they don’t want to hire new team members or devote training time for their engineers to learn a new programming language.  

A good example of this was when one of our clients wanted a mobile chat solution for their customers. Up until that point, we had helped them develop on their existing Ruby on Rails platform. If we were a singularly Ruby focused company, we would have scoped a Ruby solution for mobile chat.

When all we have is a hammer, everything is a nail.

But Uprise isn’t a Ruby shop. We are an engineering shop. We took these requirements, took a step back from the clients’ existing tech stack, and asked ourselves, “How can we best deliver on these requirements?” The solution wasn’t obvious. Ultimately, we decided to white label and fork an existing open source mobile chat platform. This allowed a two-person development team to ship a mobile application in under two months while keeping up with existing platform work.  

At Uprise, we built our engineering team in a way that lets us completely address that first step – how do we best solve this problem and work within the given constraints? We focus on what needs to be built to provide the most value and solve the problem in a way that balances time to value and investment level. Our engineers are skilled in quickly flexing into different tech stacks depending on the need of the solution. Of course, some team members have more depth in some technologies than others, and we assemble teams accordingly, but the core philosophy of what we expect of all our engineers is that they are problem solvers first, and they have the ability to quickly learn the tools they need for a particular project. New technical skills are easy for our team to learn.

We aren’t a staff augmentation engineering team – we’re a problem-solving engineering team, and that’s why we have realized the success for our clients. We are solutions and engineering specialists. We work with you to understand your business needs and translate them into product requirements and deliverables.  We also work within reasonable constraints versus pie in the sky architectural designs that cost too much for what’s needed or won’t scale well.

If you have an engineering or software development challenge or opportunity, please let us know. We would love to help!

Ready to work together?

We're always looking for ambitious projects and great ideas.

More Articles