17 Jul 2017
in Technical Blog by Kae Verens
From our own point of view, and from the points of view of our customers, it is nice to be at a point in our service management software development where we are developing iteratively instead of coming out with new tricks every week. image: clean, rinse, repeat While I love it when we develop something new and exciting, it can be nerve-wracking for us for the following weeks, as we try to find out what these new shiny toys have done to our solid, stable, well-tested field service management engines. New tricks never affect the existing workflow management system customers, because they are on servers that we do not edit except for the occasional bug-fix. The only customers that get to see the new shiny stuff are those that specifically asked for it, or those that asked for other new things such that we were forced to place them on our testing server while we worked on the next release. FieldMotion is now so flexible that whenever we're asked to develop anything new, it more than likely ends up that we already are able to do it, so my job is sometimes simply to listen to the request, and then point out how it can done already with the workflow management software. Sometimes, though, we are asked to do something that's just slightly beyond what we can do at the moment. It's never far away; just slightly. For example, today I was asked if it was possible to do a certain thing with RFID tags. After thinking about it, I suggested a way we could do it that would involve adding maybe only 20-30 lines of code to the field service management app, and yet it opens up our possibilities to yet another broad channel of potential customers. This kind of thing happens often enough that every six months, we have enough new little tricks that we can release a new version of FieldMotion's field service engineer software, confident that there is enough newness in there to merit the release, and yet it is similar enough to the previous release that our current clients won't be shocked at the difference. Iterative development allows us to "tune" the workflow system to fit better with the customers, knowing for sure that the system already works very well for them, and we're just adding enhancements, not adding whole new sections that need manuals. I was explaining earlier today to a new developer that when we create a new widget or page for the field management software, we need to make sure it is as absolutely simple and obvious as possible. He was telling me how he liked the power that the CMS Joomla gives him when he creates a website. Yes, it gives you a lot of power, but it's at the expense of usability. Every time I have to work with a website that uses Joomla as its engine, I have to learn all over again how it works. That is bad user experience. When you use any part of FieldMotion's workflow software, it is straightforward and obvious how it works, whether you've been using it every day since you got your account, or this is your first time ever seeing it. In my old life as a web developer, I would say to clients that "If you need a manual, I've built it wrong". I stick to that slogan and make sure that everything we produce in our system is clean and obvious. This is also why I love iterative development - instead of developing more and more and more stuff that piles up on the field service software like turrets and walls on a fairy-tale castle, we carefully expand the system just enough to fit the new trick in, and then just as carefully make sure that it is seamless and easy to understand.