Monday, December 31, 2018

Breaking our own monolith

If you are interested in OutSystems, you probably came across some articles from Francisco Menezes and talks from the CEO about breaking monoliths.

"A monolith is the result of building every business value and functionality into a single core application. When first building a product, a monolithic strategy has significant upsides: development moves quickly, the tech stack remains consistent, data remains in a centralized location, access to functionality is at the fingertips of every developer, and others. But as a product ages and the teams behind it get bigger, the downsides kick in. Release cycles slow considerably as changes of any kind (big or small) require a full-product release."

Well, we also had a monolith problem with the platform itself and we had to follow the same path: break it! We needed faster release cycles!

OutSystems Overview

Independent release cycles

Online services
The Mobile Apps Build Service (MABS) is a service that, in essence, abstracts a developer from all the complexity around the generation of a mobile app (XCode, SDKs, etc). This was designed, from scratch, to be loosely coupled from the rest of the platform. By following this path we got ourselves independent release cycles for MABS. MABS moves at its own speed as needed and customers get automatic updates whenever they generate mobile apps. OutSystems Insights is another piece of software at OutSystems designed from scratch with all this in mind.

Service Studio
This is a bit more tricky. Both Service Studio and the Platform Server share lots of definitions. To illustrate (and keeping it simple), imagine that we introduced a new element in the language that only Service Studio knew about. When you published it, what would happen on the platform side? So, the full decoupling is not that easy. However, there's no reason why Service Studio cannot get lots of "goodies" without requiring a platform release. So, Service Studio is scheduled to be released every week. Even further, recently, we released Service Studio Beta with automatic updates. That means you can get features in your hands automatically in no time. We release --> you get an automatic update --> new feature!

OutSystems Overview

OutSystems UI, OutSystems Now Service, Supported plugins
Well, Forge components, basically. These have a completely independent "life". The release cycle for these components is as simple as publishing them in Forge.

Why should Lifetime be dependent on platform releases? If there's an improvement in the mechanism to stage apps, what does that have to do with Service Studio or Platform Server? It doesn't. And Lifetime currently is on it's own release path.

These 4 above are great examples of independent release cycles at OutSystems. And this means that teams can work independently, at their own speed, releasing value faster to the hands of customers and developers.

Thursday, November 29, 2018

What will you remember?

I'll start this post with a personal story.
I was part of the team that built the Mobile Apps Build Service (MABS). This is that piece of software that allows you to generate mobile apps using OutSystems, abstracting you from all the complexity of native mobile development. This service is supposed to run 24/7, we're targeting a 99.8% Service Level Agreement (SLA).
It was 1am on a Friday. The night was going really well, just had dinner with a beautiful curly-haired, “green eyed” woman who was now naked in my bed. I was also naked, “ready to roll” (whatever you want to call it). Suddenly I got a call. The number was from OutSystems. Well, at that time of the night it could only be support teams. My number was the first one to call in case of an emergency with the service. I picked-up the phone, Android builders were stuck and customers were not able to generate mobile apps.

There I was. On one hand “fireworks”, on the other issues with Android builders.

Angel vs Devil

Can you guess what I did? What would you do?
I know, you’re thinking "f*cking jump into the bed". I didn’t. I put on some boxer shorts, went to the living room and opened AWS console to start troubleshooting. 20 minutes later, great success: service was restored and… the girl was sleeping.
This was real. It happened. And now I have a story that I’ll remember for the rest of my life. Of course I had to apologize to her and explain that decision. I would feel offended too if someone did the same to me. But I did the right thing. I had people depending on me. I’m not in it just for the money, I’m in it to be good at it. And that’s the only way to do it: Go big or go home.

When you're old, you won't remember the "normal days at work". You won't remember the 9 to 6pm normal work. You won't remember the routines. You'll remember the crazy stories, the nights when "shit hits the fan" (best team building events happen automatically when things go wrong), the applause when you do a kick-ass work. You won't remember the days you just did your job, you'll remember the days you excelled. That's where I want to be, where the adrenaline is.

