U.S. News an World Report just ranked Software Developer as the best job for 2018. They use data from the U.S. Bureau of Labor and Statistics to rank jobs based on pay, job security, mental engagement, stress, room to advance, satisfaction, and work-life balance. Since you are here, you most likely agree with that ranking and are surprised it took so long for someone else to recognize it.
This means we will see a lot of people interesting in software development. Anyone looking for a better job is likely to start at the top of that list and work their way down until they find one they are interested in. Not to mention everyone who sees the headlines about Software Developer replacing Dentist as the #1 Best Job. Whatever the reason, software developers will get a lot more attention.
When I’m talking to people about career advice I think it is more important to choose a career that suits the individual (internal factors) than basing the decision purely on external factors like pay, etc. That being said, I honestly believe Software Development is only going to get more important. Going forward, software development and related jobs (many of which aren’t even invented yet) will consume the many of the other jobs as automation and artificial intelligence take over more aspects of our life. It all depends on which side of the automation revolution you want to be.
When I was really young (like 3rd grade) I knew I wanted to program computers for a living. A family friend told me that I should look for a different job because by the time I entered the career market computers would be programming themselves and there would be no jobs. I remember thinking once that happens there would be no jobs, and someone would need to teach the computers how to program themselves better.
Just recently I was in Tokyo for the 10.2 launch event. I was talking to members of the press, and one of them made a similar assertion “What is the point of releasing better developer tools when soon computers will be programming themselves?” I shared the story from when I was a kid and said that “Yes, AI is automating and consuming other jobs, but the programmer will be the last to go. Once AI’s no longer need humans to make them better there will be no jobs for anyone!”
If you aren’t familiar with the Law of the Instrument, otherwise known as Maslow’s hammer/gavel, or the golden hammer it is often expressed as
If your only tool is a hammer, you treat everything as like a nail.
My understanding is that the law of the instrument means you are limited by instruments or tools you know how to use. For example, if you have a screw, some wood, and a hammer, then you might successfully get the screw into the wood, but a screwdriver would be a better alternative.
The law of the instrument also means an obsession with the perfection of the instruments you know. I remember back in the day when I was convinced there was no reason to bother with any other programming languages because Delphi was the best. Now I’ve spent some time using a lot of other programming languages, and so I can confidently say Delphi is the best, while I can see the value and use of other programming languages.
I believe it is worthwhile learning about new technologies, frameworks, languages, or methodologies. Then you can pick the correct one for the job. This doesn’t mean you need to be an expert in all of them, but you should know enough that you are confident in your choice.
The reverse of this is the obsession to chase new and exciting technologies and recreate things every few years. This keeps the developers entertained, but doesn’t really provide business value. Again I believe Delphi does a good job with this as it respects your existing code while moving forward to new platforms, features, and frameworks.
So what is the Curse of the Programmer?
When I’m talking to other programmers I see two behaviors. The first is, every problem they encounter in life (at work and beyond) they respond with “I could write a program to do this,” or some variation. By extension, they also cast a critical eye toward any software system (even those developed by themselves) to see how to do them better. This results in a huge backlog of projects that they create to fix problems, fix a problem better, or just out of curiosity to see if they can.
This is similar to the Law of the Instrument, but I see it more as your learning the flexibility and power of programming results in your seeing many opportunities to apply it. I’ve talked to people in other industries, and I think the general tendency is fairly universal, it is just that programming is (in my opinion) so much more powerful and flexible than many other applied technologies.
The second behavior, which is something to be more cautious about falling into, is the urge to create a “library” or “framework” instead of finishing the program at hand. For example, you are creating a program to solve a problem, and in the process, you create series of libraries just in case you need to solve similar problems.
There is value in having reusable libraries, functions, components, and frameworks. The trick is to not let the creation of them get in the way of shipping. The best way I’ve found to deal with this is to only create the library when you need it. Write your code with the appropriate level of coupling to solve the problem at hand. When you need to reuse a bit of it elsewhere, consider refactoring it into something reusable. Then as you use it in more places you can keep refactoring it and expanding it until you have a full blown framework.
How do you see the Curse of the Programmer in your life? What do you use to prevent every project from spawning a series of reusable frameworks?
MS Crypto — this is the Pseudo Random Number Generator (PRNG)
DISQLite — Some of 1Password’s features – such as Watchtower, for example – are utilizing SQLite. Because 1Password 4 is in Delphi 2007, we use DISQLite for that (today, it would be using FireDAC for that)
dxgettext — this is used to localize 1Password. It works nicely with Crowdin, a localization project management platform
At one point there was some attempts made to make a list of devices that were supported either completely or partially, but new devices were coming to quick to track. This lead to the misconception that FireMonkey apps only run on a very small subset of Android devices.
Since that time there have been a number of improvements to the compiler and the FireMonkey framework. Also the landscape of Android devices continues to evolve and change. Yet I still run into people who believe that FireMonkey still only runs on a small subset of devices. I thought I would provide an update and set the record straight.
Tegra 2 and NEON
Shortly before Android support was added, the Tegra 2 processor was in use. It was ARMv7 and Cortex-A, but lacked the NEON SIMD extension. So what is NEON? NEON is a SIMD (Single Instruction Multiple Data) instruction set. When it was introduced it was an option that some ARMv7 processors included to improve performance. Since it was optional, the Tegra 2 excluded it.
It seems kind of uncertain to have some processors with some features, and others missing them, especially if you require them for your application to run. This isn’t some crazy thing that only happened with Android and ARM. Back in the time of the Intel 486 CPU (right before things went Pentium) some systems had an optional 487 math co-processor. This co-processor introduced some additional x87 instructions that accelerated some floating point operations. Some programs would be faster on a machine with x87 support, and others required it. When the Pentium came out, it incorporated the x87 instructions into most of the CPUs (there are always exceptions).
The Pentium didn’t end up being the “One CPU to rule them all” though. Along came MMX Instructions. MMX is a is a single instruction, multiple data (SIMD) instruction set that was optional for some CPUs (where have I heard that before?) Some programs were faster on an MMX enabled CPU, and others required it to run at all. After a few years, most all CPUs, even those made by AMD included MMX instructions. It didn’t end there. New CPU instruction sets are introduced all the time, but it is rare that they get the same publicity that MMX or the x87 set did.
What does all of this have to do with NEON, besides perspective? Well, Neon is now part of the ARM standard. The new ARM chips in modern Android devices include Neon. They don’t even both listing it as a feature because it is assumed. The R&D team bet on NEON and they won. Since the compiler takes advantage of Neon instructions it is faster than it would be if they hedged their bets and ignored Neon.
Enter the GPU
Much like the x87 was a separate processor that augmented the system performance, there are many other processors in your computer, specifically around audio and graphics. The big thing about the GPU is that it not only beefed up the existing graphics co-processors, but it took on the 3D and texture operations and ran them through a massively parallel architecture. The original GPU that I had was actually a separate board in addition to my graphics card. Today they are mostly integrated.
On Android they typically go with a System on a Chip (SOC) that includes the CPU, GPU and a number of the other electronics.
The Rise and Fall of Intel Atom
ARM is an open standard CPU manufactured by many different chip makers, often times under their own brand. A few manufactures include Qualcomm, Texas Instruments, Samsung and even Apple (for their mobile devices). Intel wanted a piece of the mobile processor action, but instead of just implementing ARM they introduced the Atom processor. It still used the x86 instruction set of the desktop CPUs, but was designed to be more energy efficient. They put them in Windows tablets and Android devices.
This introduced another division in the Android landscape. There were two different processor architectures. Since most Android apps were written with Java and ran in a virtual machine, it wasn’t a huge deal. Except for games. Most games use native code for performance reasons, so that required either the game to include both ARM and Atom code and libraries, or the game just wouldn’t work on Atom.
Enter libHoudini. Intel realized that mobile gaming was a big part of Android, and the fact that you couldn’t play a lot of popular games on Atom devices wasn’t good. So they created libHoudini, a proprietary ARM translation layer that translates ARM instructions into x86 instructions for the Atom processor.
libHoudini was around for a while, but around Jelly Bean or KitKat it became standard on Atom based Android devices. This resulted in ARM native apps just working on Atom devices.
Embarcadero was actually in discussions with Intel. There was talk of making an Atom targeted compiler for Android, but work was also done to improve compatibility with libHoudini. Atom was never officially supported (mostly because the market share was too small) so the Android app packager includes a check to say it didn’t work with Atom processors. But you can remove that checker and your app will probably run great on most Atom devices.
Unlike Apple, new version updates don’t tend to roll out as fast on Android devices. This means you typically encounter a few different versions of Android running in the wild. It isn’t all that bad though. In my opinion, Ice Cream Sandwich (API 15) was really when Android came into its own. It was Honeycomb (API 14) that finally gave tablets some serious love, and ICS merged those new features back to phones. Anything before ICS is really legacy at this point (at least in my opinion). Android tracks the popularity of Android versions on their Developer Dashboard.
Ice Cream Sandwich and older only account for a total of 4.3% of Android devices. While there are feature differences between the top 3, nothing is too revolutionary as to make the others obsolete yet.
A Thousand Flowers
Unlike iOS, where Apple is the only company to make devices that run it, Android is EVERYWHERE! I guess I’m kind of a collector of Android devices. I owned the first Android powered watch by WIMM and even created a 6 sided dice app for it. Now that Delphi supports Android I love testing it on different Android devices. Here is a list of my findings
Android Wear – I’ve tested 4 or 5 different Android wear devices, including the Moto 360, and they all worked flawlessly with FireMonkey.
Google Glass – Again, worked out of the box with FireMonkey. We even later added official support. Unfortunately Google is reimagining Glass right now, but I suspect when then new version comes out it will work great.
Epson Moverio BT-200 – Similar to Google Glass, but has two independent translucent lenses so it can do 3D. Runs Android Jelly Bean and works with FireMonkey right out of the box. There is a BT-300 coming soon.
Ouya – This was the Android gaming console that was going to change the world. It ended up under delivering, and then not evolving fast enough. It does however run FireMonkey just fine, and I know a few developers who used it for creative projects.
Amazon FireTV and Fire TV Stick – Designed to work with your TV and running Amazon’s own version of Android. Again worked like a charm with FireMonkey.
Amazon Fire Phone – I think this is a pretty cool device, a shame it didn’t catch on. Also runs FireMonkey apps fine.
Amazon Kindle Tablets – I’ve not tested these, but I know people who have. Again it runs a different flavor of Android. From what I hear some people had to update their OS to get it to work with FireMonkey, but it did work.
BlackBerry Phone – Yeah, I went there, and so did FireMonkey. It worked too, although there are some idiosyncrasies about the OS that show up when you invoke the share sheet. I originally tested it on the BlackBerry OS, which supports Android apps, but now they’ve gone full Android.
Windows Phone 10 – My Windows Phone wouldn’t install the right preview of Windows 10, but Marco had better luck than I and got FireMonkey apps running on Windows 10 Phone under the Astoria bridge. Then Microsoft discontinued it. Windows Phone never had much market share, and continues to dwindle.
Huge collection of tablets and phones, including one with an Atom processor – they all worked (except that one old Tegra 2 tablet that ran Gingerbread).
Since Android is everywhere I’d wager that there is no Android app that actually runs on every single Android device out there, I don’t care what you wrote it with. Now if someone wants to prove me wrong, that is fine, I suspect different Android devices will be released faster than we can test them.
Let’s run through those requirements again and see how big of an impact they really represent.
ARM Cortex-A series CPU – Atom was never big, and is on its way out. Most everything else is ARM Cortex-A (or newer / compatible).
ARMv7 Instructions – ARMv6 is either really old, or used in a micro device like a beacon or some other IoT device. Not in any Android devices. Oh, and ARMv8 is the big thing now. It is 64-bit and runs FireMonkey apps fine.
NEON Technology – Like I said, it is part of the standard now, so unless you have an old Tegra 2 tablet (I still have one) then nothing to worry about.
GPU – All of the GPU compatibility and performance issues I know of have been fixed, and GPUs are standard on Android devices (at least ones with a screen).
Specific versions of Android – Only 2.3% of devices have an unsupported version of Android.
So while FireMonkey apps may not run on every single Android device in existence, most apps don’t and no app needs to. FireMonkey apps to run on the vast majority of them, and that is what matters.
I was chatting with someone today who was less familiar with Delphi. He asked what is it about Delphi that makes so many people continue to love it. I thought I would share my answer and see what everyone else thinks.
Developer productivity – When Delphi was first introduced it was going head to head with Visual Basic in getting things done fast, and most of the time Delphi was faster for getting things done, and the rest of the time it was still really fast. That continues today. I’ve done presentations for people and they blown away with how fast I can do things with Delphi.
Fast native apps – When it comes to app performance Delphi was way faster than VB and is competitive with Visual C++ and any other compiler out there. This is because it builds native apps that run fast.
Database access – One of the original goal of Delphi was first class database connectivity. That is something Delphi continues to deliver. BDE was ahead of its time, but FireDAC is a whole new breed. And the great thing is there are so many 3rd party data access libraries to choose from, to give you just the right set of features you need.
Platform API access – I remember the first time I needed to access some Windows messages and a Windows API that wasn’t exposed through the RTL. I kind of expected it to be a lot of work. I was pleasantly surprised with how easy and natural it was to add that to my program. I love that Delphi lets you work at the nice high productive level, and then reach down to “touch the metal” and access the APIs.
Visual form designers – I’ll admit it, Delphi has spoiled me. I’ve checked out a number of other programming tools, and it is rare to find one that works as good. The ability to design your user interface and preview what it will look like so easily is so useful.
Reliable applications – I’ve heard stories about when they demonstrated Delphi’s ability to handle exceptions and people were falling out of their chairs. I don’t know what it is about Delphi, it might just be that the developers who use it are amazing, but I am frequently impressed with how reliable programs are that are developed with Delphi.
Good strong community – All the Tech Partners, MVPs, authors, trainers, and developers make the Delphi community amazing. It is always great to see all the amazing projects everyone is working on. So many people willing to help and just be fantastic. It is a great community to be part of.
I made this graphic a while ago to explain why developing with Delphi was so awesome. I call it the three levels of development. The idea is each level builds on the one beneath it. The higher levels provide great productivity benefits.
The great thing about Delphi is it lets you easily move between these levels. You can do so much in code, even at design time, but it doesn’t keep you at that high level. When you need it you can move down to a lower level, even to the point of writing inline assembly code on Win32.
Most other development tools are stuck at just one level, or with just bits and pieces of the other levels. Delphi gives you all 3 working together. This is really amazing, especially for a cross platform development tool.
What did I miss? What else is in Delphi’s DNA? What is the one thing that makes Delphi the tool of choice for you?
Update: A few more characteristics of Delphi’s DNA from the comments
Readability and Maintainability – This is really important since most programs spend way more time being maintained than in the initial writing. Code that is easier to read is easier to maintain. This is aided by the fact Delphi is easy to read and has a strong type system.
Backward Compatibility – This is something Delphi really spoils us with. Even when there are breaking changes they are typically minor and easy to work around when compared to other development technologies.
Speed – Delphi has this in spades: Speed of development, speed of compilation, and speed of execution. Sure, you may be able to find some situations where something is faster in one area, but over all Delphi is very well rounded in the speed department.
I’m curious what tips and techniques you have for solving bugs, especially those really nasty ones. Are there specific tools your use? I know there is a lot of functionality in the Delphi debugger, much of which is rarely used to its fullest potential.
Monday’s podcast will feature an interview with RemObject‘s marc hoffman. Delphi Prism has been released, and it is powered by the RemObjects Oxygene compiler. If you have any questions about the Oxygene Compiler then this is your opportunity to ask them of marc, as he is the Chief Software Architect for RemObjects.
Please, leave your questions in the box below, and I will cover what I can with marc. Remember, keep your questions focused on Oxygene and RemObjects as marc won’t be able to answer questions on behalf of CodeGear or Embarcadero.