Front-End development technologies come and go. In my experience, they have been the single most volatile part of software. Their lifespan seems to be very short (5-10 years).

Why are they so volatile?

• Probably because the devices the users interact with evolve far faster than what they don’t interact with (back-end, databases and such);
• Users now expect more. Back in the day, users would happily use whatever software they had to automate their work. That has changed over the years as most people have their own personal computers and devices, which they use for way more things than just “boring accounting and payroll systems”. Also, since the first iPhone came out, users have learned to expect software to be more intuitive. And now “there’s an app for everything”, and for each app, there are likely multiple options to choose from.

Since the late ’90s, I’ve worked on a huge number of software “rewrites”. Most of them were really painful and time-consuming. Why so?

Main reasons:

• Developers put way too much code on the front-end;
• In most “rewrites”, people simply want to replace the old with the new, making the new one look and behave like the old one, but on a different platform

Every time a new front-end toy comes out, I’m mostly interested in seeing how developers are writing code in it. More often than not, I see the same pattern over and over: a TON of code put right there in the front-end. Knowing that these frameworks and libraries aren’t like to last more than 5-10 years (by last I mean to be continuous developed), I know that a rewrite for such software means, well, rewriting all of that code!!

For the most part, the front-end part of software should simply allow the user to ask questions to the system and see responses. That’s it. Present the users with what they need to formulate questions, and then show them the answers in the best way possible (which could mean, fast, or illustrated with charts, or whatever it takes to give users the insight they need in that moment of time). In certain scenarios, it may be crytical to have most of the processing happening on the front-end, but those are the exception, not the rule.

Don’t get me wrong: I used to jump at every new shiny toy, too. There was a time when Microsoft put out a new toy called LightSwitch. That was probably the first time I looked at a new toy and thought “hmm, I don’t think that thing will last long”.

I didn’t quite recall when it went away, but found out on a quick search that its lifecycle started on Oct 30, 2011, and it’s mainstream support ended on Jan 1, 2017. The official death announcement states that “the landscape has changed significantly from the time when we first thought about LightSwitch”.

Such a shame. I had worked so hard on adding LightSwitch to my resume. I had even documented my proficiency with it on this short 45-second video!

Technical Communities may be the single most important factor I’ve had (and continue to have) in building my professional career. Yes, that’s how important I believe they are.

I first got involved with communities back in the late ’90s. I got a job where I got to work with FoxPro, which I knew nothing about other than that it looked similar to what I knew at the time: Clipper and dBase. That was also around the time the internet was becoming a thing in Brazil in the days of dial-up connections.

In order to get up and running on the required tech stack, I found online forums in Portuguese.

There were many resources in English for FoxPro, but not a lot in Portuguese. I knew some English at the time. Many Brazilian developers didn’t. So here’s what I did: I’d see people’s questions in the online forums, look up the answers in English on the web, and reply to the posts in Portuguese. Why did I get from doing that?

• I learned a lot of FoxPro in a short period of time
• I learned a lot of English
• I helped other fellow developers

A member of the community invited me for lunch one day and gave me a couple of FoxPro books. I asked the reason for the gift, and he said: “If I help 100 people, maybe one of them will give me a hand in a moment when I could really use some help”. I have taken that lesson to heart and applied it to my life deliberately ever since.

Because I was answering so many questions, people thought I was an expert.

When a new version of FoxPro was about to come out, members of the community reached out to the Microsoft office in Sao Paulo to ask if there was going to be an official launch event. The MS manager said they could do that, but there were no MS employees in Brazil who were well-versed in FoxPro. The community member said, “well, problem solved: I know a guy”. Next thing I know, I’m presenting two full-day, soldout launch events. Attendance included people flying from other states (if you don’t know how big Brazil is, please pick up a map…)!

So that’s how I broke into technical public speaking. Next, I got into writing articles, creating a magazine, organizing conferences in a few different States, organizing study groups, creating training videos…

So much came out of the common need to learn a new tech stack, followed by the simple action of helping others along the way, with however little I knew of anything.

The fact that I’ve been living in the US since 2002 is directly related to this involvement with technical communities.

See why I have a cute fox as part of my office decor? Never forget where you come from!

Also, when some youngsters make smartass comments about the mention of FoxPro on my business card, I may just say: “sit down, kid, let me tell you a story…” 😉

Three years ago I decided to try out Xamarin. Given my experience with C# and WPF/Xaml, it seemed to make sense. I spent about 4 hours following some tutorial online and got the sample application up and running. Two months later, I tried to pick it back up: I launched the idea, hit “run”, and got some compilation error that didn’t tell me a whole log. After a lot of digging around on the web, I found out I had to update Xcode. After I did, the error in Visual Studio for Mac went away. Other priorities made me put that all aside for a while.

Last weekend, I gave in and decided to pick it up again. I have an idea for a mobile app that would help me with one of my hobbies and thought Xamarin would be the quickest way for me to get it done. The first feature for the app is a simple to-do list. That’s just a step away from the typical Hello World app, isn’t it?

After 6 hours of struggling, I gave up.

I was trying to use JetBrains Rider as the IDE. I thought of creating a Xamarin.Forms app, as it seemed the easiest way to have my app available both to iPhone and Android devices. I didn’t get passed creating the project, as it kept telling me that the “Android SDK is not installed”, even after installing all the Android things I’ve found out about; things that ate up 20Gb of my disk space, and I still couldn’t create the project.

I then decided to only target iOS: maybe if I at least got the app on my iPhone I’d find motivation to figure the Android deal later.

The project got created and I just tried to run it in the iPhone emulator (I didn’t write any code or change anything). Found some references online about Xcode, made sure to update it, but still, no luck.

Then, I tried to deploy it to my iPhone. First got errors about the Apple certificate needed. My Apple Dev membership expired years ago, so I renewed it ($107!). Got the certificate, then started getting errors about “Provisioning Profile”. Got it created, did what I told to do, as per online resources, and moved on to the next error: [MSB6006] “dsymutil” exited with code 1.

After some research on the error and not liking the answers I’ve found, I gave up. Six hours had gone by and I couldn’t successfully create and run a brand new project.

I’ll be trying Flutter next. Let’s see how that goes…

Have you ever seen any business that doesn’t make heavy use of spreadsheets? Right, me neither.

Here’s a technique I often use when working with a new client: I ask them “Show me your Spreadsheets!”

A lot of decision makers base their decisions off this or that spreadsheet. Even when there’s a costly ERP system involved, they normally use the “Export to Excel” feature, and then play with the data to find the answers to the questions they have.

Those questions they’re asking are often the most important part in their decision-making process. I want to know:

• What are those questions?
• Why are they important?
• Does the person have to enter additional data on the spreadsheet? if so, why is it not already captured in the system?

There are also cases where users export some data out to Excel and email the results out to somebody. I ask the users why they need to send that data and how it’s used. If they don’t know, I’ll go ask the recipient, which then may take me to the questions listed above.

This type of conversation of the clients, end users, businesses, help quite a bit in identifying the real business needs and them providing them the best solution (which could be a matter of addressing a workflow, coming up with a process, creating new software or changing existing ones, or a combination of those elements).

So, the next time you’re working with a client, give it a go: show me your spreadsheets!