"But... are you saying that we should always be in trouble or with high adrenaline"? Well, no. You would get really really really tired after some time. My worst job was the first one. I was working from 8am to 11pm, doing everything: project management (sort of ), writing code, talking with customers, writing specs... a recent graduate! Of course it didn't last long. I just held on for a year because I was too proud to quit. I learned a lot and I have lots of great stories to tell, but that was no way to live.

Nevertheless, point in case: give it all while you can. It's like sports: if a game has 90minutes, give it all you got until you can no longer stand up. Even if you can't breathe after 30min, doesn't matter. Be the best on those 30 min.

Side notes
- although my number was top1 on emergency call, the first task was always to actually gather the team. That story was the only example where I didn't and went on my own. Usually, we would all be ready to work after 5 to 10min. Amazing team spirit "when things are not working".
- I ended up getting married to the green eyed girl :)

Wednesday, May 9, 2018

Stopping chaos while still being helpful

The Small Book Of Few Big Rules

Be helpful.
This is one of the rules you'll find in the small book of few big rules. This small book contains the core values to be successful at OutSystems. I guess it's actually a key part why the CEO says that "80% of people will become great when in the right environment". And people take these small rules *very* seriously at OutSystems.You can go around the office and feel this, like if it was something you could touch. People guide themselves by this book, it's amazing. Now, focusing on the help rule:

People at OutSystems are open to helping you. Use this to your advantage as much as possible. And do the same yourself. Offer help even if it is not in your job description. We believe you should extend yourself outside the boundaries of your work and into other functions to get the job done. Remain aligned with the Ultimate Goals when offering assistance. When it is your turn to look for help you will nd that people will quickly reciprocate.

Pretty simple right? In essence, it is. However, my team actually struggled with this rule. We helped too much, in a chaotic way. How is this possible? The Mobile Team is highly exposed to pretty much everyone, from support to customers, to peers, to...It's the main entry point in the R&D for anything you can think about related with mobile. Remember that OutSystems 10 brought Low-Code development to mobile apps. But, of course, it wasn't all done by the mobile team. We had literally hundreds of people involved from dozens of teams (IDE, FrontEnd Teams, Core Teams, you name it). Think of us as a group of pretty organized ants, carrying blocks of "value" instead of sugar to a big platform.

OutSystems 10

At some point, a combination of this exposure with our strong feeling about the small rules became toxic. Too many requests together with our willingness to help resulted in a huge growth pain. We created a monster. That's not necessarily good in a R&D department and can highly impact value delivery to customers.

Too many channels

OutSystems Mobile Team

First there was skype. Then Hangouts. Then... Without realizing, we had incoming help requests coming from all sources of communication channels. People would jump to our spot in the office, interrupting all the time in search for help. Some would "skype" a team member privately. Some with hangouts. Feedback would come through mail, support cases through JIRA, mail... Slack, which appeared later was the final "stone". A public #rd-mobile-team slack channel you could use to get help? Sounds awesome, except you would divert the attention of an entire team. And private messages, now on slack too?

Monkey User - Focus

Click to enlarge - source:

It started to be too easy to reach the team. All team (and more) distracted because someone entered the team channel to ask "which plugins in forge are supported?" Or... Of course, we replied to everyone on every channel because we wanted to be helpful. But it was taking a huge hit on the team performance and focus.


What to do? Well, what we do best at OutSystems: change!


Click to enlarge

Back to the drawing board. First step? Notify management that we were not working properly and ask for their input. Ideas! "Call me a whiner any day". And they did gave us a great starting point. We merged their ideas with our own and we had a plan.

Executing the plan


We're a fast growing company that's in constant mutation. Everyone is open minded and always willing to change. And top management supports change and encourages autonomy of people to apply these changes. So, let's do what best fits our team. But first... how do other teams around us work? How have they dealt with this issue in the past? We talked with the most similar to our team and got great insights. Again, we would to whatever would best fit our working methodology, but ideas are welcome.


"You can't manage what you don't understand". We started with a small impact analysis: how much was it costing to be so helpful? Impact on team speed? Also, a small risk analysis: what are the risks of helping through private channels? What if some erroneous information ends up in a support case and a customer gets the wrong expectations? Well... we were surprised with so many risks that we didn't think of. We never stopped for a moment to look into this issue. Hell, we're growing at the speed of light!

Action items

