Jump to content
Jacek Laskowski

Delphi, be better!

Recommended Posts

Comment accompanying the new edition of Android Studio 3.3.
 

"Based on the feedback from many of you, we have taken a step back from large features to focus on our quality fundamentals. The goal is to ensure Android Studio continues to help you stay productive in making great apps for Android. Since the last stable release, Android Studio 3.3 addresses over 200 user- reported bugs. "


Can Embarcadero go this way?

 

https://android-developers.googleblog.com/2019/01/android-studio-33.html

Edited by Jacek Laskowski

Share this post


Link to post

It is not about the number of errors, but about the direction, please read the quote again.

In addition, the number of bugs fixed in Delphi covers a year, in Andoid Studio, less than 4 months.

Share this post


Link to post
1 hour ago, Jacek Laskowski said:

In addition, the number of bugs fixed in Delphi covers a year,

To be fair, it is 8 months from Delphi 10.2.3 to 10.3

Share this post


Link to post
1 hour ago, Jacek Laskowski said:

It is not about the number of errors, but about the direction

What would you like to see that would improve the situation? This is bearing in mind that given the quote "we have taken a step back from large features to focus on our quality fundamentals", large features are out.

Share this post


Link to post

"Focus on quality" actually means, we massively screw things up, and we need some time to clear this mess before we start adding new features.

 

Having said that, all software has bugs, especially this complex (talking both about Delphi and Android Studio). New features generally add more bugs - both because they are new and not completely tested (in production) and because often they require changes in existing code, breaking old features, too.

 

I am not going to compare how Google does things vs how Embarcadero does things, because it would be comparing apples to oranges. If nothing else Google releases updates almost on weekly basis. And when they really make mess, they will issue patch even on Sunday. On the other hand, those fast releases (Canary and Beta channel) are quite often really buggy, so you get what you ask for. But you have a choice and you can choose to use more or less stable update channels.

 

As far as Android Studio stable releases and their quality is concerned, the whole 3.x series have been complete disaster. 3.0 was more or less OK, but everything else was nightmare until the latest patch. I cannot say that I am exactly thrilled with its quality and how long it took them to put things back on track (where they were). Not that I am thrilled with Delphi quality either. 

 

Point is, achieving quality is continuous process. While once in a while you can take the slow lane as far as new features are concerned and polish the stuff you already released, this is not something good per-se, nor something we should strive for. We need new features as desperately as we need quality. Both should go hand in hand. If there is constant struggle to maintain quality, then the whole development process needs to be reevaluated and improved, new features are not the real culprit.

  • Like 9

Share this post


Link to post
8 hours ago, Dalija Prasnikar said:

then the whole development process needs to be reevaluated and improved, new features are not the real culprit

 

Well said.

Simple bugs, sometimes regressive ones, reported with fixes yet not implemented for years points to other issues..

 

Share this post


Link to post

Rio contains more new bugs than the 496 'fixed' ones and seems to be one of the lowest quality builds I've seen in a while. It was rushed out the door without being close to ready.

We've all been there. Boss says it needs to be ready by Nov 28th. So we release it. The really bad part about Rio is that 2 months on, almost all the bugs remain unfixed and look like things we will have to live with forever.

 

Some of the most annoying in Rio are:

The Library Path's don't save properly much of the time (not sure if you have to close rather than open a new project but its very annoying)

Code insight doesn't work for the new inline variable feature despite this being a huge new feature

Code completion still can't cope with anon methods and adds annoying end's to your code everytime you press enter

None of the new dialogs support wheel scrolling anymore

The ugly white lines around the search boxes in the title bar!

Critical bugs in the ISAPI web broker libraries

