Unlocking the Power of Custom Software: Building Tailored Solutions

foreign [Music] [Music] ER and Welcome to our Helix Insider podcast I'm joined in studio today with three of my team uh senior developers Sam Sheldon senior developer Andy Webster and our Senior Systems engineer Sean coover hello everybody today we want to talk about custom software development and how it can benefit you and improve your company's productivity by considering a custom application here at triple helix we make custom software applications for our clients all the time as a result of not finding the right size right fit and sometimes having something custom made is actually a huge Improvement to a company's workflow and productivity so um I wanted to start with you Andy uh where when we do a project like this how do you prepare for a custom project well um usually we start with um a spec so um you know we would have some specification of uh what the project is supposed to be and really the more detail that is the better for the project because the more we know how the more

we know what you need and the very small details and you'd be surprised how how uh how detailed things get um the more detail you can provide the better um in up front because if we provide a vague detail in the beginning and then kind of um pin down things later going on it usually means doing things over so um when we when we have like a really clear picture of this is what we need to do right off the bat and this is and this is kind of a guideline of how we're going to accomplish it that makes for the best um the best Trail to Victory yeah yep yep makes sense Sam how about yourself how do you prepare for these projects yeah so like Andy said starting with the spec is important um one thing that I always try to get a sense of from the customer is what their process is currently because I know that a lot of the time when we get you know requests for custom software will go to a customer and they'll say yeah we don't like our current process and we're going to revamp it and this is going

to be the first step of that and that never seems to turn out quite like they want it to I assume because it's too much change all at once you've got a bunch of people used to doing things a certain way whether that's with Excel spreadsheets or on paper or whatever else their process might be whiteboards things like that um what I've found is it's important to look at what the process that they have currently is and try to match that as closely as possible while also getting a sense of where they'd like to go because that means we can build something that's flexible enough that if their process changes to something more streamlined or to include more features that we can give them that it's a smooth transition rather than as Andy mentioned having to rework things because reworks cost a lot of time and energy and there's always something some little thing that goes wrong and gets forgotten that's a good point um you know you touched on a very excellent point where you know we are relied

upon by our customers to create a specification that fits their need and very rarely is the customer writing that specification for us but on a rare occasion a customer will actually be able to do so and Andy tell me about a time where we had one of our customers who really knew what the process of this was and how they handled giving us their spec yeah I um I it's a specific customer that um I'm thinking of that uh is always very very detailed in their specs and um I really appreciate that it makes things a lot easier because it takes the guesswork out of um you know you read um I can't even think of a phrase right now but you're thinking you read a phrase in the specification and it seems kind of vague and you have questions about it but in this case you just read it and it says this will do this you know this will um not let you save unless this form is filled out or or whatnot and then they have all the specifications just lined up for you it actually makes a really big difference

because that means less time back and forth um trying to hammer out all the details so because the more the more that um the more work you put into it as a customer um initially the better the results really going to be because we're going to have a better idea exactly what you want and um and you know you can you can still fudge things around a little bit after that because sometimes you don't really know what you want until you actually get the paint on the canvas but um yeah it's um that particular customer uh always provides just really really detailed specifications and I feel like that is part of why their product turned out so good yep and that's fair I mean like the best customers of ours I can provide very succinct details of what it is they want um usually get a much better product at the end of the day so we talked about now getting ready for a project now let's talk about diving in Sam talk to us about what it it's like now that you have your specification in hand what's the

what's it look like when we actually formally dive into the application and start creating the code yeah so usually our first step is we have you know our standard template for starting a project we've got tools that we use thing Frameworks we install things like that we get that you know basic layer laid down and then we usually start we you know start with a big General feature and then we drill in on that feature and work through that and usually until it's done and then repeat with the next feature and the next and test as we go things like that um sometimes there are some projects that are a lot more interconnected where we have to do a whole bunch of different parts of it all at once um those tend to be the ones that are really complicated like full applications rather rather than the ones that are just we need an extra reporting layer on top of our existing Erp yeah it kind of depends on the project how we get started because reporting layers on top of erps are very different than