Write down action items and owners. By action items we're saying what must be done to improve and the owner is someone that will assure things will happen (not necessarily the person who implements it). This will get things rolling.

The "bad boys"

It's so easy to just open a chat window and ask things that it's the most dangerous part of this equation. So, our first targets were the chatting channels:

OutSystems Mobile Team

  - Reduce scope: No answers through Skype or Hangouts. Our official, internal, company wide tool is Slack. Period.
  - Redirect from private to public: private Slack chats shouldn't be used to ask for help unless you specifically want to talk to that person. So, ask in the team channel. Not only you'll have proper help but everyone in the channel will have the knowledge (E.g.: support engineers, product owners, etc). If someone has the same question again in the future, it will be easy to answer and everyone can do it. So...

OutSystems Mobile Team

Still a bad boy

Ok, so, it's set: internally, anyone should just go to the #rd-mobile-team slack channel for help (help is different from support). But we still don't want everyone in the team to be distracted.

OutSystems Mobile Team

  - Don't use @channel and @here unless it's critical. This alerts everyone in the channel that has notifications active for that channel. Someone will answer when it makes sense.
  - Maintenance only! Only the person in the team doing maintenance can reply unless it's critical. Block interruptions from the remaining team members and make sure 2 individuals aren't answering to the same request.
  - Wait: Yep, probably no one from the team will reply in the first 15-20 minutes. That's due to two main reasons:
    1) Most people ask without giving it a good previous thought (because it's so easy to just ask and some are just "rubber ducking")
    2) Maybe someone from support or similar will be in the channel with all the context and will help even better.

OutSystems Mobile Team

The not so bad boys

OutSystems Mobile Team

Slack is great to ask for help. But sometimes people just want to report a bug or provide feedback. Slack is not good for that. Mail the same. Why? We'll have to grab that feedback and create issues on our backlog. So, we opted-in for the internal tool that was already in use by other teams for this purpose. It's called Sauron and it's, in essence, a centralized way for all teams to receive feedback, prioritize and manage that feedback. Yep, we look at everything you provide as feedback (E.g.: Service Studio). Again, only the person doing maintenance can look at this tool for a given sprint. After the initial analysis, the maintenance member can decide all sorts of things, like the priority, impact, risk, etc. It can also send to another team if it fits or immediately to team backlog (if it's something that the team should work right away).

OutSystems Mobile Team

Customer success is our success

Ideally, we wouldn't have any support cases. And we wouldn't have support at all. The product would be so good and so intuitive for everyone that no customer would need help. We'll get there, dream high.
However, while we don't reach the sky, we do want to make sure every customer gets all the attention he deserves. So, we treat support cases in a different way. Whenever a customer opens a ticket and it escalates to R&D, we have to make sure we react fast. So, if support needs to escalate they will automatically open an issue to the team in our "special board", we get notified and the maintenance person will quickly look into it. Support provides all the info through that issue and we iterate really fast with them. It's a high speed lane to us.

OutSystems Mobile Team

All customer related issues coming through proper support channel has a huge advantage: centralized knowledge in support. Only strange issues require R&D escalation nowadays as support gets more and more expertise on the product. And all customer communication is done in one place.

OutSystems Mobile Team

Be helpful... Be helpful... Be helpful!

It's a big rule right? And we love it! So, we still want to help everyone and live, on our spot, is still an option. Just pick a good time for it (middle of the morning is not a good time, focus days are a nooooo please - unless you bring food) and, if possible, go directly to the maintenance guy. It's the one with the fire extinguisher.

OutSystems Mobile Team


Summing up, all this seems simple and pretty obvious right? Well, it is. But the "monster" didn't show up from one moment to the other. It was something that slowly appeared without us realizing. And it was a huge release by OutSystems, with everyone, including OutSystems developers still absorbing all the information. You can see that we still have a lot of communication channels. But it's ok. The issue was chaos. We have brought some sanity to the team and we can help in a much effective way. We are a happier team.

OutSystems Mobile Team

Sorry about the drawings. My skills are not that good and this was done on a plane. But hey, communicate to be understood :)

Friday, April 27, 2018

Funny code comments – zen

We've all been there: that moment you're so tired that you just do a crappy code and you place a comment admitting it's not good. That funny comment because you know someone will look to it later and laugh. Below is a compilation from several sources, grab a beer and have fun!







