Developing software is never an easy task. It is surprising how long it can take to develop something as simple as a click, especially when it comes to developing software that’s dedicated to making construction estimates as accurate as possible.
Jon Bowser, Head of Development at Beck Technology, talks about what goes on behind the scenes during the development process of DESTINI Estimator construction estimating software and DESTINI Bid Day bid leveling software in the webinar below, giving you more insight on why we do what we do for the construction industry.
Q: What are some unique challenges when developing software for preconstruction?
John: One of the biggest challenges that we have is the same thing anybody anywhere has. One thing I think we all take for granted is what we know today. Once you’ve established yourself in your career, you slowly forget everything you didn’t know you knew when you came right out of school. I think it’s fair to say that applies to all of us.
As a software engineer, you’re taught how to write code, process problems, develop algorithms, all those things people typically think about when somebody says software engineer, but what they don’t teach you in school is how do you apply all those things to a specific industry. They all have different problems; they are all trying to solve different things and accomplish different stuff. School can’t really teach you about those things and so that is the biggest challenge for developing software for any industry and preconstruction is no exception.
The upside is that the more you’re exposed to the industry, the more you understand and the better you apply that knowledge you gained in school.
The next biggest challenge is closely related to that and that is to approach problems from the right perspective. Engineers are super smart people. They have a lot of tools in their toolbox for looking at problems, breaking them down, and solving them.
But sometimes it really easy to get caught up in applying your own perspective to the problem and not really realizing that the world doesn’t necessarily see the problem the the same way.
It goes back to better understanding the industry and the users.
Q: Has there been a specific instance where you or your team were focused on something that you thought was a big issue in the industry but then our clients let us know they were focused on something completely different?
John: It’s not usually in the big things. It’s usually in the small things. If you think about it from the software engineer’s perspective, obviously the end feature doesn’t start out finished. There’s a lot that happens from it doesn’t exist to it does exist. There are many things that go between there around testing, making sure that the workflow looks and feels right.
Things that as you’re developing the software you might run through this step a thousand times and you might all of a sudden you start thinking ‘wow! The estimator is going to have to do this a thousand times. I’ve got to change the way this thing works or change this workflow, make some tweaks to it,’ when in reality, I know the estimator is going to do this once maybe two or three times so when you lose sight of the fact that your hitting whether their challenges or mouse clicks or workflow inefficiencies, a lot of times you hit those in development and they are just purely made up in the sense that you’re still developing the way this is going to look and feel and it’s not really how the user is going to interact with it.
Q: For people who join the development team as new software developers for Beck Technology, is there a process that you go through to help them get more industry exposure?
John: Yes, and it’s an ever-changing process. We’re always trying to find better ways of doing it. We have training material that our clients go through that we also send our developers through. We work with our Services team to try and get hands-on domain exposure to the new hires and even people who have been doing it for years are always getting exposed to something new.
We work with our Services team to better understand what our clients are doing, why they’re doing what they’re doing, why things are important to gain that domain knowledge.
We go through training on LinkedIn Learning or other learning tools. We read websites. We read books. We talk to users a lot. We have a number of users who are so passionate about the industry and so passionate about helping people understand, including us, that they will take time out of their day to explain to us why they are doing what they are doing, why it’s important, and how it impacts the work.
We also have had the opportunity to embed ourselves, software engineers, as actual estimators on live jobs and participate in those workflows—doing takeoff, building the estimates, doing the bid leveling. So, whenever we have those opportunities, we also try to run our engineers through that in real-world exercises on real jobs that have real ramifications for things that go well and when we make mistakes.
You get a sense of urgency, a sense of the pressure that an estimator is under and I think that’s one of the unique things about Beck Tech is that we have that opportunity because we have such a close relationship with our clients that we’re able to do those types of things that other software companies don’t necessarily have.
I think a lot of folks can talk to users but how many can say they got in the trenches and actually worked on a live job with them? It’s probably a pretty short list.
Q: Client feedback is so critical to this process. Are there other avenues that development uses to bring in that client feedback or to provide clients with an avenue to offer that feedback to you?
John: We have a number of ways. We have our Beck Tech Community. We have our support line. We have our Services team constantly interacting. But aside from those normal ways, really every touch point we have with a client is an opportunity to get that feedback.
Our clients are always thinking about how to make the product better for themselves and for their team, and even the industry. So, for us, every touch point is an opportunity despite the formal channels. We are very much driven to make sure that we’re doing right by the industry, we’re moving the industry forward in a way that makes their life better and makes the world a better place for everybody.
Every chance we get to talk to somebody, whether it’s boots on the ground or all the way to the top, just getting that feedback from them and how can we use that to make the product better.
Q: I love the fact that there’s this ongoing relationship with people in the industry. Even a casual conversation that started out as catching up turns into ideas to reduce the time it takes to do an estimate by fifty percent.
John: It is a big part of that relationship and communication. A lot of companies will have those formal avenues for receiving feedback and there are a lot of times the only touch point the client really has with those companies is they want the software to do XYZ.
The problem is we’ve all been in this boat where we’ve been working on something and we hit a challenge with an ‘if only I could do this, it’d be a lot better.’ Oftentimes when me make those kinds of decisions in the heat of the moment, we’re really just addressing a symptom and not the underlying root cause.
So, for us, by having that tighter relationship and not just these formal, rigid, end-of year enhancements that make it into the software, by having more constant interaction and communication with our clients and users, we are able to put the enhancements to the side for a little bit and just have the conversation about what’s really happening, what’s the problem we’re trying to solve, why is this solution important to you.
If we can really dive into that root cause, find out what happened to get you where you’re at now to where you need this new feature, we can solve the problem better. Instead of making a solution here, if we can address something four steps back, it can be an even better solution than what was originally thought.
By having that tighter communication, that better relationship, we can ultimately create a better solution and not just focus on the symptoms.
Q: Your team is in the process of getting out the latest version of DESTINI Estimator during a huge crisis that’s impacting the way that a lot of our clients’ work. Have you hit any unique roadblocks during this time?
John: We haven’t hit any roadblocks. I think compared to other industries, as developers, we already had processes in place for people to work from home, to work remotely, so for years we’ve been able to refine our process and better utilize our tools, introduce new ways of communication that really facilitate that remote environment.
This is the firs time the entire company’s gone remote, so we had similar challenges I think that every other company out there has had but at least we had a pretty good leg up that at any given point in time, half of our development team may have already been working from home, so for us it was just doubling down on a process we already were doing.
The challenges we’ve hit around everybody being remote are fairly similar to what everybody else has. When you can’t leave the house, it is really easy to just wake up, immediately go to work and then the next thing you know it is seven or eight o’clock at night and you’re still working.
You have to do things to make sure that you and your team aren’t getting burned out because that just isn’t sustainable. There are times when working that long is necessary but to live that day in and day out can definitely wear on you.
The other part, the less obvious one and the more subtle one, is when you’re in the office you’re having a lot of interaction with people that's not necessarily nuts and bolts, 100 percent I'm typing away to keyboard to solve a problem. There's that softer personal side of things. We all have relationships in the office. We all have these personal connections with people that we see and interact with every day and those interactions can help break up this day where you would otherwise sit down at your computer at 8 o'clock and then not get up from your desk till 5:00 or 5:30 or something. Without those touch points it can be, and again, real easy to get burned out and even worse you lose that culture that your company has built, that they thrive on.
It is important to make sure that we’re doing things to interject those personal touch points in our days and not just asking our coworkers questions but really sure we’re connecting with people on a personal level and making sure they are doing okay.
Q: To wrap things up, what do you think is the most important thing for an estimator to understand about the development process and vice versa. What's the most important thing a developer should know about an estimator’s biggest priorities and their workflow?
John: I think the biggest thing for an estimator to understand about the software engineering perspective is we're going to ask a lot of questions and honestly, sometimes, questions are just out of ignorance and it’s just making sure we understand and know why people are asking what they’re asking and how it’s important. We just want to make sure we’re solving the right problem.
We don't just want to bolt something on that addresses the symptoms, so we're going to ask a lot of questions and it can sometimes seem like we just don't know what's happened or what's going on but really we are just trying to really dive into understanding the core issue and for the software engineer to understand the estimators.
It's really looking at what are we creating and making sure that we understand the problem we're trying to solve and making sure that as we're creating it that we're solving it in a way that makes sense for them.
Engineers, estimators, everybody thinks differently so what works in one person's workflow may not work for somebody else. Knowing that we're building tools for the preconstruction industry we need to make sure that when we are creating these solutions, we're approaching it from that lens and to make sure that this makes sense for preconstruction, not for a software engineer.
Beck Technology’s development team is focused on providing you with a tool that introduces efficiencies, is very flexible, and that can adapt to what your specific department is doing.
