CivilGEO’s Software “Development on Demand”
What would you think of a software company that is so keen on making a great product that it will take client requests for new software capabilities and will implement them, sometimes within days of the request? That would be a bit unusual wouldn’t it? And yet, CivilGEO does exactly that; we call it “software development on demand.” Practicing civil engineers are the guys and gals that let us know if the basic “machinery” behind our software is worth its mettle. They are the “lab rats” if you will, behind our technology. For this reason, we take our users’ “stories,” comments and suggestions very seriously.
An Idea in the Pipeline
Whenever we get a request to add a feature, the proposal is put through an analysis that separates those ideas with real promise from those that don’t add value to the product. We begin by talking to end users about which features are most important and which are not. This often includes a discussion about competing products on the market and how they do or do not address users’ needs.
What is a Typical Engineer’s Workflow and How Can We Make It More Efficient?
We put ourselves in the place of the engineer or consultant and consider how the software can most efficiently tackle the problem we are trying to solve. This requires our team to think creatively and we often find unique answers to problems that have long dogged the professionals we serve. Competing products may offer a cobbled together “solution” to a user problem, but it’s often not an ideal outcome for a variety of reasons. We are not afraid to try a completely new approach to a challenge and to tackle it from a very different angle.
Designing an application that approaches a problem in a completely novel way is laborious. We are sure to encounter serious limitations along the way. Both limitations in hardware and available memory can further define what is commercially feasible. However, we have found that this strategy of thinking “out of the box,” although it takes a lot of patience, ingenuity and intense team work, offers a larger payback in the form of a more satisfied customer base as well as a product with real and lasting value.
Fine-Tuning with User Input
If the proposed feature passes our initial evaluation, we storyboard, or plan out implementation of the application step by step. We show our sketches to the client and ask for input. Agile methodology requires us to look at all of the “moving parts” of the software as well as how the proposed feature fits within the framework of projects we are currently working on. All of the developers weigh in on how best to implement the capability and within what time frame. We schedule the work into our timetable with considerations of which programmers with the necessary expertise are available to work on the necessary code.
Example I: An Idea that Doesn’t Make the Cut
Some “needs” seem unique to the client that is proposing it. One client requested that we work on improving the printed quality of the GeoHECRAS file so that it was of the same high caliber as an AutoCAD print-out. While this would be nice, we concluded this feature was not worth the effort or the time. Generating high quality drawing files should be a priority for AutoCAD and ArcGIS, programs that are focused on generating high quality graphics for construction and design projects. Our primary focus is on enhancing HEC-RAS’ capabilities, software which has an entirely different focus and objective.
Example II: An Idea Worth Pursuing?
When we were asked to introduce the capability to model for unsteady flow, we knew this was a feature that would enhance the overall utility of our product. Not only do unsteady flood flow analyses often generate more realistic hydrographic outcomes, but the functionality made sense in multiple ways. We also realized we could leverage much of the code developed for steady flow analysis to an unsteady flood flow scenario. Once we decided to move ahead, the feature was implemented in four days. The following YouTube video shows what we were able to implement for one of our customers, Bolton & Menk.
High Standards for Our Software
Our software needs to have some key characteristics for it to meet our exacting standards. In summary, we ask the following questions whenever we consider any revision, modification or feature request:
- Does the program automate certain rote tasks a civil engineer is required to do?
- Is the software’s user interface intuitive and easy to use?
- Does our software offer capabilities that are not available in comparable applications on the market?
- Does the software have unnecessary “clutter” that detracts from the software’s core mission? If so, we remove it.
- Do all of the features enhance the core purpose of our software?
Software is a living, evolving organism, changing with the time and staying current with professional needs in the field of civil engineering. Our process for considering changes to our software’s design needs to reflect this key objective.