New IDE performance is slower because of the skins, especially to open dialogs (it can be turned off, but I don't buy a car with great styling to then cover with a car cover when driving)

Mac 64bit pushed forward yet again, despite the 64bit store requirement

 

If they wanted to make Rio friendly to new developers they should have copied the look from the welcome page in office 2019 it looks great. The ugly web page welcome of Delphi is not very pleasing.

 

  • Like 1

Share this post


Link to post
10 hours ago, hsvandrew said:

Code completion still can't cope with anon methods and adds annoying end's to your code everytime you press enter

I don't even want to estimate how much of my lifetime I have already spent on stuff like this. It's like the IDE does not want you to get your job done in time and is constantly putting spokes in your wheel 🤨

Edited by Der schöne Günther
  • Like 3

Share this post


Link to post

That is why I played with 10.3 a few days and reverted to 10.1. It is not perfect but at least event log (broken since 10.2) and options dialogs (reworked in 10.3 for unknown reason without any testing for alignment, it seems) work like they should. And don't get me started on themed/unthemed bugs which are uncountable... I feel the 10.3 quality is on the level of Delphi 4 or 2005 - the buggiest releases so far.

 

  • Like 2

Share this post


Link to post

I think the biggest problem with EMBA is the mentality. They do not really challenge themselves and their practices. Seems that they more spend time in trying to convince people that the bugs are "as expected" rather than looking at the big picture; which is customer satisfaction.

 

This is sad as they have been working hard (I don't doubt this) and this is not recognised as it often seems a focus on wrong things.

 

The announcement by Android Studio shows indeed that they have messed things up as @Dalija Prasnikar says. But, it also shows that they take ownership of the problems; they say: yes, we recognise we messed up but now we adjust our approach and set our priorities. This attitude has nothing to do with how big the company is or the avail resources.

  • Like 1

Share this post


Link to post
21 hours ago, John Kouraklis said:

I think the biggest problem with EMBA is the mentality. They do not really challenge themselves and their practices. Seems that they more spend time in trying to convince people that the bugs are "as expected" rather than looking at the big picture; which is customer satisfaction.

 

This is sad as they have been working hard (I don't doubt this) and this is not recognised as it often seems a focus on wrong things.

 

The announcement by Android Studio shows indeed that they have messed things up as @Dalija Prasnikar says. But, it also shows that they take ownership of the problems; they say: yes, we recognise we messed up but now we adjust our approach and set our priorities. This attitude has nothing to do with how big the company is or the avail resources.

I couldn't disagree more. When releasing Rio, Marco have a very difficult decision to make and had to post-pone Managed-records and IOS 64. They disabled both features. They were testing and certifiying the quality up to the last minute. Unfortunately they couldn't made it.
Quality IS very important for them. But even so, the all mighty M$ have infinite resource and released buggy patches and even buggy major releases.
 Embarcadero must  improve their testing scenarios and some bugs are harder to get then others and they are not using the power of this community as they should.

Share this post


Link to post
59 minutes ago, Clément said:

I couldn't disagree more.

 

We all have different criteria when evaluating release history.
Expecting us to believe Rio is 'quality assured' by removing heavily advertised (and at least one needed) features is stretching it..

 

Share this post


Link to post
55 minutes ago, Clément said:

they are not using the power of this community as they should.

I wholeheartedly agree with this statement.  This is evident by the further development of DDevExtensions for Delphi Rio by Andreas and the HiDPI enhancements form Uwe.  The Delphi Community has many developers more than capable of contributing to fixing IDE and run-time bugs if only they had access to the code.  If the IDE was open source I think we would see a lot of improvement in quality, assuming EMBT resources were allocated to incorporate those fixes.  I find the the Galileo IDE and it's insistence of trying to put in begin/end keywords annoying and counter productive.  I'm still much faster with the D7 IDE and CodeRush.

 

I would also have chosen functionality before form; that is to say while I like the aesthetics of the Rio IDE, I would have chosen 64 bit Mac OS/X support and bug fixes over that work.

Share this post


Link to post
4 hours ago, Clément said:

I couldn't disagree more. When releasing Rio, Marco have a very difficult decision to make and had to post-pone Managed-records and IOS 64. They disabled both features. They were testing and certifiying the quality up to the last minute. Unfortunately they couldn't made it.
Quality IS very important for them. But even so, the all mighty M$ have infinite resource and released buggy patches and even buggy major releases.
 Embarcadero must  improve their testing scenarios and some bugs are harder to get then others and they are not using the power of this community as they should.

As I said, I really appreciate the work Marco, David and the others put. I have no doubts they work hard. Because of this, we as customers who care about the product and its future share our criticism in constructive spirit.

 

Having said this, the last-minute pull-back of the features has a name in business world: it is called marketing and product disaster. You mention M$ and their buggy releases...I would add that when such disasters happen with MS products, people lose their sleep and many their jobs 

 

Anyways, quality is important for everyone; what happens now is that there is a gap between what EMBA perceives as quality and what customers perceive

 

And as for the resources...money and resources can't solve everything but undoubtedly contribute significantly to solutions. Size and resources are not the game-changer elements; mentality and organisational culture are. We can all learn from smaller companies like TMS and VSoft and many other that don't come to mind right now. Their products have bugs (and some nasty ones) but the whole culture in those companies is geared towards ownership of the problems, responsiveness and solutions.  

  • Like 1

Share this post


Link to post

There are at least three large components: compiler(s), RTL / component libs and IDE. Having very limited resources (as I guess) one has to concentrate on something to achieve at least visible progress in one of the components. A large group of Delphi users obviously desperately waits for compiler (language/codegen) improvements and additional platforms support. Instead we see tweaking the IDE introducing a lot of glitches/bugs/name it yourself which are obvious even after ten minutes of active usage. Was there any reason to rebuild the Options dialog probably from scratch paying no attention to bottom alignment? Or SDK manager where I could not do anything until I resized the window and saw that there are indeed buttons, invisible at first look? Component toolbar options page has fixed height - why? Every other Delphi version had it adapt to the window height. In previous versions dialogs were carefully aligned, with necessary anchors set. Now it seems that somebody had just quickly thrown a bunch of controls on the form giving no attention to how it would look in reality, and more - nobody bothered to check the result. Toolbars sometimes start to jump around by themselves - I never saw this in any other Delphi version. And so on...

I do not doubt that a lot of efforts was put in development, but it looks like they were mostly wasted reinventing the wheel (i.e. modifying IDE breaking it functionality) instead of focusing on, say, compiler. This is a question of targeting the right aim. Or we are starting to see the result of outsourcing the development (when was the core Delphi R&D team fired? A year or two ago?)

  • Like 4

Share this post


Link to post
17 hours ago, FredS said:

 

We all have different criteria when evaluating release history.
 

 

Right, I'm looking mostly towardy cross-platform.
My main concern is, beside all this ARC yes/no, Inline vars yes/no, Managed records, etc.:

! DONT BREAK MY RUNNING APPS AGAIN !

 

I know that EMBT makes a great job there integration 5 platforms, but please keep it all consistent.

The worst case for me would be that all these nice code experiments causes a lot of extra work for me to build in/out, test,
debug such features that I never wanted or needed.
I can accept some degree of experimental and improvements, and I'm willing to follow that burden from time to time,
but in the last versions had left some kind of chaos behind, and I'm not willing to see completely non-functional apps
or app-store rejected apps all the time.

 

Maybe a solution would be to offer beta-versions more often, but on the other hand I don't want to be a permanent beta tester.
A good description of the changes and best practices how to handle possible issues would be great before moving to the next version.
At least a first place would be to give all the new, alien error messages some really good explanation, especially for the mobile failures.
All the exra time I had spent with finding workarounds for some buggy stuff I better don't count, and this even if I use only 10% of the available features on purpose

.

 

 

 

  • Like 4

Share this post


Link to post

Great statement, Rollo! When FMX started out every release broke the code for previous releases...no problem. EMBT was still learning. And it was quite a big thing. But also ARC was introduced as "absolutely necessary to create modern apps for mobile devices" and it would come to Windows sooner or later. Now... not so much. ARC is slow. ARC is not as clever as we thought and ARC is not necessary. Well, no problem I ignored Warnings about using Free in iOS anyway, so my windows code wouldn't have be riddled with $IFDEF IOS. So, win for me...yay!

But please remember this before the next big thing crawls through EMBTs offices. We can't always be that lucky and forgiving.

Share this post


Link to post
21 hours ago, Larry Hengen said:

I wholeheartedly agree with this statement.  This is evident by the further development of DDevExtensions for Delphi Rio by Andreas and the HiDPI enhancements form Uwe.  The Delphi Community has many developers more than capable of contributing to fixing IDE and run-time bugs if only they had access to the code.  If the IDE was open source I think we would see a lot of improvement in quality, assuming EMBT resources were allocated to incorporate those fixes.

I have to disagree. You can go through release notes for a few previous releases and look for code contributions in Jira tickets. You will see, that very few of them go in to Embarcadero codebase, and most are rejected. This is because usually there are much better ways to fix a bug, but developer needs very deep knowledge of framework code. Embt employees have these knowledge, but average developers don't. So while there certainly will be some minor improvement in quality, miracle will not happen. And there are obvious downsides of open sourcing codebase.

Share this post


Link to post
53 minutes ago, Микола Петрівський said:

Embt employees have these knowledge

From my experience many don't ... could be that's those that are not directly employees of Embarcadero so then you would be correct again.

Those that have enough knowledge are only a few left and they have probably other tasks to do than to review code all day (which is heavily needed given the quality of some of the code written in recent years).

 

And I believe the quality of the code that we don't see (IDE, compiler) is not much better.

 

Open sourcing code alone of course does not solve anything - there are other steps required. Of course not everything is golden with Microsoft but if you look at the quality of .NET core for example you can see how much refactoring goes into that and how things are discussed in public - something that is completely lacking at Embarcadero because the developers don't even openly communicate mostly (which is partially fault of the community which has been very offensive towards them in the past).

Edited by Stefan Glienke
  • Like 4

Share this post


Link to post
On 1/24/2019 at 11:35 PM, John Kouraklis said:

Having said this, the last-minute pull-back of the features has a name in business world: it is called marketing and product disaster. You mention M$ and their buggy releases...I would add that when such disasters happen with MS products, people lose their sleep and many their jobs 

Pulling back features is never good, but releasing features that are not ready is way worse. Especially ones that are not localized and can have huge overall impact on product if not done right. 

This things happen all the time, everywhere. Google postpones features, Apple postpones features, MS postpones features. People are not losing their jobs for making hard decisions when bad things happen beyond their control.

Sometimes you complete 95% work on some feature only to realize that the remaining 5% is not actually 5% and it will take way more time to finish it properly. 

 

Of course, if there is constant inability to finish something on time, then someone has to take responsibility. Question is why is that happening? Is it because people working on things are not competent enough, or there is just not enough people working on things. 

Share this post


Link to post
On 1/26/2019 at 11:07 AM, Dalija Prasnikar said:

Pulling back features is never good, but releasing features that are not ready is way worse. Especially ones that are not localized and can have huge overall impact on product if not done right. 

@Dalija Prasnikar That's true. But when you build the whole marketing campaign and the next product development phase around those features then it is multi times worst

On 1/26/2019 at 11:07 AM, Dalija Prasnikar said:

This things happen all the time, everywhere. Google postpones features, Apple postpones features, MS postpones features. People are not losing their jobs for making hard decisions when bad things happen beyond their control.

No, they don't lose their jobs for bad decisions. They lose their jobs for bad planning, execution and bad results (it is cruel but that's life in the corporate world). Apple's situation with Maps gives some good lessons about what is happening when people do not deliver

Share this post


Link to post

What some people call beta is not but rather alpha - a proper beta in my book is software that is feature complete but not completely tested. Now if you call an alpha beta and time it closely to release that just asks for disaster.

Edited by Stefan Glienke
  • Like 4

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×