Mendix versus Traditional Dev: 3 Reasons Why I Made the Move
My name is Eric Tieniber. For as long as I can remember, I’ve been interested in technology. Growing up, I’d tinker with old computers in my parent’s basement – break them, fix them and then break them again. It’s only natural then, that I started fixing my neighbors’ computers. From there, I began consulting with local small businesses: installing networking equipment, configuring a VPN, or adding new workstations.
Generally speaking, I am (and always have been) a middle man between business and technology. I work with businesses to understand their needs, and deliver a solution based in technology.
Throughout my career, I’ve maintained that theme. Before Mendix, I worked at Deloitte, in the world of traditional technology consulting. I delivered some great solutions to my clients. With Mendix, I can deliver amazing solutions in a fraction of that time.
In thinking through my transition, I’ve found three major areas where Mendix truly stands apart from the traditional IT world: initial development, bug resolution, and product enhancements. In each area, I’ve done my best to connect the dots between old and new and why the new (Mendix) beats the pants off the old (traditional development).
1. Initial Development
When it was time to start building an app in the traditional IT world, we stepped through the systems development lifecycle (SDLC) model. This meant analysis, design, and then implementation in concrete steps. Design involved pages upon pages of often contradictory documentation, and it’s not easy to discuss an application when everything is strictly hypothetical. Couple that with the fact that your users often don’t really know what they need, and at the end of development, we’d often discover gaping functionality holes.
“What do you mean you need Outlook integration!?”
With Mendix, you can take an idea, pull together a base set of requirements, and have a proof of concept ready within a few days. Getting feedback from users and management is easy when you can put something real in front of them. A few cycles of feedback later, and your users get exactly what they need.
2. Bug Resolution
Testing, piloting, and bug fixing were always a challenge in my old world. I’ve tried issue tracking through email, Excel sheets, and SharePoint – even an entire issue-tracking application. You name it and I’ve tried it. And every time, the team would struggle with duplicates, missing information, and versioning issues.
Mendix combats these scenarios through its Feedback Widget. From a user perspective, it’s easy to submit an issue and take a screenshot directly from the application. From a developer and product manager perspective, all of the feedback is sent right into the project portal. The project portal also stores your user stories, so it makes sense to also maintain your issues and bugs within the same place. This also makes planning fixes for the issues easy; bugs follow the same planning process as development stories.
3. Product Enhancements
A few of my previous projects focused on a highly customizable web application used by healthcare providers. New clients often demanded new features, or worse, our Partner would promise the client some feature we didn’t have!
Adding a new feature meant working in at least four different areas: database, back-end code, front-end UI, and security. Between the collaboration and planning needed internally and with our clients, it often felt like a minor miracle when we finally launched a feature.
With Mendix, all four areas live in one environment. Domain models, Microflows, pages, and built-in security all come together within the Business Modeler to create a visual, self-documenting development environment. Sure, you still need to test, but adding features is a relative breeze!
So there’s my spiel. My name is Eric Tieniber, and I’m Mendix Blue. I’m a programmer turned rapid developer and I’m excited to be working with our customers so that they can accelerate their app delivery timelines and start seeing results.