Thursday, February 22, 2018

Releasing a new mobile app version

It's the Go Live. You've finished all development, gone through all the QA processes, stakeholders approved the new app, marketing campaign is scheduled. Releasing a new app is always exciting. However, releasing a new version of an existing app implies some extra considerations, particularly if it's a major version with lots of differences from the previous version. With everyone receiving automatic updates from the stores and with in-app updates like OutSystems provides, you have to take special caution when releasing a new version. You'll automatically impact customers, disrupting their routines, changing their lives (for better or worse).

So, here are some topics to consider when updating an existing mobile application.

Don't change app identifiers: Imagine you have an app in the store called MyCarApp (with an identifier like Than you decide to release a new version of your app and you want to call it MySuperCarApp and change the identifier to This is no longer a new version of the previous app, even if you see it that way and want to deprecate the old one. With the identifier changing, it's a new app on the stores and, as a result, you lost all your customer base. You are now dependent on them explicitly moving to the new app. So, keep the identifier. Just an extra note here, don't use weird identifiers. Don't use weird, unrelated ids. Don't let external, consulting companies decide for you. Run away from things like com.ConsultingFirm.MySuperCarApp. This will pursue you for the rest of your app lifespan, you can't change it (unless you fall in the scenario stated above). To pick a good id, please read the Reverse Domain Name Notation info.

Don't remove features: Imagine buying a new car and the manufacturer decided to remove the side and inside mirrors because they wanted to quickly release the new car model and didn't had the time to develop the mirrors. What would be your reaction? "What? I was used to having mirrors!". The seller can reply: "you can drive without them, the engine runs perfectly good and you'll get to your destination, just... be more careful". Argh, don't do that, right? It's the same with new version of mobile apps. If you remove features that users like and are used to, you'll take a huge hit in stores. People will get mad and automatically say the previous version was better, even if the new is super fast with a unique look and feel. Yeah, the car is cool, but... it doesn't have mirrors!


What to do? Metrics. First and foremost, understand what your users really are using in the app. Are they really using feature "A"? How many times users enter screen "B"? Data driven decisions, decide with the proper info in your hands. You'll end up discovering interesting usage patterns. Hey, there are probably features no one ever used.

Don't do a big layout disruption: Although this sounds weird (disruption is good!), it's actually something you also need to consider. We're humans and we're used to some daily routines. Our brain is "trained" to not think about most of what we do on a daily basis, like breathing, walking, brushing teeth, closing doors (one of the best books ever - Thinking fast and slow, by Daniel Kahneman). Same goes for apps: if you are used to having a shortcut in a menu that takes you to the feature you regularly use and suddenly it's no longer there but in a place that requires 4 extra clicks to get to where you went before with 2 clicks, people won't like it.

Don't loose user data: You can't do it. No way. If the user was properly registered in version 1.0 of the app, you cannot force him to insert all info again in the new version. Migrate user data to the new app. It's a must do, otherwise, you will lose users. Some won't like it, others will have lost the password, others won't remember the user, some will have to register again when they are in the banking row... you get it. And there's no technical limitation you can invoke here, "the new app no longer stores info in file "x" of the device but uses local storage" or... no chance. Migrate user data, keep the transition seamless!

Users don't know the concept of MVP: In software development, we use a lot the concept of MVP (Minimum Viable Product). But most people don't know what this is. When you release a new version, people won't know if your planning to evolve the app nor understand release cycles, fast feedback, etc. They are using it now, not tomorrow. They expect everything to be there, not in the future. You can assume it's going to have bad reviews and you will improve it. It's up to you...

They will compare: It's human nature. We compare everything. "This new car is much better than the old one", "This restaurant has a faster service than the one we went yesterday", "This TV has a much better image than that one". There are actually lots of techniques used in different industries that take advantage of this effect, called Framing (read Make a Choice). So, expect users to compare the latest version with the previous one, for the good and the bad.

Do a phased rollout: Nowadays, stores have great mechanisms to proper release an app. Beta users and Test flight allow you to safely test your app in real world scenarios with users. Then, both Google Play and Apple Store allow phased rollouts (e.g.: 10% of the user base, then 20%, then more 20%...). This is great because it allows you to control usage of backend servers, get phased feedback from users and reduce risk by affecting only a subset of customer base with a the new version. OutSystems has a great in-app update that also allows feature flag, but for major versions, it's better to use store mechanisms.

Have a great release!


Saturday, February 3, 2018

Keep learning

There are things in life that only experience can teach you. No matter how many hours of training you have, nothing compares to that unique feeling of seeing a message like the one below in a production database:

Rows deleted

