Xojo 2019 R2, I mean API 2.0, Review

Lot of chatter in the blogosphere and forums about API 2.0. What do I think? 

I think renaming the events was a mistake. Not because the philosophy behind the changes is wrong but because the IDE was not designed for it. In fact, I cannot think of any language that renamed events on their standard library classes. It just does not happen. Events are part of the core contract of the whole object hierarchy and all code developed in an OOP fashion relies on the stability of those events. In other languages they would release a new class. 

The crux of the issue is the language and standard library are presented as a single entity in the IDE. It would be ridiculously awkward and painful if new projects started with AppV2 or WindowV2. Platform makers often just create entire new frameworks like WPF, UWP or WinForms. It is ridiculous, but it gives the developer choice. If I want to stick with my trustworthy but not entirely clear when it fires .Open() event I can just stick with Xojo Desktop v1. 

When you create a project, it should ask you "API v1 or API v2" and that's it. The constructs of classes having events is the same regardless of their names so why does the IDE care which version you use? All it needs to know is which library to use for code completion. The fact that the choice is not possible or was never considered is the part that makes event renaming as delivered a rookie platform mistake.

I am not as upset as I could be as there was an even more asinine change that we luckily got reverted. The <beta> class that we all use every day had been changed in ways that are completely and utterly mind boggling. Who is driving the technical direction here?

If I sold you a plugin and it did not work and I told you that I implemented .Open() and your use of .Opening() broke my code you would understand. It makes sense. It is annoying and one questions how or why this is possible, but it makes sense.

What if I had said the reason your code does not work was a subtle change to the default constructor that made the entire object immutable? All I would get back from you is a puzzled look. Likely, you would ask for clarification about why I mentioned the default constructor. 

That's right. Depending on the constructor you use, all properties silently changed their behavior and there is no way to know this in advance. If you have any existing code, you would reject using R2 on the premise that <beta> is completely and utterly borked. Funny, when they realized this, they changed the name of the class which is actually what should have been done in all cases of event, property, and method renaming.

Some of you will not use R2 because of event renaming but I promise you it could have been much worse. Worst part about all of this is R2 is actually a good release. Lots of things are fixed and improved and the database improvements without needing horrible prepared statements are much improved. However, there is also nothing shiny or stand out about the release. Subtle changes here and there give the appearance of a release with lots of effort, but it is mostly semantical nuances.

Array's moving from Append() to AddRow() is untenable for anyone with a computer science background. My thinking is in the future arrays can likely be used as a bindable data source and AddRow() represents the action occurring in the user interface. That's my imagination and hope for the product as I seek creative justification for these mostly pointless and subjective changes. All for the sake of a hypothetical future citizen developer who didn't buy and selected "did not understand the exact timing of Window open" on a marketing survey.  

The struggle is I don't know why API 2.0 exists at all as a version milestone. It does not move the product forward in any meaningful way. If Apple had not released macOS Catalina, then this release would serve no function. I am concerned these changes were built in a vacuum not mapped to any real-world deliverable. The time to optimize is when you release new things like DateTime. Release Web 2.0 with API 2.0. Release Android with API 2.0. Release an enhanced desktop framework with new controls like a date picker and database binding with API 2.0. Allow API 2.0 to grow out of necessity and not as a milestone in and of itself. 

The fact is if I use API 2.0 it won't improve my software and at the end of the day that is what creates Xojo renewals. Did my software just get a little bit better because I upgraded Xojo? Sadly, when it comes to R2, it does not. 

For the future I recommend being less ambitious and evolve more areas of the product simultaneously so timespans between meaningful new additions is not so great. Produce more meaningful new additions. We are coming up on a second XDC with nothing new for the platform to encourage new developers to use it. 

DevOps is PeopleOps

The skills required to automate all the things pales in comparison to the challenge of guiding disparate teams with very different objectives. 

A typical day can look like:

• Working with the business to understand the nature of the service being deployed. 
  
  Do we need to support one hundred partners or ten thousand customers?
  
  

• Providing architecture advice to developers that will help them scale.
  
  Should we use Product X or Service Y? 
  What/when/where should we cache data?
  
  Sometimes the best product, service, or choice does not fit into your larger architecture. The DevOps personnel often have the quarterback view.
  
  

• Train development and infrastructure teams on the benefits and usage of automation. 
  
  While they generally understand the value proposition, they often misunderstand the extent to which the other is utilizing it. Overly ambitious automation projects often fail because they skipped too many transition steps.
  
  Start with small steps that both teams can adopt and slowly build on a common foundation together.
  
  

• Demonstrating how technology teams can deliver faster value to the business.
  
  As you slowly develop your automation the teams discover they are able to iterate faster than ever before. This provides opportunity for them to take ownership of smaller releases more often.  
  
  

• Developing automation pipelines to enable seamless development, testing, and production environments.
  
  Once you have a good sense of your developer’s workflow you can ultimately build a great development environment. Reproducing or emulating production systems helps with building more reliable software.
  
  Improving the development environment setup is also critical when onboarding new developers. The faster they are productive and contributing the more successful your project will be.
  
  

• Documenting systems requirements so infrastructure teams can develop lifecycle support systems (monitoring, backup, intrusion detection, etc.).
  
  Infrastructure as code helps with this tremendously. However, there is also acquisition of new cloud resources, regulatory tools, and staffing to consider when going live.
  
  The DevOps team can build that bridge to make sure the right tools are procured, and all regulatory, business, and security requirements are being met.
  
  

