An Interview with our Senior Developer Andrew on the Truckit Provider App

Interview with Andrew Erikson - Senior Developer at Truckit.net

How did the idea of the app come about?

I think the idea for the App may even predate the Website actually. No, I'm exaggerating just a little.  But it really wasn't long after the Website launched that talk of doing a Mobile App began. I think it was pretty much self-evident that that’s where things were headed. Smartphones changed everyone’s lives… which demanded that Truckit step up and produce, not just an App, but a top-notch App.

Had you developed apps [like this one] previously?

Well, I've been involved in the Development of other Apps, but certainly nothing even remotely close to this one. I think that is just a reflection of the level of bespoke functionality that Truckit has acquired over the years that has made it so much different from everything that came before, certainly in my experience.

How is this app different from others you have done?

The main area that in my experience has set this App apart from others I would have to say is the intricacies and permutations of the User Interfaces, which are required to support several distinct workflows and User Experiences. Truckit is very unique in that aspect, and this has made it quite different to other types of Software I've had the privilege of working with over the years.  Besides this, there is also the technology aspect that was new in that we chose to work with a technology that up until that point we had little experience with.  All of this has since changed of course.

Can you discuss the agile methodology of software development and talk about its advantages and disadvantages?

Using the Agile methodology has enabled us to adapt and change as the project has progressed and made it possible for us to respond faster to requirement changes and overlooked or poorly designed features that are not obvious at the outset. But this usually comes at the expense of being able to apply more time to the documentation process which can have a detrimental effect over the longer term. It can also be frustrating sometimes to iterate multiple times over the same feature until such time as the stakeholder is happy with it.  So there definitely are positives and negatives. Unfortunately, if you are dealing with a project where the full scope of requirements is not yet fully understood, and this was certainly where we found ourselves at the beginning, then Agile is the only method available to you really. The most important aspect of any software project is the ability to adapt to circumstances and understand that what you are dealing with is very often a moving target. Sure, you might settle on all the features to be included in a Version 1, and then a Version 2 after that and so on, but we all know it often doesn't stop there. Versions can be open-ended depending on the success of the product, so I think it’s good in some ways to try and view a software project as a journey rather than a destination, with fixed resting points that define the boundaries between versions. When you look at it like this, and utilise it in this manner, then I think the Agile Methodology makes a lot of sense and the advantages outweigh the disadvantages.

What were some hurdles you faced, and which was the biggest hurdle you faced during the creation of this app?

There were several hurdles that revolved around deciding what Architecture to go with, but I would probably say the biggest hurdle of all was actually deciding what Technology to use, because I mean, there are so many options out there really. The classical approach to this question may entail reviewing the development skills available to you as a manager, and then making a decision based on this. That is not the approach we took.  In fact, we completely put available skills to one side and focused on the pros and cons of each technology independent of other factors, and we continued doing this even after we had started the project. In fact, we made what I would refer to as a 'course correction' a few months into the project after we evaluated another technology that had up until that point been off our radar. The fact that we were prepared to make a huge U-turn like this as far into the project as we were I think emphasises just how important technology choice was for us in the end, thus making it our biggest hurdle, definitely.

After overcoming these roadblocks, how do you think overcoming these issues changed the final product?

I would certainly hope that after each roadblock, the end product would be better. If not, I guess it would make those very roadblocks pretty pointless really.  So, roadblocks are a really good thing, and it’s important to try and frame a roadblock as positively as possible. One could take a 'glass half empty' approach and say, "oh well, you know... there is just no solution to this, so let's rather just drop the feature entirely". That is obviously not the approach we here at Truckit, take. Quite the opposite. We welcome roadblocks.  We thrive off roadblocks. The challenge of solving a Roadblock is what gets us up in the morning. So, coming back to your question, I wouldn't necessarily say overcoming roadblocks changed the product, but what I would say is that it changed those involved in the product rather, by giving them a sense of confidence and pride in their own abilities, and this I think will stand them in good stead for the future of their careers, as well as the future of this product hopefully.

Can you discuss how you balance addressing client demands with developing complex application software?

That really is the Holy Grail that you have touched on right there... finding that balance. It all comes down to the search for simplicity, and simplicity for a client or user vs a developer can often mean polar opposite things. The more demanding the user requirements, usually the less elegant a software application becomes.  Client demands definitely take precedence though.  From a software perspective you need to exchange customer for user in the cliche 'the customer is always right'. So, the user is always right and us Developers need to always keep in mind that we are there to support the user rather than the other way around.  Ultimately achieving this balance requires a robust architecture that on the one hand is flexible enough so, as to give a Developer enough freedom and control to build more advanced and challenging features, but on the other hand constraining enough so that it forces a Developer to conform and stick within certain defined boundaries defined by the rules of the architecture. So, it’s a delicate balance that comes down to architecture selection I would say.

What steps do you take to prevent an app from crashing?

Software crashes are one of those things as a Developer that, hard as you might try, you simply cannot prevent 100% of the time. So, it’s something you cannot get around unfortunately, kind of like death and taxes. All you can really do is ensure you have a robust framework in place to identify errors when they do occur, and deal with them appropriately so that they cause as little disruption as possible. This requires the following of best-practices to ensure you have error catching code in place. Also, you need to try and ensure that you inform the user in layman’s terms what just happened and what they need to do to be able to continue working. Obviously as a Developer you want to try as hard as possible to recover from the error as seamlessly as possible while invoking the least amount of anger from the User as possible. It can be a real challenge to get all those things right. It's also very important to try and capture as much detail about an error as possible, and then try and ensure that all this detail makes its way into the hands of the Dev team so that they can then try and identify the source of the problem, and hopefully fix it in the next release. Google luckily have a product called Crashlytics which can be very, very helpful in this case.

What are the different testing stages and how does each stage assist in the development of the app?

Testing is all about quality control. Developers that worked on a project will have a natural bias towards much of the functionality in an App, so they should not feature in the Testing phase at all, although a Developer will always need to perform Unit Testing and some other Basic Functionality Testing to make sure their code works as expected before they send it for code review and more advanced internal testing, followed by external testing. In computer jargon we would refer to this as Alpha, followed by Beta Testing. Testing stages are usually dictated by the type and importance of the software being built. For example, testing flight automation software where you are potentially dealing with life and death will have way more stringent testing requirements than say an ecommerce web application that is selling merchandise. During Alpha testing it is important to create a test plan that defines your inputs and expected outputs, so that the success of a test can be easily measured, and then also to ensure that this information flows seamlessly between the Testers and the Developers so that bug and other fixes can be performed within the time sensitivities of the Project and Test Plan. So, it would be an iterative process that repeats indefinitely until such time as all the Tests within the Alpha Test plan succeed, and then it can be moved into Beta Testing. So, each testing stage should result in improvements to the software overall and give confidence to both the Developers of the product, and the users of the product, that everything works as it should.

What’s next - maybe a customer app?

Oh yes, most definitely. We need to strike while the iron is hot.

All I can say is 'WATCH THIS SPACE'