Particularly if you were expecting to delete just one or two rows. I've been there too, trying to recover the latest backup as fast as possible because the company was losing thousands of euros every minute. I learned the hard way that production databases are a sanctuary and no script can run without a transaction. This seems obvious today, but not when you just graduated and you’re under stress. No training can give you the adrenaline of hammering IIS 6 metabase in a live production front-end. Project management in real life with customers is far more funny than theory tells you, and MSProject is actually far more weird when used on a daily basis. All these wounds have healed and made me much better today, no doubt. And all were valuable lessons and great stories. However, you cannot discard the value of class training for two very important reasons.


Be the best: I graduated in Computer Science. After 4 years working, I started having Project Management tasks. It’s a common progress, from IT to management. However, I felt I needed more than just “be thrown to the sharks”. So, I grabbed 10k€ and went all in for Project Management (an entire year, I would go to work at 9a.m., out at 6p.m. and non-stop until 11p.m., not counting group work and all those things. Oh, and family, friends, life…). Next, I felt I still lacked negotiation skills (dealing with customers or even day-to-day negotiation is crucial), so, I spent another 3k to further understand important topics. Last year I felt I wanted to further enhance my leadership skills. So, another 3k and I went in search of some extra guidance. What I’m saying is: there’s a lot of things experience can’t teach you. Go for the extra mile. It was expensive, but fun. Your career, your responsibility. Why not?

Networking: This is something that amazed me. While graduating, everyone was looking into the same: computer science. When working in a consulting firm, the customers where from a limited scope: banking, insurance, telco. However, in these post-graduations, I got people that sold diamonds, insurance companies CIO’s, a guy that has an olive oil company, a CTO of a big pharmaceutical company, everything. People with civil engineering background, marketing… So, not only you get the official training, but all the connections and extra experiences. Priceless. By the way, that’s why I picked 3 different schools.

So, while experience will teach you the hard lessons, training is an investment in yourself, will boost your development and give you different perspectives.

Be a teacher, be a student.
(ignore the branding, the message is awesome)

Tuesday, January 23, 2018

It's not you, it was me – Low-code

If your development is skeptical about Low-code, keep reading. I've been there, I understand them.

I was skeptical too. Yes, it's the truth. I was in my mid 20's and I didn't like Low-code. Everytime someone tried to convince me (sorry Hugo Almeida) that Low-code was the way to go I would reply with all reasons to prove Low-code platforms were not exciting enough. Today, I can't live without a Low-code platform. I can't imagine a world where you have to build an application from scratch writing all the code. If I could recover all the hours and hours of life I spent writing Database Access Layers and WCF integrations and zipping packages to deploy to production and... argh!

But this is today. Now I'm older (wiser?). I have over 10 years experience. I don't see things the same way. Today, I can look back and understand why I didn't like Low-code and why I was fooling myself into thinking I was right. But I was so wrong. So, below are my thoughts back then and my own reply today. It's César-Mid-Twenties in an epic battle against César-From-Today.

1. "I like code."
I still love to write code today. I'm that guy that can get all excited developing a personal project. Back then, I would stay up all night just because I had an idea and, well, it was fun to be all alone in front of Visual Studio developing my own stuff. I have so many episodes of this, but I have two favourites: I love cars and I had a VW which can be programmed in all possible ways you can think of (for those that know VAG cars, it wasn't just using VAGCom). Well, I spent an entire weekend closed in my father's garage playing around with the car . Yes, nights too. My father would open the garage in the morning and I was there, without any sleep. Hours and hours. Lucky me, Portugal is not that cold at night in Spring.

Car VW VagCom

Left of the image, my car's first dashbord. On the right, the garage and the car.

The other episode was on Christmas eve. Well, my bank in Portugal required coordinates from a matrix card to validate every online transfer. Argh, I got so upset I told my parents I was sick and stayed alone at home understanding how could I develop an OCR (free versions were bad apart from tesseract), how and if I could mess up the browser's memory to inject values and so on (no browser extensions back then or any smooth options). It was so simple (never actually finished, today would be much easier, but the idea is there - MVP):

So, you get the point: I like to mess around with things. All this was fun. However, Low-code is also fun. And today, I have a different mindset. I want my ideas to come to life more than ever! My brain is tattooed with "Technology is just a means to an end". Low-code is the best balance between fun and results. And that feeling when you see your apps being used by others... priceless!