•  Supervise said systems and validate they meet the needs of all team constituents.
  
  Throughout the development and procurement processes the DevOps engineer becomes responsible for validating the pieces fit correctly. Ultimately, they will be the ones calling meetings and developing compromises when difficult architectural decisions have to be made.
  
  

• Develop opportunities for team members to take ownership of different aspects of the automation.
  
  The best running systems are the ones where team members are engaged to the processes and outcome. The best way I have found to do that is develop leaders in different parts of the stack who become subject matter experts.
  
  

• Writing custom tools to serve as the glue between the manual and automated worlds. 
  
  Sometimes as a DevOps engineer you just have to write some code. Building the perfect system is impossible and so you are constantly faced with a moving target as your organization moves towards CI/CD.
  
  This means having to write a lot of code to handle assumptions or decisions that were made yesterday that are no longer true.
  

Despite your DevOps engineers generally being some of your more senior team members their role is not purely technical. In fact, the technical skills required to automate these systems is trivial to any developer.

The actual challenge is working with the stakeholders to:

• Enable developer productivity and flexibility.

• Increase development speed.

• Provide products/services the business can iterate on quickly.

• Not completely destroying the infrastructure and lessons learned that are already in place.

• Providing training and leadership to infrastructure and developers alike not used to these processes.

For that you need someone who above all else can forge great working relationships with your development, infrastructure, and business teams alike.

My XDC 2019 Feelings

I had a good time. It was as good as you could possibly expect from a programming conference in Miami. I met new friends, old friends, customers, and team Xojo. I walked away optimistic about Web 2.0, excited about upcoming opportunities, and confused about why Xojo is so secretive online.

The truth is time and time again you hear people admire the conversations with engineers and general comradery at XDC. I had good discussions with a few on the team and generally felt like I was a valuable member of the community.

I do struggle in some areas though.

Throughout the conference many raised concerns about the lack of engineers on the team. Geoff was always prepared for the question and was insistent that they are staffed appropriately for their current needs and roadmap. I believe them. Frankly, the roadmap has not expanded, and some items like plugins (built in Xojo) have been completely dropped. I see some efforts to align efforts with reality.

While discussing estimates and why Xojo does not commit to timelines Geoff said they try to “manage our expectations”. I believe Xojo should be releasing numerous builds even in early stages. Monthly alpha builds at a minimum. Soliciting our feedback on the design goals and direction earlier on would be very valuable for us. I don’t pay Xojo to manage my expectations of their product. I pay them to develop it and I would be happier if I knew the direction it was going in.

I wish Xojo was prouder of their third-party ecosystem. The design award to GraffitiSuite was great and deserved and I’m sure MBS has earned them in the past. At the same time outside of a single session I didn’t see a general awareness for the third-party ecosystem. More plugin and providers should be showcased. While self-serving, I wish there was a certified hosting program. ServerWarp would love to be a certified Xojo web host. Someone at XDC mentioned why there was no section for vendors. I whole heartedly agree.

Everyone believes they attempt to do too much.

I think everyone in the conference was in awe at the tremendous effort and progress of the overall platform. However, it is painfully obvious to us that while engineer staffing may be optimal the overall ecosystem is not healthy. Statistics and marketing data presented to us suggests that the number of women and young people has risen. Yet forum participation and general Xojo developer penetration seems flat or worse. It does not seem entirely impossible that perhaps the number of adult males has simply declined. 

During the final feedback session Geoff was great. He talks about vision and opportunity. Yet, I find myself disgruntled because I am convinced the company lacks technical vision. Nowhere in the conference did we see anything awe inspiring or cutting edge from Xojo. Just further iteration on the same old ideas and concepts with the same limitations and caveats. 

Upon later reflection I realized that Xojo has quietly made some very strong and strategic technical choices. For a long time, they suffered from tremendous “not invented here syndrome” and would recreate everything. Custom database server? Check. Custom HTTP socket? Check. Custom web framework? Check.

Yet more and more these items are being deprecated. Engineering efforts now are on pulling in the best and most accessible libraries available and simplifying them for us. The potential output of any given engineer is likely doubled or tripled due to the reliance on more third-party code. The new web framework for example is relying heavily on bootstrap and jQuery and various other user interface libraries. Interops is designed specifically to make utilizing operating system libraries easier so Xojo itself can iterate faster.

I think the keynote was lackluster because they were unable to communicate how much impact the new technical investments are going to have. As soon as web framework 2.0 is done they will be able to create considerably more controls very quickly. Plus, I hope they are dog-fooding their own Web SDK as much as possible. Android even if terrible will open several new doors and channels to insert Xojo into the conversation. 

So now it is more confusion for me versus disappointment. They apparently do have technical vision but are completely incapable or unwilling to share it. No blogs or forum posts about new abilities or plans. No videos highlighting features being copied from other languages and frameworks. You don’t see the passion and drive that fuels this effort, so it feels hollow. Like a grind. And it becomes one for us constantly following along hoping our feedback request gets fixed and our subscription renewal becomes worthwhile once again.

What do I want?

Monthly alpha builds
Certified third party ecosystem for plugins AND services
Less management of my expectations

I think a little more effort into battling the not invented here syndrome when it comes to community and the third-party market would change the game. If you aspire to be more than just a secret weapon you need to shepherd its growth versus dictating it.

XDC is about being a part of the conversation. Being heard. It should not take a physical gathering to keep that spirit alive.