This is the fourth part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.
The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1
The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2
The third part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part3
-----
Bob Keeney writes in his latest piece that “software development is fluid” [1]. Always changing, evolving, and not easy to schedule around. It is a nice analogy and I get the underlying message. There has been a current on the forums that maybe Xojo does not do enough to resolve bugs. Perhaps they are too focused on new stuff that important issues do not get addressed. Bob is writing a piece here defending Xojo, their development style, and the complexity of what they are trying to achieve.
I think like most in this niche of software consulting we rely on Xojo being a reliable product. Our success in some ways is tied to theirs. Let me rephrase that a bit: Xojo consultants would prefer to stay Xojo consultants versus primarily using other tools. He wants to promote the tool he likes so much and so do I. Most in the community are like minded in that way.
Many of his arguments I suspect are valid and reasonable. I think for the most part you see this throughout the Xojo community. We all recognize how challenging it is to run a small software company. Some part of us appreciates Xojo on a fundamental level. We also become have become proficient with it and it enables us to get more done.
However, there are times when it holds you back. A new release breaks something or a new feature does not work as expected. The community lights up then and the argument remains:
- Why do you not give us more heads up on what you are doing?
- Why do we not get more time to test?
- Why are there not more testers?
- Why do bug reports take so long to get fixed?
It can get pretty excited at times and it is not unheard of for a thread or two to get locked shortly after a release. I love this part of the community because everyone is so invested in the product.
When you look at issue trackers and forums for open source languages it is rather dull. Many times there are few that are invested in a language because you are only one console command away from installing an entirely new development stack. The questions are highly abstract and technical and the responses are typically slow and methodical.
I comment aggressively on the Xojo forums that I wish the (Xojo) engineers would tell us more, show us more, give us more. Sometimes they fire back and have told me that being on the forums is not in their job description. Nonsense. If the Xojo engineers left the forums the community would be harmed. The Xojo engineers are not just part of Xojo they are also part of the community. They would miss us as well.
We all want to enjoy where we work. We push Xojo pretty hard and that is healthy but we also have to make sure we are not making it intolerable to work at Xojo. Like Bob said we need to do our part with bug testing, writing open source code, and helping others in the forums. However, the community is not to blame when regressions hit and progress slows. Some part of it is due to the enormous nature of what Xojo is trying to accomplish. The other part is the secretive nature in which they do it.
This is why in Part 2 of this series I suggested open sourcing the standard library; The mish mash of libraries and classes in either Xojo, C++, or third-party libraries. When bugs are encountered in the “framework” it can force you to use a different version of the product. The sad truth is regardless of the difficulty of a bug report it may not lead to a timely resolution. Often times you will get a confirmation and then wait several releases. You have no idea if they have even scheduled to start fixing it.
I feel like if Xojo is not going to commit to fixing something in a reasonable timeline then that would be a great opportunity to ask the community to attempt it. Let us earn badges or points or something. Give the top 5 every month a coupon for example. I am thinking bug bounty board meets achievement points. We don’t need any cash or prizes but recognition to the community for being involved. Most importantly let us help you chisel away at the issue list.
If there is a problem with Bob’s piece I would say my only nitpick is I don’t think software development is fluid at all. In fact, I think it is solid. Solid like a giant rock that has remained stationary for millions of years.
Software development is like sculpture as you chisel 0’s and 1’s into a rock face. You spend so much time planning and considering the subject matter and problem at stake. You design and architect the database, storage, and architectural nuances of how messages get from one method to another. You consider deployment strategies and security concepts to protect your users and not leak your database to Reddit. You do all of this in the hopes perhaps you will achieve something great. “Something great” more often than not is a tool or utility to create more software to manipulate even more 0’s and 1’s.
I say solid as a rock because even with source control, undo, snapshots, checkpoints, auto-saves, and screen recording you can’t save a bad program. It takes too much work and the amount of effort to resolve the plumbing job of a poorly planned program is terrifying. You start dreaming up ways to convince your client or boss that it would be best to start anew. As you mature you realize this is not always a practical strategy and so you are going to have to do surgery more often than not. You are desperately hoping not to chisel the last bit of support that keeps the rock standing up.
I am not convinced software is fluid at all.
I am convinced Xojo makes for a great chisel.
I also believe the Xojo community is part of the value proposition of the product. For example I search the forums before I search the documentation. Thank you forum.xojo.com.
-----
[1] = http://www.bkeeneybriefs.com/2017/08/software-development-is-fluid/