an entire you know application that's meant to support your process from start to finish right good point and and I know a big part of our our diving in and getting started is related to not only the software itself but the environment um that it runs in and I know you Sean are a big part of our team and making sure these environments are stood up correctly and actually configured correctly um tell us an example Sean about what project you worked on uh we're having all that in play made a huge impact for the customer uh well we have a a manufacturer Factory uh has a lot of sensors in their uh manufacturing plant and uh we designed and developed a platform to uh take all the data from Those sensors and aggregate all that data and uh combine them into one database this is a OED or operational equipment Effectiveness or also referred to as iot Internet of Things is that correct yes correct OT correct we but we also had to design and develop a uh platform for a server to aggregate all of that

data and provide that to the custom application that we built for the customer as well uh the the architecture and the uh the the platform that the application is built on and the the this the container and the server that it's on is a big it is very important in my opinion what is it yeah that one was very very impressive because I mean there are a lot of software platforms off the shelf that you can purchase that will do this for you but they are extremely expensive uh both from a setup and a maintenance standpoint and this particular customer uh was looking to not use one of those custom or rather off-the-shelf systems and because we had already developed a fairly robust reporting platform for them they wanted to hook in and I remember your input with this we were basically taking the sensor feeds off of the floor uh with specific Hardware uh and then wrote the architecture to allow us to uh contain that and then of course reconnect it to the application stack because there was multiple

multiple touch points not just the sensor Hardware but other reporting and whatnot we did that was a very impressive project yeah yeah I I had a lot I had a lot of fun with that it's a it was a good challenge uh getting all all the sensors all aggregating into the the through the wireless gateways and um and getting it all aggregated into the server uh we've got a a big database that's that's rolling for it and um it the reporting portal that we built for them is is um is pulling data from that database this is a very good example of where a custom software application was really what this customer needed the off-the-shelf hardware software Stacks were going to be very cost prohibitive for them and quite frankly may not have even worked exactly what they wanted so yeah that was a really good job Sean um now I want to take a pivot here and talk about we've talked about how we set up for a project and and get things ready the specification and the server environment we talked a little bit

about diving in and actually doing the work itself but now I'd like to talk a little bit about how we actually wrap up so when a custom software application is is deployed what does it mean to have that application continue to function properly uh and and get support as the customer takes ownership of it and Addie I'll turn back to you on this one is is what do we do when we wrap up and do a final delivery yeah so typically what we do is um we'll set a date for the release and we'll get all our scripts prepared all of our stuff if there's any data to migrate over we'll have that all ready to go and uh usually the client will specify a time of day that they want um get to happen at every everybody will get out of whatever applications that you know we're migrating data from any kind of stuff like that and then um we'll launch the application and um typically be right before that launch we'll have like acceptance testing so um you the uh will have like a beta test so all that that's where

like a larger group of people will come into uh the the software and like behave as if they were doing their regular business activities um that they would expect the thing to do and if that passes then we will release the software and we'll be kind of on standby on release to um if anything acts unexpectedly to get any bugs things like that um usually as like any soft really software release anywhere this always happens um you always have something that there's always something that nobody that nobody thought about it's usually not that big but um you know and then we'll we'll jump in there and uh fix those things up really quickly and um and then as time goes on those things will be less and less and it'll be more like maintenance in the sense of um if uh if any kind of thing is not behaving the way it's supposed to um you know open a ticket with us and we'll we'll fix it or if they want to extend it then um we'll open a ticket and add something new um but yeah that's that's pretty much

the process the go through really soon um Sam you've been involved in quite a few wrap-ups and um I'll let you tell me about a time where um the production launch and and basically hand off to the client didn't quite go as expected and what we had to do to remediate that and get them on the on the right track yeah so I think maybe some time ago we had a project that after a lot of development finally launched into production we've done a bunch of testing with the users it was you know we were all pretty confident this is going to work so we get it launched and then they start doing their financial reporting through our um through our software and they realize something's not adding up quite right so they call us obviously in a panic something's wrong and so we had to go through and figure out where where the problem originated from what you know what specific part of the financial reporting wasn't working correctly um and it actually ended up being a case of they had requested a specific

thing planning to update their processes um after we had gone live but of course over the course of development plans change and this was forgotten about so we had to go through and rework some things within that reporting to ensure that their old process their old methods still worked and I believe eventually they did update things to the way they had planned but it was still very awkward and required a lot of you know a lot of very quick bug fixing at the very end of that project I recall it I recall it a specific way where like they had after a year of testing not actually caught this particular feature bug uh inconsistency and it was one of those hair on fire moments when you launch and this is a very large lift for this company so they had quite a few people doing the uat for the live production launch to make sure everything was working right and then that moment where they were like oh no we realized we didn't tell you you were supposed to use this set of instructions and then it