Shared in stackoverflow

Note: These were compiled from this Stackoverflow thread and this post.

.NET Core

We're doomed! (Source: ConcurrentExclusiveSchedulerPair.cs)

Maintenance (Source: Parallel.cs)

Zombies... (Source: Scheduling.cs)

Curve ball (Source: DebugTypeDescriptor.cs)

Legacy (Source: isymwrappercore.cs)

I can't prove it! (Source: EventLogInternal.cs)

Don't touch (Source: compareinfo.cs)

I don't understand (Source: methodbuilder.cs)

Hooker? (Source: console.cs)

Note: These are from a post I wrote in 2014
The .NET Core is OpenSource.

Saturday, April 21, 2018

Preliminaries are as important as the act – Part II

So, it's a "sexual" quote. True. But apply the idea to a public presentation. Most people don't give the appropriate importance to the preparation (preliminaries) and just focus on the presentation (the act). But the most important tasks for a good presentation don't happen during the event itself.

About 4 years ago I wrote an article on this topic, preparing a presentation. It was called "Preliminaries are as important as the act". This one is the sequel and is about improving your presentation skills.

The sequel

Jerry Seinfeld, in one of his stand-up shows, used to joke that speaking in public was number one fear for the average person:

Although part of a stand-up comedy act, it's somehow true. Do you ever get anxious before a big public presentation? Always feeling you could have done much better after the presentation? Well I did too. And that's ok: some people are natural speakers. I wasn't. So I had to work (a lot) to get where I am. If you ever been part of a sports team, you certainly witnessed that most of the work is done in practice, during the week. It's not when the game is on that one can improve a lot, it's when "nobody's watching. Cristiano Ronaldo didn't got to where he is by improving during matches only: it's mainly hard work that you don't' see. Performance in matches is just the result.

So, what to do if you think "you're not there yet" when it comes to public presentations? Work! Hard! Here's some preliminaries to have a good act:

1. Identify key aspects to improve: just saying you're not a good speaker doesn't help. Too vague. What's the real issue? Do you get nervous? Don't know what to do with your hands? Sweat? Write down all the issues.

2. One step at a time: don't try to improve everything from one presentation to the next. Overnight success is overrated. So, start with a couple of issues. Focus.

3. Talk to a mirror: out loud, with the same voice tone you use when presenting. How do you feel doing it?

4. Present to family/friends: Let's assume you like these people and you are comfortable around them in a social context. Great! Now do a presentation to them, doesn't matter the topic nor if they understand the content. Can you do it? Should be easy right? Maybe...

5. Record and review one presentation: then look at the full video and identify what you did like and didn't like. If possible, find someone to analyse it with you. Grab some beers, it will be fun.

6. Learn to work with your voice: I said this in the first article, but it's really important. Others hear your voice different than what you hear. That's due to the "Skull effect". Learn to vocalize for the audience and not how you like when you talk. What you hear is not what others hear.

7. Understand your body: Not everybody looks the same doing gestures with hands and so on. Maybe you look better moving around. Maybe you are 2 meters tall and moving all around makes you look clumsy and funny. Is that the image you want or not?

8. Build confidence: yes, it's a must. We're animals. We can smell "fear". So, you have to "look" confident, even if your not. Come on, these people took 1h of their precious time to listen to you, that's gotta mean something!

9. Contextualize: Contradicting a little the previous point, learn to put things in perspective. If someone told you that you only had 3 months to live, how important would the presentation be to you?

10. Expose yourself: have as much presentations as possible. If you only play one game per year, it's gonna be hard to master that game. To improve, you must see how things go live, fail, learn.

...2011... 2012... 2014...

I used to have all kinds of issues when I started 10 years ago. I would get nervous, always thinking I could have done much better afterwards. I would avoid exposure. I have great soft skills, always did, but I felt uncomfortable talking in public. But I knew that at some point in my career I would need (and want) to be a better speaker. So I went through a learning process. And I forced myself to it because I wanted to be better. For the first years I would do as much as 10 public presentations a year.

...2011... 2012... 2014...

Today I don't do them as much as I did because I don't feel the need to. Today I have fun when I'm on a stage. What about you?

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...