Let’s get some facts straight. Google does not apply resources in the quantities required to design, build, integrate, deploy and market so that they prop up the open source market. There is real profit motive in play and to suggest otherwise is disingenuous. Flutter is an attempt by Google to convert iPhone first to Android first by way of Android too.
the sum of the parts is not the sum but the average –Richard Bucker
Let’s be real for a minute. If you have the budget then you do not care about Flutter. You’ll have two teams or maybe three and you’ll develop your products in or out of parity. If you do not have the budget you’ll get the best team you can assemble based on what sales and marketing has on hand. If you have an iPhone sales team then that’s what you’re going to develop for because that’s how you perceive the market.
The problem with Flutter as a tool and platform is that it’s not stable. They seem to be relying on free resources to provide support. The documentation is poor and their howto videos are marketing infomercials for managers. It’s not until you actually try to bolt the iPhone and Android applications together that the pain starts… if not already as in my case.
So what did agile get wrong. One thing for sure. Releasing often or too often for one. Having a customer that is so huge that you cannot hear the feedback (when the customer is the population at large). And it is possible to release too early. As evidenced by the support team suggesting users use the unstable channels to solve problems.
this was accomplished before the internet and before Google. – Richard Bucker
In the 1980s I was hired to start work on a new payment system that was to become the anchor of the giftcard industry. At the time I was a DOS system and dbase programmer with some OS/2 internals and some OS/2 application development experience. I had already achieved my 10,00 hours so I was a rock star when it came to absorbing new tech. Within 3 months I built the giftcard system on Sun Solaris, Oracle SQL, Java, designed REST before it was REST, integrated the system into the company’s mainframe operations workflow, implemented an integrated IVR, and was the only after hours support person.
The one component I keep trying to forget is the help desk software that I wrote using some tools from CA (computer associates). I’m sure it was fine for some tasks but as a general purpose multi-platform application environment it sucked
. And I was too bold not to take the bullet early. The hard lesson I learned is that the sum of the parts is not the sum but the average
. Keep in mind that all of this was done without the internet and at the time Unix system admins were hoarding online and dead tree manuals.
So here’s the thing… I head to learn by experimenting with the tools at hand. I had to wait for the mail in order to get the next release and that could be weeks or months and sometimes years. But when I/we received a 1.0 release we knew what it was not production ready but effectively an early release. When 1.1 arrived we knew there was something there to work with. (see the Java language history). The next place was the bookstore. It was the next best place to get good information. I had hundreds of manuals that filled in the gap. At the time the software release cycle was slow enough that there was a book business behind it. (see pragmatic programmer and O’Reilly). And when all else failed there was the library or computer science department at any college.
building on top of crap is a waste of time even if there is time to market. The cost over time will be higher than just getting it right. –Richard Bucker
Now the internet is at warp speed and developers are dumping as much crap on the internet as they possibly can as fast as they can… is it marketing? Is it just to be relevant? Over the years I’ve brushed against peers who want to use the latest tool or toy until I’ve experienced it first hand. Early on it was about taking the lead by being the lead. Then it was about not having to support junk I did not believe in and not wanting to replace it with yet another piece of junk… it just misdirects the conversation to something that is nonsense.
tcl and expect are old enough not to have a logo
I’d previously written an orchestration system for vCloud. It served a particular purpose and was designed in functional silos. Now I’m building some orchestration tools for vSphere that solves a different problem. Now I need to deploy and configure different linux guests. All the cool people are using Chef, Puppet, Ansible, Teraform. I’ve experienced some of those but they are so complicated and worse for non-programmers that might need to support or deploy it. So this new tool is build on bash and expect. Silly me it just works and it exposes just enough for operations staff to use and with a little personal growth to extend.
So now the real rant is over and while I do not regret saying THIS IS NOT NORMAL on a flutter support site… I regret accepting management’s decision to use flutter. It’s just not normal.