2. "I don't like Low-code."
It's different from the above statement. One thing is to like code, the other is to not like Low-code. This was mainly because i didn't fully understand what Low-code meant and I was resisting. Like any new technology, you won't like it at the beginning. It's like beer or red wine: did you enjoyed red wine the first time you tasted it? Well, I was all about white wine when I was young. Now I love red wine. I learned to appreciate the good things in life (sorry white wine drinkers, I still drink white wine but... there's a new trend in my town). Give it a shot, you'll love it too (not the wine, the Low-code).

Red wine

Got to love red wine.

3. "The entire team is used to other technologies."
Yep, it's disruptive. Like in the previous myth, you won't get the buy-in from everyone in a heartbeat. And you can't force Low-code down to everyone's throat. It doesn't work when it's imposed, we are humans and we must understand why we're doing things (Ellen Langer's experiement). And it takes time for teams to get productive with Low-code. Different tools, different way of thinking, different working methodologies. Nevertheless, it will take much less time to get to full speed than other technologies or crazy languages, say, I don't know, Objective-C... The learning curve is much faster than tradicional development.

4. "I don't want to learn this new tech as it might not add value to me"
There are literally thousands of programming languages out there (Subset is listed in Wikipedia). Some are more used than others, some are more specific than others, some seem to be in high demand others don't. The point is: it's not about the language. A good place to work will want to know if you can think rather than how many languages you know. It's about how you structure ideas, creativity, innovation, engineering. A person can speak English, Spanish, Portuguese, French and German and still not be able to articulate thoughts in either one.

5. "I have less control."
Remember that movie with Tom Cruise, Days of Thunder? Nicole Kidman said that "control is an illusion". This somehow applies here too. Are you concerned about machine code running in your CPU? How Windows uses paging? How the .NET framework abstracts you from dealing with memory management? So, why should you be concerned about how a Low-code platform abstracts an if statement to a visual element? But I was skeptical too. After all, César-mid-twenties was a super engineer able to write awesome code (yep, I was). How I got this myth out of the way? One day I was using an OutSystems action called TextToDecimal. As the name suggests, it basically converts a string to a decimal number. However, in some countries the decimal separator is a comma and in others it's a dot. And this depends on the culture info you have on your machine. If OutSystems engineers didn't implement the action using the right underlying method, making the conversion CultureInvariant, it could be a mess. Worse than that, a mess only when the code reached production! You can read the full story here, it's worth it. That day I was sold: I won't care about the underlying quality. These guys have this covered. Proper implementation, properly tested through years. Really read it, it's simple and cool: A good example.

6. "Development is not faster."
Metrics. Give me numbers César-mid-twenties. The truth is that for the same project, two proficient teams, the Low-code choice will be faster. Of course, it depends on the project. I can't imagine that VW messed up with a Low-code platform... hum, wait, idea. No, seriously, there are lots of projects that might benefit from not using Low-code for all sorts of reasons, let's be honest (e.g.: airbag systems, airplane sensors, etc). Even more "non-critical" projects, like high graphical mobile games. But it's "some projects"... a mobile app is not the case. Developing Android and iOS versus a Low-code mobile app? Objective-C? When I saw that "alloc" word, in 2017...

Red wine

Copyright(C) Dilbert

7. "These Low-code platforms have limited use cases."
They always have "the way out", the "dark bag", the escape: Extensibility. Of course the platform narrows the use cases, it's the 80/20, otherwise it would be almost impossible to have anything usable in an IDE. But if the platform is good, it will have a way for the user to extend functionality: some JSON, a .NET extension, writing a cordova plugin yourself, whatever, it should have a way to do it. Just dig in like you would have to do if you weren't using Low-code. Just remember it's for edge cases or you'll end up not taking advantage of the platform and doing everything aside. And also keep in mind that Low-code is not No-code.

That's it. I've now killed my twenties self.

Summing up all this: as time goes by you quickly get to a point in your life, as a tech person, where you need a balance between fun and speed. Your focus will shift to "Technology is just a means to an end" and you'll take it seriously. You'll realize life is too short to iron clothes, insert numbers from a matrix card to validate a transfer, dry dishes or code a full app from scratch. I know can't afford spending a full weekend in a garage writing code.

Life's too short to write too much code. Low-code.

Red wine


Yep. All big car maintenance would end with a great picture. I loved that car, what a toy...

Thursday, December 28, 2017

Call me a whiner any day

It's one of the best things we have at OutSystems nowadays: our ability to change. How quickly we adapt to new realities and move to something better. And everyone is open to listen to your ideas.

Since I've joined this team I learned to challenge things. I also learned to be a whiner. A big one. I don't mind. "Whining is the first step toward change. It’s the moment when you realize something is very wrong and that you have to take the initiative to do something about it." I rather raise the flag, gather feedback and understand how to move forward. If your company is good, everyone will want to know what problems you're having and help you.