was like you had within the context of a few hours hair on fire fixing everything that was a great and curriculum if I remember yeah it was it was definitely hectic it and it's fully possible to miss things in testing because there's there's functions of your business that you don't think about outside of tax season or outside of you know when you do a specific type of audit or whatever there's a lot of little things that you don't think about when you're just looking at your daily processes and of course Depend and if it's not something you think about very often when you're doing your user acceptance testing you may not even think to go test it because it's not something you think about every day unless you're doing the user acceptance testing during that one specific time right so so our Senior Systems engineer Sean coover we also like to refer to him as um our our battle Sergeant because he just takes care of all of the problems on the servers and Sean love to hear from you give us

an example where um did a launch and the lift has been made and then all of a sudden something's horribly gone wrong and what we did to remediate it especially on your end on the server side because if something bad is going to happen it's going to happen on the server and the configurations right right right yeah you're you're definitely right about that um I I'm trying to think about a a client where the the deployment with the configuration went uh um all all wrong I I could think about um One One customer who was using a I guess they were they were migrating their website to it to a new platform and they required two different servers and uh uh the originally we had only spun up one server with one platform but uh after that um we realized that we had we need a separate server for another service and we had to quickly spin that up and get that up and running for him how much time did that take us um we deployed the the the website the uh online uh shop um and within I would say two

to four hours we had the second server all spun up and and ready to go it was a hair on fire moment yeah and and this is speaking to the to what happens when you do your lunch all best plans intended but they don't necessarily go the way you want and I like your example because I remember that particular client um you know having the Redundant solution able to be spun up that quickly against their production environment this wasn't like us putting it back into development and and shutting everything off it was like they were live and they needed this other service stood up so that kind of speaks to like your ability of spooling up these servers quickly in the pipeline and the tools that you've created to do so yeah no that was very impressive like thanks Chuck yeah I really I really enjoyed developing and designing the uh the server platform that we're using right now with at triple helix it's it's really fine-tuned for the applications that we uh we developed for our our clients and they're

really uh they're really customized we have a a base image but uh each application as custom as the as they get the image itself is going to get that custom too so uh we have a base image and uh some great architecture and we we can just dive down from there right so that speaks to the idea of custom software development as a whole you know like a lot of people think custom software development is costly and very uh labor intensive and what we hear at triple helix have done is we've tried to take that labor intensiveness and costs out of the equation by standardizing standardized application Stacks standardized server standardized processes in fact right from the beginning as we started this podcast the specification is key we don't know what you're going to build or how you're going to build it it's going to actually create a problem for you not just the client but actually for us as well the development team so um well I think that's almost all the time we have for us today for uh the

Helix Insider podcast but just before we wrap up like to get some clothing cuts from everybody um Andy um closing thoughts yeah um be specific as possible I would say and uh and clear and constant communication is is uh is the best way to get the uh the best product in the end yep agreed Sam closings off yeah so Andy's correct that being clear and consistent is a good way to get what you're after I'll add that the that when you're developing a custom software Solution that's maybe not the time to be aspirational about changing everything at once it's hard to change everything at once start with what you know have us develop something that fits with what you know and let us know where you're going so that we can plan to eventually get there good point good point uh Sean final thoughts uh yeah speaking on uh what Andy and Sam spoke on first uh having a specification is is amazing if you know what you want um then we we can definitely design and develop the not only the code but the architecture

that supports the code and detail that's going to really support it all uh and then um having clearance consistent communication for what's What's um you know or what you what you need going forward and making these changes in phases instead of uh having it all change it once so that you can step into all the changes yeah absolutely um so you know I'd like to invite our listeners if anyone is currently experiencing a roadblock or or it has an idea for an application that would help their company uh would really um love to chat with you please put the your feedback in the comments below or also please feel free to reach out to us um we're on the web at uh www.3xcorp.com that's number three x like x-ray corporation.com uh also 860-490-3488 we'd love to hear from you uh this is Jason Bender from our Helix Insider podcast and I wanted to say thank you to my guest Sam Sheldon Andy Webster and Sean Cooper for their great insights on custom software development until next time thanks everybody

foreign