Fleet Software Customization (Part 3): 5 Tips for Fleet Software Design and Construction
Ray Moro, Senior Software Engineer, AssetWorks
Analysis Paralysis: When Fleet Software Programmers get “Writer’s Block”
Similarly to when writers start overthinking their writing, developers suffer from writer’s block! When fleet software developers become overly burdened with concerns, nothing gets done!
An example scenario of a development team suffering from “analysis paralysis” goes like this:
• Programmer 1: We should build the fleet software with RoR.
• Programmer 2: But RoR doesn’t deploy nicely to heterogeneous servers!
• Programmer 3: Then we should only support one operating system.
• Programmer 2: But our customer already uses Windows and AIX!
• Manager: Why don’t we just host in the cloud?
• IT: But we have our own successful data center!
• And so on and so on for eternity!
In order to combat analysis paralysis, the fleet software development team should follow these tips:
Tip #1: Just do it!
Build something—anything! Even if you’re on your lunch break and doodle an idea on a napkin. A visual aid reinforces the core ideas of the design and puts everyone on the same page. Visual aids are much more effective than writing a list of requirements and throwing it over the wall to the programmers.
Once you have created something (no matter how small), everyone can look at it, review the viability and start building upon it. You may realize along the way that it wasn’t a strong idea, but it’s better to find out in the early development stages than months down the line!
Tip #2: Understanding fleet business processes
Faded ink is better than the best memory
Sometimes in the act of formally defining your fleet customer’s business processes, you realize that you didn’t really understand it before—or that everyone in your organization has different interpretations of it.
The key to determining your business processes? Modeling.
If you cannot easily discuss a business process, then you definitely can’t build software to automate it!
Remember: Models are not supposed to be perfect. If it was a 100% reflection of reality, then it would not be called a model! Pick out the parts that matter, and model those parts. When evaluating a new model, what matters is whether it is an improvement over the previous model, not whether it is “perfect.”
Types of models:
Workflow diagrams may seem like stone tablets compared to all the whiz-bang web-based collaborative wire frame editors available today, but they are both incredibly powerful and incredibly cheap to create. You can put it on paper, on a whiteboard or in your virtual meeting app, and make sure that everybody understands the flow of information and product/service through the business.
Wire frames are fantastic tools for quick design of user interface. These can be on paper or in fancy digital tools– it doesn’t matter. The point of wire frames is to represent the outline and organizational focus of a design at a level that abstracts out the mundane details. So you don’t care about what specific fields a user may need to enter, but do care about the way in which content is organized and used. For example: “Show user information at the top of screen, show system diagnostics at the bottom.”
Use cases are an old tool but were formalized through UML (unified modeling language). Even if you do not use UML, use cases are very useful for establishing the roles involved in a system, and there interactions. This is often phrased in terms of “X does something with Y.” For example: “Customer requests fuel from pump” and “Fuel pump dispenses fuel.” This helps you identify who is involved, both the people and the parts of the system.
Tip #3: Roleplay- not just for nerds!
During the “roleplay” stages of fleet software customization, you must walk through your customer’s business processes (hint: Use the models from the previous section!). You don’t need software to do this, and it is probably more useful to step away from your computer for a moment.
An example scenario of a development team role-playing a fuel card authentication module:
Programmer 1: pretends to be the fuel pump.
Programmer 2: pretends to be the driver.
2: I’m pulling up to the service station.
2: I’m getting out of the car and swiping my fuel card at the pump.
1: Not authorized! Your fuel card is invalid!
2: Whoops! That wasn’t my fuel card… that was my driver’s license!
As silly as it may seem, by acting out the different roles the fleet software development team gets very immediate feedback with very low cost. It also can help reveal gaps in the design that otherwise may not have been noticed until the system was already built, sold and installed.
Tip #4: Prototypes are your friends
Once you understand the process and have built a model, you can start designing a fleet software solution. But you are foolish if you think you will get the design right the first try (unless you are some kind of robot built by Google!). Prototyping is a good way to get early designs into the hands of the actual people that will use the product faster.
Remember: prototypes do not need to function. The idea is similar to tracer bullets: you know you will not hit the target the first time, but you can at least tell when you are getting close.
This tightens the feedback loop to save time and money due to expensive misunderstandings and last minute changes. As the development team’s understanding grows, you can continue to improve and formalize the prototypes. Start with a napkin, then a piece of paper, then a PowerPoint presentation, then a simple piece of functional code and so on until you have the final fleet software system.
Tip #5: Be prepared for change
Change is part of the process. Successful fleet software developers must design with future growth and change in mind.
Fleet management processes evolve (and hopefully improve) over time, so fleet software needs to adapt. To some extent this can be handled with things like configuration options and user-customizable workflows.
While software engineering is a relatively new field, the team at AssetWorks has 35+ years of experience to know that change is constant, and that it is essential to build software in steps that are both incremental (add one bit of functionality at a time) and iterative (repeat the cycle frequently to get feedback and monitor progress).
The dedicated team of fleet software programmers at AssetWorks would love to show you what kind of custom solutions we can provide your fleet. Simply fill out the form below and we’ll contact you soon.