So, cry. Complain. Complain again. Whine. Then move yourself! Make things better!

"Call me a whiner any day."

Quotes are references to the book How to win at the sport of business.

Wednesday, December 13, 2017

Lose the head – Tag!

OutSystems 10 brought the wonderful world of low code to mobile application development. Now, it's about your ideas! Want an app to take pictures? Just "drive" to OutSystems Forge and look for the Camera Plugin and use it in your app:

OutSystems Camera Plugin

There are literally hundreds of plugins out there to interact with basically everything on your device, from accelerometer to camera, GPS, etc. OutSystems has a list of supported plugins, which means that not only you get official support if anything is wrong but the plugin is also properly maintained and evolved. However, the great power of this plugin mechanism is that the community is able to develop whatever plugin. Anything! Hey, I've created a plugin to keep the Android screen alive all the time. There's documentation on how to create a plugin, but I want to highlight a critical aspect of plugins.

OutSystems mobile apps are cordova based. This means that, potentially, any cordova plugin can be used in your apps ("potentially" because some plugins might not work - e.g.: because they are built for Android 2.3 (low target SDK), they don't have iOS implementation, etc). Lets head back to the Camera Plugin. To use it, you have a client action, "TakePicture". But what does that mean? Taking a picture is something that implies specific native iOS and Android commands. So, how is that client action doing the magic? Well, an OutSystems mobile plugin is actually composed by two distinct parts:

OutSystems Cordova

How does everything work together? Where's the glue? A bit more low level:

OutSystems Cordova

Looking at the image, you can see where the logic separation is between OutSystems and the native code. A cordova plugin basically exposes a Javascript API that OutSystems plugins ultimately call. There's still a missing piece: how does the platform know what cordova plugin you want?

OutSystems Cordova

It's in the OutSystems plugin extensibility configurations.

OutSystems Cordova

The camera plugin uses an URL to refer to the native part. When you request a native build of your mobile app the OutSystems Mobile Apps Build Service (MABS) will then use that URL to fetch the code for the native part of the code and include in the build of your app.

OutSystems Cordova

Now, here's the detail: did you notice the URL of the plugin?

It contains a what is called a tag (or release). This instructs the MABS to get that specific version of the plugin and not the latest and greatest. This is a best practice: do not use the head of the master branch. Weird? Let's see why I'm stating this. Assume you have no tag; Without the tag, you are using the latest commit someone did to an open source project, the camera plugin. How risky does that sound? A lot. There are tests and so on, but still, it's risky! Considering this, imagine the following scenario: you started a project for a mobile app in February and included a plugin with no tag. 2 months later you go to Quality Assurance processes and, after 1 month of proper validation, you're ready for the go live! Well, someone commits in that repository and... bum! Everything is broken or it's not working as it did before. Or now it's compiled with 64 bits library and you are also using another plugin that conflicts with that. Or...
You get the point. You didn't do anything and, all of the sudden, your project is no longer ready to go live. It's a free run and you have no control. You are totally dependent on "strangers". And this gets darker: someone might not commit on the main repository of the plugin, but the plugin is referencing the head of some depending libraries and someone commits in that dependency repository. Now it's even harder to understand why things suddenly stopped working because it's not obvious, there are no commits on the main plugin branch!

So, rules of thumb:
   1. If the plugin is critical for your business => create a fork to your own repository and merge as needed (OutSystems does it for the supported plugins)
   2. Make sure the plugin's dependencies use tags.
   3. Always, always, always use tag. Control your release.

Happy plugins!

Friday, September 29, 2017

OutSystems mobile app at scale

The goal of this post is to actually provide some tips when using OutSystems 10 to develop Mobile apps. It's so easy to develop an app using the platform that sometimes we tend to forget a few things that might be important at scale. So, if you're planning to build the next Facebook using OutSystems 10, keep reading. Tip 6 is the more important.

1) Don't run away from the stores
It's a fact: you're not in control anymore. With web apps, whenever you wanted a customer to get a new version, you just had to "One-click publish" and that was it. "Hit F5 and you're done". The happy path simplified:

One-click publish

Ok, here we're ignoring all the operations behind it (from development to production). With this "web", you could still have issues that you must keep an eye on: add a proxy, bad network, cache servers, load balancers and a huge frontend farm and the scenario gets a bit trickier:

One-click publish

Nevertheless, you have almost all the control (Days of thunder - Control is an illusion). Why should the mobile world be any different? OutSystems 10 brings you Mobile Apps with an amazing capability: no need to go through the stores to push a new version to your customers! There are lots of applications that do this already, even facebook (facebook lite app):

Facebook Lite

