So you want to build a mobile app. Should you choose native or hybrid mobile application development? Each choice has advantages depending on your projected use and time to market.
What is a hybrid mobile application?
Mobile apps generally fall into two categories, native and cross-platform or "hybrid". A native mobile application is just what it sounds like: it uses the SDK (Software Development Kit) and hardware features specific to a particular mobile operating system. Hybrid mobile applications also fall into two general categories, hybrid HTML5 apps and native cross-platform apps.
You may have heard software developers and project managers talk about "technical debt". This term has been around since the 1990s and is growing in popularity. But what is technical debt and why do people keep talking about it?
Legacy system conversion projects are always challenging. Rollout strategy can make a huge difference in successful user adoption and overall project success.
Only when I began writing them down did I realize that I had recurring dreams. I had believed that my dreams were largely random and varied, but instead I learned that I had many frequently recurring themes. Similarly, the process of writing down my thoughts on software development has shown me that there are also recurring themes.
One of these themes is the impact of rollout methodology on a project's success. More specifically, rollouts of legacy system conversion projects. Rollouts of brand new systems into an organization are typically less painful, as you are often automating a paper process, or inventing a new process that improves productivity. However, legacy system conversions are almost always painful, as there are many processes that have emerged around this system. People have developed a form of muscle-memory with the old system that even they themselves scarcely understand.
We have successfully replaced dozens of legacy systems where everyone was happy and all was good with the world. But it's not those projects I want to talk about. I am going to talk about the projects where things went awry, because I don't want to make the same mistakes again. Hopefully, these words will also help the reader to avoid similar problems in their projects.
It's easy to assume that someone needing user support is not using the application correctly. What if there really is a bug?
We've all seen the acronyms from user support techs: ID-10-T errors, PICNIC, PEBKAC, and so on.
On the one hand, they're pretty mean-spirited (but kinda funny). On the other hand, who can blame user support techs for being exasperated when rude, frustrated users scream at them to solve problems that aren't their fault. Yes, some support techs really do have to walk users through the most basic of operations. REALLY basic, like making sure the computer and monitor are plugged in and powered on. On the OTHER other hand, it is the job of support techs to bridge that knowledge gap.
As consultants, we are often called upon to support our own or someone else's software. We have to be the opposite of that acronymic stereotype. Users aren't idiots; they're experts in something we are not proficient in and vice versa.
Once in a while, we are on the receiving end of user support, and these experiences can be real eye-openers. I remember one instance where we found an undocumented limitation of a mature third-party application.
ONE: Don't just "break the system"
I remember my very first QA task when I started here three years ago. I was testing a client’s internal employee management system. I had never tested anything before, so I asked my project manager, “How should I QA the software? What does that mean?” He answered simply: “Do your best to break the system.” Okay, I thought, should be easy enough. So, when I sat down at my computer, I opened the user management screen and did my best to mess with it – invalid email addresses (example: email@example.com, ned@winterfell, harryunderthestairs.com), phone numbers with too many or too few digits. And I made sure to document in Notepad every “error” I found this way.
After about an hour of this, I proudly sent my list to the developer. Look at all the bugs I found! A few minutes later, the programmer walked over to my desk and explained gently that these were not the only types of bugs I should be looking for. While it is worth knowing which fields catch invalid data types and which do not, this is only the beginning of the testing process.
"There are only two hard problems in Computer Science: cache invalidation and naming things." - Phil Karlton.
The above quote, while somewhat tongue in cheek, wears the ring of truth. Naming things is hard. Even when you put enormous effort into consistent and clear naming, you will invariably end up with some muddy and inconsistent caverns in your code. And when you are unfortunate enough to inherit code from someone (or multiple someones) who put no effort into their naming...You're in for a world of pain. If you have been programming for any length of time you know what I am talking about.