It’s always nice to read about companies that agree with our sentiment about software modeling. In this case, the almighty Google has introduced ‘App Inventor’ to the world, fueling discussion between the masses similar to those we’ve prompted for years. As for the idea of providing nontechnical people a tool for creating applications, we agree that abstracted software development is a trend bigger than all of us – Google, Mendix, and everyone in between.
In an unexpected and commendable twist of fate, the users and believers, members and readers of Mendix just may know a thing or two that Google hasn’t calculated into its plan. We have heard the thoughts of our technical veterans, who dispel our modeling beliefs faster than they can address a letter or open their watch.
In the case of App Inventor, these applications serve the masses of the Android market – an interesting group of people even less technically savvy than our own modern business engineer. The reactions to App Inventor are altogether predictable; one of my favorites here…
“Great. Now any schmo can claim they have created a “program” just like any schmo can click the shutter of a digital camera and claim they have made a “photograph.”
And then there are the future-minded individuals who offer yet another perspective…
“So why assume that somehow coders/programmers are more creative than non-programmers, or that they automatically do a better job? I’ve used plenty of apps for computers that were solidly coded but their UI bordered on inscrutable. This may very well *raise* the quality of apps, because people with a good idea can build it themselves instead of trying to get a programmer to understand what they want.”
Either opinion is as well argued in the countless threads of comments about Google as they are in our own experience with modeling. The difference between modeling business applications and modeling for your cell phone brings an interesting question of value to mind:
What makes software valuable?
- Its ability to solve a problem.
- The speed at which it can solve a problem.
- Both. The positive change that is attributable to its implementation.
In enterprise software, the answer is undoubtedly C – a combination of the speed at which it can be implemented and its ability to solve a problem for an organization. If it doesn’t solve a problem, there is no reason for it – and if it can’t be implemented, it won’t be… simple as that. In the Android market, it seems as though Google wants these apps to solve an immediate problem that developers haven’t thought of or had for themselves. In the case of personal electronics, where utility is equivalent to profit, the answer is still C.
Software modeling, agile development, and business agility sit on a branch of software’s family tree that is growing eagerly. Our clients increase their bottom line because we’ve given them a tool that allows organizational evolution to mirror environmental change, AKA business agility. Google on the other hand, provides a tool for consumers to create added utility on their own mobile device. In either case, the end user is given a more direct role in creating their application.
Changes in application creation are never taken lightly. As one commenter puts it…“Creation? Man should not meddle with such power.” Here at Mendix, we will always stand behind the idea that abstracted development isn’t a way for business people to take work from IT people; it is a way to enable better collaboration between the two. Google has a solid track record of introducing game changing products to their enormous market, and when they back our own ideas as closely as App Inventor does, we look forward to playing the new game in ours.