This is a huge advantage (pushing updates to the customer on-the-fly) because it no longer implies a round trip to the stores. So, looking at a typical update scenario:

OutSystems update

Looks like "the web" scenario where your "One-click publish" goes to the customer in seconds. So far so good, the happy path is always a delight. However, this feature doesn't mean one submit to the stores for life. The mechanism that checks for updates will get the "delta" from what's new in the server and what the customer has:

OutSystems Lifecycle app
(click to enlarge)

As you can see, if the customer is constantly picking up the updates we're again in a happy path. However, imagine a customer that installs the app from the store 2 months after your release in the store. When he opens the app, the in-app update mechanism will check for updates and see that there are 1120 new changes (V6 is in production). If the files have, in average, 10KB each, that will imply approximately 11.2MB for the update. This will bring overhead and, in bad networks or network transitions (e.g.: entering an elevator, subway, etc), might not be smooth (2G).

So, tip number 1: don't run away from the stores. Create checkpoints whenever you start to witness a big difference from the original submit. It's a balance.

2) Understand the upgrade model
The updates "on the fly" are amazing, no doubt. However, some features require a new shell (e.g.: using a new plugin that interacts with native features - camera, bluetooth, NFC, etc). Now you'll have to deploy your app to production and go to the store. Let's go with an example: suppose you have an app and now you add a functionality to scan QR Codes by clicking a button. You go to the OutSystems Forge and grab the supported Barcode plugin. This requires a new shell as it now interacts with a native capability and code to interact with the camera. How to "glue" everything? Publish to the store first? Deploy to production first?

OutSystems update

Let's look at this scenario. The first thing you MUST do is to protect your code to not "blow" if the plugin is not there. Hide the button, provide a graceful message to the user when he clicks, whatever. Just make sure you don't try to scan if the user doesn't have the plugin. This is a must do no matter what's your deployment strategy. Now, for the complete experience to be in the hands of your users they will need to have both a new shell with the plugin and the logic in the app.

#First approach - long time prepare
If you know you're going to need this plugin, release today a new shell in the stores. Wait a few weeks until your customers update to the new app from the store (or force that update in the app). After that, deploy to production the new feature.

OutSystems update

#Second approach - Deploy code first
You might not be aware in advance that you'll need a given plugin. So, you can't prepare it so easily. Go to production with the code protected and deploy to the stores right afterwards. You must properly protect the feature to scan the QRCodes.

OutSystems update

Keep in mind that unless you programmatically force the user to update from the store, you don't control how much time the user will have an old shell:

OutSystems Lifecycle app
(click to enlarge)

Tip 2: Keep in mind that although you have the applicational updates "pushed to the client", native functionality will go through the stores and you must have a combined strategy.

3) Caution with infrastructure
If you're not in the cloud and have the responsibility to have all the infrastructure in place, then, besides all the work you'll have, you will also be the one dealing with cache servers, load balancers and several frontends. So, this means that in a deployment to production, some customers might get a new version while others don't. Some might be affected by cache poisoning (e.g.: Cache is returning bad JavaScript files while returning new HTML files...), others might not.

OutSystems update

Tip number 3: properly setup the production infrastructure and be aware how you deploy to production.

4) You will have a customer with a rooted Xiaomi 3422-y-k-x-a-89002893-whatever-the-model-it-is
This isn't something particular to OutSystems. It's on all Mobile. Due to the market fragmentation, particularly in Android, you will have a customer with a Xiaomi model that something will not work. YOu don't need to avoid that, but protect your app to avoid possible unhappy users. Example? Do you want to accept rooted Android devices that you don't have the slightest idea of what's hammered or not? How will you deal with a complaint from a customer using a device you don't have access to?

Tip 4: Prepare yourself to customer's free of will to buy whatever mobile device they want and you not having access to it.

5) Phased rollout is king
Because the control you have is little, a phased rollout is almost mandatory. YOu have the ability to push improvements to customers, take advantage of that and do a DevOps approach, releasing things to internal users first, then some customers, then... It's the same logic that TestFLight and Play Beta use, but faster and better! Maybe you have the new button to scan QRCodes. Well, make it visible to a given set of internal users or friends. Then open to the world.

Tip 5: Take advantage of the fast updates to gather feedback faster from a subset of your customer base.

6) Just because it's easy...
... doesn't mean you don't have to read some documentation. Most developers out there are used to a web world where the concerns are totally different than mobile. Performance, battery consumption, network conditions, device fragmentation and all those mobile world intrinsics must be a primary concern from the first day of the project.

The technology makes it easy to bring your ideas to life. But you still have to care for your ideas and your project.

Tip 6: