Friday, December 16, 2005
Thursday, December 15, 2005
Tuesday, December 13, 2005
Well, it's been an eventful last couple of months, to say the least. I've not commented here on recent events for several reasons. First of all, I've been on vacation for the last week with the family (Disneyland and Disney's California Adventure). Secondly, I wanted to see what the tone and reactions were to some of the latest news from Borland. So far, I'm pleased with how the customers have been reacting. So let's recap the latest news along with my various opinions...
Tod Nielsen - New Borland CEO. So far so good. He's a former MS exec and has walked in the shoes of many of us in the tools and database business. Frankly, I feel his pedigree is the best since Phillipe Kahn. That isn't a knock to any former CEOs (at least not all of them ;-), but merely an observation. His tag line, “Go big, or go home.“
Borland Developer Conference - Smaller venue. More focused on developers. Good content. Different “feel.” Better in some ways, and not so much in others. I really enjoyed participating in the opening keynote and doing the “What's new in Delphi“ talk.
Borland Developer Studio 2006 - Released to manufacturing. It was nearly a month and a half later than the original schedule due to needing more time to hit our quality criterion. Upper management, pushed hard for the orginal release date (as they should) but know that a quality focus would pay off in the long run. Big, big change from previous releases. Is it perfect in every way? Probably not quite, but it really needed to be out there so we can better know where to focus our efforts for updates.
C++Builder 2006 - The descision to release C++Builder as a preview and update that personality later was unprecidented. The team was stoked by this descision. By all rights, the C++Builder personality will get a significant number of much needed fixes before the update is released (which is real soon now).
Danny Thorpe - Sticky subject, for sure. First of all, yes, Danny has left Borland and is now working for Google. His reasons for leaving are personal, so I'll simply quote his comments made in the borland.public.delphi.non-technical newsgroup:
Members of the Delphi Community,
As you've no doubt read in other threads in this newsgroup, I have left
Borland to seek new opportunities at Google.
This was not a sudden action. I have tried my best to ensure a smooth
transition for the Delphi team, starting with transition plan
discussions with Borland management more than nine months ago.
Delphi is built by a team, not by any individual. Far greater talent
than mine has come and gone from the team, and Delphi presses on. More
importantly, far greater talent remains in the team, some of it as yet
As you may know, my philosphy is that teams should be built to
anticipate, tolerate, and support the comings and goings of individuals
on the team. Everyone will eventually leave the team - either by
choice, or by pine box. To ignore this is childish.
I have full confidence in the Delphi team to continue to deliver the
right stuff to keep Delphi current, innovative, and competitive for
years to come. Though there have been some difficult spots between
myself and Borland corporate management, the internal changes in
attitude and messaging in recent months from Borland corporate toward
Delphi have turned my faith in Borland supporting Delphi back toward
the positive. I'm sure that will only get better as Todd Neilsen
steps in as the new CEO.
I'm also pleased that in some small measure my departure is creating
opportunities for advancement within the Delphi team, and that Borland
management (Boz and Steve Todd) was very supportive of "redrawing the
map" under the guidance of Allen, Michael, Eli, and myself. Several
individuals on the team have been promoted in title and/or in pay as a
result of this change. Many of those have not seen promotion or pay
raises for as long as 5 years. Borland has also committed to opening up
several new positions in the Delphi group in Scotts Valley, which may
be filled with entry or mid level engineering talent. This alone is a
significant reversal of the "No new hires in Scotts Valley" edict
earlier this year by then-CEO Dale Fuller.
I was not snatched away from Borland, and I am not leaving Borland for
lack of money. I sought out Google, and I'll be making at Google
exactly what I made at Borland, which is nicely comfortable but not
excessive. There were other suitors (including the obvious one) but,
quite frankly, Google outmaneuvered them.
Could Borland have bought me back? No, because I didn't leave for
money. Why, then? Opportunity. I'm going to Google to pursue ideas
and opportunities that are simply beyond Borland. I love Delphi, I
know it inside out, but there's a lot more in me than just Delphi.
After 15 exciting years doing a wide variety of things at Borland, it's
time for me to do something /completely/ different.
This is not goodbye. This is just changing channels.
Let me comment by first saying that Danny's departure will certainly inccur some pain, however we've always survived the departure of other high-level team members. What this does is open up the team to allow some of the existing talent to advance and get the opportunity to put their unique mark on the product. It also opens up an avenue to bring in some new budding talent. As a matter of fact, we've just hired a new, young, hot-shot engineer in an entry-level position who was with us as an intern for a year or so. (the scary thing is that this guy was still in middle-school when Delphi was released!) Notice I said, “team.” That is a key point. Delphi was, and always will be, a team effort. Danny himself states, “Delphi was built with a team.”
On a personal note, Danny's mark will always be on the Delphi product, as will be Chuck Jazdzewski's and Anders Hejlsberg's. I can honestly say that Delphi wouldn't be what it is today without the vision and guidance of those individuals. I also count them all as very key to my own personal success for it is was with thier mentoring and guidance that I've been able to take over the reigns for Delphi.
So Delphi is moving forward on into the next release, codenamed Highlander. We're still on the same roadmap. The only things that may change is the timing. Internally, we're investigating various agile development methodologies in order to enhance our current processes. What is interesting about this is that it is being endorsed and supported by the exec management team.
Thursday, December 1, 2005
Monday, November 28, 2005
Thursday, November 17, 2005
In keeping with my current provocative streak, I'd like to talk about another potentially hackle-raising, ire-swelling, flame-generating subject. As the title of this post suggests, what is quality and how do you know you got it? Let me start by placing myself squarely in the “Quality is a journey” camp. Are you actually surprised by this? If you've followed this blog (and other Borland bloggers), then this shouldn't come as any kind of shock. After all, I'm more a pragmatist than I am an idealist. Also, I want to dispel any kind of myth that I'm ignorant of any quality foibles that have hit Delphi in the past. So, this isn't some high and mighty diatribe designed to deflect any blame and/or hide past mistakes. OK, D2005 was less than perfect.. some would contend it was a disaster. As much as I was reponsible for that release, I wish to just say we messed up and we're trying our hardest to correct as much as is in our power the how's and why's that happened. Are we going to step up to the plate and just swing for a single? I don't think so. We're going to swing for the fences, dangit! Will we hit a home-run? Maybe. Maybe not. But the point I want to make is that even after a bad play, we are still determined to step back to the plate and give it our best shot. So even if we don't hit it out of the park, a double or triple would be far better than striking out at the plate.
So what does this sudden baseball analogy have to do with journeys? Hank Aaron didn't start his baseball career as a record setting homerun king. It was a journey for him as well. So along that same vein, quality is also something you are always trying to do better than you did before. It is a journey that some may contend is never finished. However, unless you take those few first steps, you're going to just sit there and go absolutely nowhere. So you may also be saying, “That's great, but shouldn't you be so much better now that you're releasing the 10th version?” I agree. But it is what it is, and I can only try and correct those things that lead to where we were in the past. If only I could set the “way-back machine” and correct the problems of the past...
So you want honesty? Maybe that was just too honest, but so what? Would you rather some corporate mouthpiece pump out some press release about how it's all good and there's no trouble in paradise? I don't think so. I will tell you that the Delphi team is excited about the DeXter release. The team was also relieved at the exec's willingness to actually delay the final cut of the C++Builder portion until we ('we' being the team and the field-testers) feel it is ready!
I hope folks will be willing to join in on this journey. You get a better and better Delphi/C++Builder and we all win. Come to think of it... Isn't that also what this whole SDO/ALM thing is about as well? Not only is quality about doing software right, but also about doing the right software. This is something that the Delphi team has held as one of its core values. Always, always, use what you produce in one form or another. I like the story I'd heard recently about how an airplane manufacturer would require that the team of engineers that wrote the flight control software be among the first to fly on the plane during trials. I'm not sure I'd want that job, but it does illustrate my point.
Read this: http://bdn.borland.com/article/0,1410,33404,00.html. Go ahead, I'll wait.
Borland has never, in my 14 years here, done something like this. Personally, I think this is a good thing. I hope folks see this as being honest and forthright. What is absolutely amazing about this is that this descision was driven and supported by the executive team! They absolutely didn't want to push out a sub-standard release but also recognized that major portions of the product are ready. This was the right thing to do, both for our loyal customers and for Borland.
Tuesday, November 15, 2005
The following link is the presentation I made at this year's Borland Developer Conference. Please note that it is mostly bullet points for features and not a whole “wordy” set of slides that explain in detail each feature. In other words, I actually used the slides a my own notes and didn't show them very often since my talk was mosting about demoing the product. You can get the Powerpoint slides here: http://homepages.codegear.com/abauer/WhatsNewInDelphi.ppt.
Saturday, November 12, 2005
This should go without saying, however sometimes a little reminder is needed. First of all, I presume that most of the readers here are actual developers of some form or another. Maybe you're developing the next “killer app,” maintaining an internal accounting system, or just plinking out code in your spare time. For most of you, people besides yourself use your application to make their life a little easier. Basically, we all understand that the developer is the producer and the user is the consumer. For one segment of the overall market, those consumers are other developers just like yourself.
Now that we've established that we all share at least one thing in common, even besides Delphi, is that we're all software developers. I think we can certainly empathize with one another on one thing; defect or bug reports. I certainly think that there is a certain etiquette one must follow to create a good, clear, and concise defect report. This is especially true when reporting a defect to a fellow developer. This developer may be on your team, or some unknown developer that creates some set of components on which you rely.
First of all, make sure you are able to reproduce the bug. This is the most basic requirement in order to increase the likelyhood that the defect will be fixed. The next item is try to narrow the case down as much as possible and eliminate as many variables as possible. This will serve to keep the developer working to fix the problem focused on actually further understanding the issue. Otherwise you risk sending that developer on a wild-goose-chase, which only wastes time and further delays the final fix, if it is even possible. Sometimes a bug report may contain so many steps or variables that getting down to the real, core problem becomes an excercise in frustration and futility.
Finally, put yourself in that developer's position. Remember, you're a developer, so please afford them the same courtesy you would want when someone reports a defect in your code. What information would you want in the report? What is a good threshold for numbers of steps? It is rarely helpful to just dump you're entire project as an attachment in order to demonstrate the bug. Most of all, just think about the perfect bug report from your perspective and try and come as close to that ideal as you are able.
“Oh sure“, some may be saying, “then I'll never report a bug because I just don't have the time to mess with all that crap!” I'm sorry, but everyone has the same number of hours in the day. You're time is just as valuable as everyone else's. In fact by not reporting a defect, you're actually hurting your own productivity! No software product is going to be 100% free of defects (mainly because many item's design and operation may be considered a “defect”), they can only be made better than before. That can't happen if the developers of said software are unaware of the problems. They also cannot be expected to use the product in the same ways that everyone else does. That's why there are field or beta test programs. These are essentially, volunteers that spend time using the product as they would normall use it.
“What if I just can't seem to faithfully reproduce a bug?” In the ideal world, every defect is reproducable. You should strive to narrow down the steps to as few as possible, and to eliminate as many other variables as possible. However, in reality, it is never that simple. Sometimes an encountered defect is simply not reproducable on command. You may be asking, “So if I can't reproduce a defect, do I bother even reporting it?” The simple answer is, “Yes!” It's true that a single, lone non-reproducable report has little, if any chance of being fixed. But that is the beauty of a community defect reporting tool! By simply reporting the error message, and all other pertinant data you actually have, even if that is not enough information to actually reproduce the problem, you are adding to a growing database of data points. What if you run into a defect and spent 30 minutes trying to narrow the steps or even just reproduce the problem all to no avail? So you file a report anyway with all the data you currently have about the problem. Then someone else sees that report and immediatly is able to spot some commonality between your report and 15 other reports that seem to have the same unreproducable issue. Your defect report may have been the final bit of information in a long chain of data and finally forms a complete picture of the whole problem.
“Nobody can reproduce my defect report, but I have no trouble reproducing it! What do I do?” This is another common scenario that sometimes discourages and frustrates people. Don't fret! We still want to have these kinds of reports. Provide as much relevent information as possible, because just like the case in the previous paragraph, your defect may be the last key in a long standing quest to finally get to the bottom of a very complicated issue. Ultimately, the developers and quality assurance team responsible for fixing and testing a certain defect must be able to reproduce the problem. This makes sense, right? I mean how else can you be sure you've actually fixed a defect if you cannot compare the behavior before and after making a change to the code? You also need these steps and reproducability in order to plug this test case into a whole set of regression test suites. How else can you make sure that a once a defect is fixed that it actually remains fixed and doesn't somehow re-occur in a later build?
“I don't have time to actually give you good steps and a good description of the problem. It's not my job to be QA! I'll just tell you that there is a problem in general terms and you guys can try and figure out the defect and fix it from there.” Fair enough. This is similar to the first scenario I presented, but there's some more things we need to cover. Everyone's time is valuable and everyone's circumstances are different. However, I do need to point out that if this is your normal modus operandi, there is something you need to be aware of. Only you are the foremost authority on exactly how you work and what steps you took to encounter a defect. It is very difficult for the QA staff to extrapolate enough information to form a decent defect report. Also, unless clear and concise steps are given, how can we even be sure that we've actually found the defect you're reporting? What if a completely different defect is found when trying to narrow the steps and that is attributed to the original reporter's report? Sure, we've found and possibly fixed a defect, but how did that help the original reporter? Their defect is still there even though we've now closed out the report as fixed. That's not very helpful for all involved, is it?
I hope folks understand that by following a few simple rules and creating a defect report that you would like to get is actually you contributing to your own success. In this one case I have to say that karma is the best way to describe this process. By paying it forward and actually becoming a part of the solution, it will all eventually come back to you. Even though you may think your contribution is tiny and insignificant, the fact of the matter is that your contribution when compounded with everyone else's can pay back in large dividends. Quality Central is your friend!
Sunday, November 6, 2005
I'm sitting in my room a little more bleary-eyed than I was this morning. I spent the first half of the day in Ray Konopka's .NET component tutorial. Ray always does an excellent job in his talks. In actual fact, I spent that time getting together my slides that I'll use for my session on Tuesday, November 8th. In the afternoon, I attended the Delphi overview talk by Anders Ohlsson. Well it was sort of Anders' talk because I got up there and quickly ran through some of the new IDE features and did a quick demo. Then Jason Vokes got up and went through all the new Together design project support. After Jason, Henrik Jondell demoed the new ECO III stuff. John Kaster showed a lot of the new database features. Finally, Nick Hodges went through some ASP.NET demos and intro.
Got to have dinner with John Kaster, Anders Ohlsson, Malcolm Groves, Jason Vokes, Henrik Jondell, and Nick Hodges. Tip: You can skip the resturant Cortez here in San Franciso if you're at all hungry. It is all ala carte with very small portions and relatively high prices. We stopped by a corner market on the way back to the hotel. I got several of them an It's-It. They're a local San Fransciso treat. If you're in the bay area and like a little different twist on the ice cream sandwich, get an It's-It.
Saturday, November 5, 2005
OK.. I'm here at DevCon at the San Francisco Hilton Towers smack in the middle of downtown San Fran'. I'm currently waiting for a build with the latest changes feverishly checked into StarTeam to complete. The VPN is connected, the fan on the laptop is on high trying to stay ahead of the wattage from the CPU, and the 7200 rpm laptop hard drive is chirping madly. I also have to go over and finalize my talk, “What's new in Delphi”... I'll also be guest presenting in Anders Ohlsson's Delphi Overview pre-conference tutorial.. It's only a half and hour, but at least I'll be able to do a dry run before my main talk in the actual conference. I'll also be connecting as often as possible and VPN'ing back to the office to check on the latest progress of the build and make sure I don't have any real nasty critters show up... On top of all that, Tuesday, Nov. 8th is election day here in California... and... oh wait.. I took care of that and have already sent in my absentee ballot.. whew! Citizenship duty... check! Next item... where's that PowerPoint application? Oh don't worry, I'll only have a very small number of slides. There's enough stuff in DeXter to keep me busy for several hours.. the problem is picking the coolest ones. I'll try and keep some more information flowing here... oops.. the build is done. Gotta go.
Wednesday, November 2, 2005
Monday, October 31, 2005
Just in case folks are out there stuck waiting for some pithy or otherwise tasty morsel of information from this blog...(if you fall into this group.. uh.. you might want to investigate actually getting a life :-).. or for the others that just seem to have a passing curiosity of what goes on here.. if only to see what kind of drivel that wacky Allen actually spouts today. Well, anyway, in case you've been stranded on a deserted island (or were a contestant on Survivor) there is a new Delphi release in the works along with the Borland Developer Conference coming. So not surprisingly, I've been very busy working on getting all my bugs fixed for the release and also getting together my presentation at the conference. Postings will remain a little light for a while.
As if you actually care...
Friday, September 30, 2005
Remember this post? It was where I described the newly added PopupMode and PopupParent properties to TCustomForm. Lets fast-forward to now, in the midst of the DeXter release of Delphi. It seems that this change highlighted some shortcomings in the implementation of, not only, Borland supplied components but also of many third-party components... Well.. maybe shortcomings is too strong of a word... let's just say “issues.” One of the original goals of VCL visual components was to delay the construction of the underlying window handle to the last possible moment. It was also a goal for all visual components that use a window handle to also properly survive a handle recreation. The visual component should save off any state that is internally associated with the window handle and then properly restore it once the new handle was created. The reason for this is that there are some window styles and/or states that cannot be change on the fly without destroying and creating a new window handle. This was especially true back in Win16. Thankfully, this is less of an issue for Win32, but there still are a few cases. So when the PopupMode properties were introduced, the only way to change the “owner” of a window handle was to destroy it and then recreate. There is no SetOwner API similar to SetParent. (Ok, if there is, I haven't found it..) So why is it important that the correct owner be set for modal UI? Raymond Chen explains one reason quite well here. In fact, I encourage you to peruse a lot of what Raymond has to say regarding the inner workings of Windows. In today's modern world of frameworks and abstraction layers, rarely do folks ever need to really understand the raw Windows API level functionality, however sometimes it is good to go back and revisit why and how things are done the way they are. Raymond rarely disappoints in that regard.
So back to the subject at hand... In order to properly guarantee that modal forms were “owned” properly, the ShowModal method on TCustomForm was changed to force a recreation of the handle if the PopupMode was set to pmNone. What this did was ensure in CreateWnd, the proper owner was selected for the new window handle. This seemed to wreak no end of havoc on existing VCL applications. It also served to highlight how “recreate brittle” many of our own VCL components were. The good thing about this is that for DeXter, we've corrected all those issues and our VCL components are now “recreate tolerant.” In fact, if you're a third-party component developer, I encourage you to review your own components to determine their “recreate brittleness.”
Now the standard technique for “fixing” this issue was to simply set the PopupMode property on all your forms that are intended for modal operation to pmAuto. This would ensure that when ShowModal was called, no recreates were nessesary because the correct owner would have, presumably, been selected. There are cases where this may still not be the case, especially when you don't create and destroy your modal forms near the point they're needed. In response to the feedback regarding this issue and the fact that when you are bitten by it, it is extremely difficult to determine the cause, we'll be introducing a new TApplication property that controls this modal behaviour at the global level in the DeXter release. The new TApplication.ModalPopupMode property does this. For consistency sake the type of this property is TPopupMode, which is an enumeration with three elements. The default value for this is pmNone, which makes ShowModal behave the same as the Delphi 7 version of VCL and earlier. Setting this property programatically to anything other than pmNone (pmAuto or pmExplicit), will enable the current Delphi 8 and Delphi 2005 behaviour. So now you can choose when and if you need to support this new behaviour.
For component developers, the IDE code explicitly sets this value to pmAuto, so if you have any modal dialogs as part of the component/property editors associated with your components, then you'll still need to ensure that those dialog's PopupModes are either set to pmAuto, or they are not “recreate brittle.” This is simply because your VCL components are running on top of the same core VCL that the IDE is using.
Thursday, September 29, 2005
I consider Nick to be a good friend, not only personally, but also a good friend to the Delphi community. His zealous, passionate support for Delphi and the Delphi Development team certainly does not go unnoticed within these walls. More than once, I've heard or have been known to say “Did you read Nick's latest blog post?” Now, Nick, before you're cranial cavity expands beyond the point of comfortably traversing a doorway, I also have to say that Nick is most definately a human being as well. With that, comes all the faults and foibles so many of us share. I certainly have my fair share of faults... just ask my wife... It's probably a list in a 10meg Word document by now ;-)...
I highlight Nick because he is the epitomy of what he himself is talking about in this most recent blog post where he references this blog post by Kathy Sierra. Nick is a passionate Delphi user.. you know the type.. “You'll get my Delphi when you pry it from my cold, dead fingers.” You know where he got that? From the Delphi team. Members come and member go, but at the core and at the very heart of what is Delphi is a group of passionate, dedicated, engineers. More than once I've heard from former Delphi team members where they say “I remember my time on the Delphi team as some of the most fun and exciting time in my career.” Even folks who were peripherally involved, such as former Developer Relations team members. They all say the same thing.
So why has the Delphi team continued to be so passionate and driven despite any level of corporate maelstrom-du-jour? I think everyone of you, the loyal, vocal, sometimes irritating, often combative, highly opinionated, yet consistently unwavering and passionate. When Borland or even the Delphi team makes a mistake, we hear about it... I mean boy do we ever. But the flip side is also what makes working on Delphi so rewarding; when we do it right, we also hear about it!
Doesn't Borland seem to be heading down this course of “professionalism” and straying away from the “passionate” and why? In a word... ok a symbol “$”. In and of itself, that isn't a bad thing.. I mean what would all the recent hurricane victims do if there wasn't a huge influx of “$”? So overall money is good...
Borland is currently in a transition, it's growing up. Is that good? According to Ms. Sierra and Mr. Graham, it's not and, frankly I think I agree. Is Borland a lost cause? Not at all. I think what is happening is that is that this transition is more painful because it is so committed to making it happen. I've been saying for a long time, that Borland is too small to act big, and too big to act small. Being a publically traded company certainly complicates things and increases the pain level... because there is this other group that is neither its customers, nor its employees... they're the shareholders. They're an impatient lot... hmmm.. sounds familier. I'd say that the Delphi community is just as impatient (when do we get a Unicode VCL?, what about 64bit?, Is this .NET thing ever going to be real?).. but I digress. There is certainly a desire throughout the management ranks to rekindle some of these ideas throughout the development teams. Will they succeed? Time will tell.
For my part, being a torch bearer for Delphi has been a tough position to be in. But I see a few glimmers of hope. Recently, I was involved with a lengthly email thread that involved Rick Jackson, the Borland Chief Marketing Officer (CMO) regarding “why isn't Delphi 'just an IDE'?” I don't pretend to take credit for this by any means, since there were many, many others involved, but the result of that thread was this posting. In fact here's some excerpts from what I wrote:
About the Delphi customer/fan base:
“Maybe this has been said before and maybe this is news to some... but pigeonholing Delphi into the "its just an IDE" space is really, really missing the whole point. Delphi is far more than simply an IDE. In fact, for Delphi the IDE is merely a convenient place for all the technologies that surround Delphi to converge. Delphi is a proprietary language (one that Borland wholly owns), it is a component framework from which many others are measured, including Microsoft .NET Windows Forms Framework. <snip>. The Delphi customer base is a loyal, rabid fan base. What other product has this kind of following, at Borland or any other company for that matter? The near cult-like following that is the Delphi market is not one to be shunned or scorned, either directly or indirectly by gross omission. It is one that should be nurtured and cultivated...from all facets of the company.”
How is Delphi different from other “IDE” products such as JBuilder, or even Eclipse?
“Why is it that Delphi seems to continually and consistently bring in a stable revenue stream? Consider the difference between JBuilder and Delphi. Borland doesn't own the language, the compiler, or even the frameworks. JBuilder was, in effect, just an IDE. Of course that market suffered from erosion from Eclipse and other entries in the Java IDE market. It was relatively easy for someone to move between the different IDEs. The same language and the same frameworks existed and worked with all the different IDEs. The IDEs could only compete on features, JDK support, J2EE support, etc.. <snip>”
Please, if you're a JBuilder customer, don't take this as some attack on JBuilder because, frankly JBuilder is an absolutely awesome tool! I have nothing but respect and admiration for how much JBuilder has served to “raise the bar” among all IDEs.
My summary on what Delphi truly is:
Not to leave it out, but I also included C++Builder as well.
“What about C++Builder? It is very similar situation as well. While, yes it is based on the widely used C++ language, it is no less proprietary. In order to properly support the Delphi VCL framework, and since we also control both the C++ and Delphi compilers, we were able to extend the C++ language in such a way as to allow the use of the Delphi/Pascal VCL framework to be used with C++. In fact, C++Builder would have not existed without Delphi. The Delphi compiler actually directly generates all the necessary supporting files and libraries required for a C++Builder application. The relationship between Delphi and C++Builder is very symbiotic. Like the Delphi market, the C++Builder market is no less loyal and near cult-like. <snip> Remember the open letter from the C++Builder community to Borland? What customer base, even a C++ customer base, would take the time to create a letter and get signatures from many rather large installations?”
And finally, about the Delphi/C++Builder team:
“This rabid following both for Delphi and C++ Builder translates directly to the development teams. Most of the members of the Delphi/C++Builder team love working on the product not only because they believe in the product, but also because they know and understand the Delphi and C++Builder market and its customers.”
So any place you see “<snip>”, they're just a few places were some internally sensitive statements were made.. but that amounts to about 4 sentences and don't really add any more to the tone of what I was trying to say. By all counts, this message was heard loud and clear. Within the next two weeks, corporate marketing (not to belabor the point but, yes, folks there actually is a group called “marketing” in Borland :-) was requesting an audience with nearly all the members of the Delphi team. We sat down in a conference room for 2.5 hours where we got to explain Delphi, the Delphi team, the Delphi market, and the Delphi product to this team. There were about 4 members of the marketing team listening and writing furiously as many members of the Delphi team proceeded to enthusiastically, passionately and fevently explain why Delphi is important. Many points were raised, most of which I've already covered above. The level of detail was intense.
So what about all this recent bruhaha surrounding the idea of Delphi being bought out? Well, if I did actually know anything, I couldn't comment, that's for sure... but one thing I will say is that it is certainly fun to fantasize and ponder “what would the world be like if..?“ Then once you begin to follow that train of thought, with the logistics, the turmoil, the FUD, all of which would be obsticles that I shudder to think about it. Maybe, maybe not.. let's move on folks.
So will this post get me fired? I don't know, I doubt it. I just wanted folks to know that we're not a passive team, and that there are still many champions within Borland for Delphi. The tireless efforts of John Kaster, Anders Ohlsson, and David I, should be commended as well. As should other Delphi team members, such as Danny, Steve Trefethen, Chris Hesik, and others for their continued blogging efforts.
Wednesday, September 28, 2005
There has been some speculation into the recent Delphi Roadmap announcements regarding the inclusion of FastMM4. Some have speculated that this memory manager is only use for the IDE. Well, that is simply not true. FastMM4 is now the default memory manager in the Delphi RTL. It wholly replaces the existing Delphi memory manager and will from now on be included in any Delphi Win32 application compiled with DeXter. Yes, the IDE also uses this new memory manager and in fact, by simply replacing the memory manager in my informal tests I saw the IDE startup time drop from 25 seconds to 13 seconds... folks that is nearly a 50% increase in performance!
One thing to note about this move is that it highlights the unique relationship the Delphi Development team has with its customers. There are very few products in almost any industry that has this strong of a community. It is the commitment and tenacity of the Delphi community that helps make things like this happen. So, be sure to support Pierre le Riche, the author of FastMM4, in his endeavours. For my part, I'll be ensuring that he receives a complimentary copy of next version of Delphi... I'll also be looking into making sure he gets a copy of each version from now on as well.
Wednesday, September 14, 2005
The ever present, Chee Wee Chua, reminded me of something that you may have already encountered with yesterday's fix. Be sure you run sn -Vr on the Borland.Studio.Vcl.Design.dll assembly. That will disable strong-name validation for that assembly so that it will load properly. Thanks, Chee Wee! Duh! If that doesn't fix it, you can simply not install the Borland.Studio.Vcl.Design.dll assembly until I can figure out how to get it strong-named... I guess I'll have to see about grabbing our strong name private key from the integration team.
Update: I've now strong named the Borland.Studio.Vcl.Design.dll assembly and updated the d2005_update.zip file. You'll need to re-download this file.
Udpate 2: There is now a CodeCentral entry that has these updates. I'll probably be removing the files from homepages.borland.com in a few days in favor of using CodeCentral.
Update 3: Ok... for now, ignore the Borland.Studio.Vcl.Design.dll assembly until I can get the assembly version number garbledygook figured out.
Tuesday, September 13, 2005
Friday, September 9, 2005
Friday, September 2, 2005
Call me crazy... but I suppose I'm just flirting with disaster... So by paying homage to all the extreme sports out there, I've just uploaded a new patch. I guess you can call it Extreme Delphi. Just like extreme sports are not for the faint of heart, so too these patches should be approached the same way. So if you've donned your knee and elbow pads and your helmet, you may proceed to the Extreme Delphi half-pipe and get the latest installment here. This latest patch will hopefully cover some cases of random hangs and may also serve to reduce the occurance of the dreaded “amount >= dest - startDest“ assertion. This latest installment comes by way of Extreme Delphi team member, Adam “Sparky” Markowitz. So in our quest to extinguish as many bugs and issues as we can out of the next Delphi release, code named, DeXter, Adam happened across this simple but effective fix. So, I hope you are able to catch some big air with this patch...
Tuesday, August 9, 2005
You may or may not have seen this rather insidious message in D2005; “amount >= dest - startDest” If you've seen this message, then you know what I'm talking about. Like this fix for the editor kernel itself, this one will take care of at least one instance of the previously mentioned assertion. Again, this is extremely informal and no warranties, express or implied are in any way given. If you are not risk averse, like to live on the bleeding edge, or otherwise are willing to give it a go, then you can download this patch here.
Like before, shut down the D2005 IDE. Go to the bin folder and rename coreide90.bpl and coreide90.jdbg to coreide90.bpl.save and coreide90.jdbg.save, respectively. Then unzip the file from the above link into that folder. Oh yes.. this will only work with an update 3 installation.
Again, thanks to Randy Magruder for really living on the edge and testing this little patch.
Friday, August 5, 2005
Let's just keep this between you and me, OK? While developing the next version of Delphi we encountered a defect in the editor kernel dll that could cause some instability if one happen to, ahem, use a different memory manager dll (borlndmm.dll) (cough...FastMM4...cough)... You can get the informally fixed editor kernel dll here. Simply download this file and unzip it. Go to the <D2005 install>bin folder and rename boreditu.dll to something like boreditu.dll.save. Then copy the new boreditu.dll to this folder... oh, and of course you shouldn't be running D2005 when doing this.
Remember this is just between us friends... This is not an official support channel, nor will I have the bandwidth to answer any questions regarding this. If this fixes some issues you may be having with D2005, then great. If not, see below. Basically, you should see fewer random editor kernel AVs. This doesn't fix the random editor kernel “amount >= dest - startDest“ assertions some folks had been reporting. That is a different issue.
I'd like to thank, Delphi user and ex-Borlander extraordinaire, Randy Magruder, for his help in informally testing this this little patch. So if it blows up on you, you can blame him... :-). However, if it works for you.. oh.. well.. you can still blame him, I suppose...
Tuesday, July 12, 2005
Starting this evening at “oh hundred” hours (that's 12 midnight Pacific Daylight Time), the event of the year will be starting. That is when the “24 hours of Delphi” event kicks off. I'll be “on the air” at around 9:30am PDT and possibly again around 11:00am PDT. I sure don't envy David I, Anders Ohlsson, and John Kaster who have to stay up and ramble on in order to keep the “dead air” to a minimum. However, based on the schedule I've seen, there doesn't look to be too much of that, if at all. Be sure to “tune in.” I may decide to take some breaks throughout the day and “crash” their little party periodically ;-)..
Sunday, July 10, 2005
No this isn't really about firearms, but actually a response to a comment I received regarding this post. The comment basically chastised me (or Borland in general) that I (we) should just fix the bugs and release more updates rather than “paint useless Powerpoint slides.” Wow. I thought that was what we're trying to do (fix the bugs, that is). The comment seemed to suggest that we should simply take a “shotgun” approach to fixing bugs. I'm sorry but that is a foolish approach. If you don't have and use tools to help you prioritize your work, you'll almost always be doing the wrong thing. You can't prioritize based on data you don't have or can't see. So rather than attacking the problem with a shotgun we get out the sniper rifle. The surgical nature of using the sniper rifle approach reduces the collateral damage.
Oh, and again, that post was merely intended to be a visual aid to describe what is currently a mental process. Powerpoint was not used in its creation.. Excel was ;-). It was also intended to potentially spark some discussion externally and, probably more important, internally. It seems to have done that since John Kaster has responded that maybe this should be something that is added to Quality Central.
Thursday, July 7, 2005
Steve Trefethen has been running a series of posts regarding the Delphi Development Process. I thought I'd add a little salt to this post about how we handle bugs. Then I started looking at some of my old posts and found that I'd already posted a rather long diatribe on how we prioritize the fixing of defects. So rather than simply restating what I'd already said, I thought I'd provide a visual aid to explain my comments regard a defect's “surface area.” I spent a few moments and created the following graph to illustrate this goofy idea I have regarding the use of a bug's “surface area” in determining its priority in the stack of things to be looked at.
As you can see, by using a spider graph and picking various metrics that are the radial scales a quick glance at the data shows how much overall “surface area” a defect appears to have. As I mentioned in my post referenced above, we don't actually spit out a spider graph for each defect. This is merely a visual aid to help further illustrate my point. Although, this may be a good thing to have our internal tools begin to actually provide....hmmm.... The number of metrics and their scales would probably be very different, but I hope this may help spark ideas, internally and externally.
Wednesday, June 29, 2005
In this blog post by Raymond Chen, I find it very interesting and also very comforting that they (MS) actually considers the case where their MSDN examples are going to be taken and translated to a myriad of languages beyond the world of C/C++. In fact, according to Ramond, far more people use languages other than C/C++ to create applications for Windows. Do I believe that? Maybe. If you consider the huge number of Visual Basic programmers out there, then it seems that this statement has some merit. I know that we Delphi programmers are certainly included in that calculation as well. I mean, we've all done it. We've all looked up the documentation on some Windows API and took the example code and translated portions of it to Delphi.
As a side note, posts like this also seem to be fodder for the various “glory-seekers” to chime in a pick apart his statements with petty little pedantic tirades on how much more they know about the C/C++ idiosyncrasies. Just look at the comments regarding the realization that ZeroMemory won't work if the structures have IEEE floating point fields, or if some system uses a value other than 0 to represent a NULL. I call them “glory seekers” because it seems that their only goal is to somehow get their “props” by pointing out the little edge conditions in someone's statements. Good for you... you are a programming god... meanwhile the rest of us will take comfort in the true intent of what Raymond was saying.
Tuesday, June 28, 2005
Monday, June 27, 2005
Thursday, June 9, 2005
I admit it. I'm an incorrigible optimist. In the recent announcement by Apple regarding their move to using Intel CPUs, I only saw it as a good thing for the industry. I also see it as a potential opportunity for Borland. I'll predicate all of this with a huge dose of speculation, wishful thinking and downright optimism on my part. Nobody has a magical crystal ball and cannot predict the future. Yet, unlike Danny's post, I have a more positive outlook. Now, there are those that scoff at the notion of a Mac OS running on Intel hardware. Generally, these are emotional responses, or the obligatory “oh no! The Intel monopoly is expanding!” concerns. Ever since the first release of OSX running on the BSD kernel, rumors have abounded about how easy or hard that it would be to get OSX running on an Intel platform.
How does this all relate to Borland? Right now, it doesn't. It's just an interesting development in the industry at large. As Danny posits, if Apple is going to go totally for the EM64T/AMD64 side then the route to the Mac is certainly riddled with far more land mines. However, according to Corbin Dunn (former Borlander and now on the Cocoa team at Apple) in a comment to Danny's post:
“The intel x86 machines are not limited to 64-bit (trust me on that one). So, in theory, it would be possible to port Delphi to Mac, since the compiler is already spitting out x86 code. But, as we know from the Linux port, it isn't as simple as it seems. But, it would be simpler since BSD isn't such a far stretch from Linux.”
I'm sure another one of the big questions on everyone's mind is this: “can I take a plain-Jane ASUS motherboard, throw on the latest Pentium, slap some memory in, drop in a decend graphics card, hard drives, cdrom, etc... stick in the OSX disk and install?” Hm... I don't know. I'd imagine that to almost be the case, but since Apple keeps such tight control on the hardware spec, there probably isn't too many graphics cards, or other esoteric types of hardware that it will support. Now, if Apple opens up their video driver architecture, and other subsystems we may be able to install the latest ATI or nVidia hardware.
So there's that question. Apple did try to go down the licensed hardware route back in the late 90s, only to eventually reneg on that whole endeavour. There are some rays of light in this article about the move to Intel. According to the article:
“The first challenge ended up not being much of one at all, as Jobs revealed that OS X has been running on x86 platforms for the past 5 years; every release of Mac OS X has been compiled for PowerPC and Intel.”
Hmmm.... Did they design some special hardware 5 years ago just to run this port of OSX? I doubt it. I imagine they bought some off the shelf Dells or built up some systems from stock mother-boards and components. Even the Mac has a PCI bus (don't know if the newer Macs have AGP or PCI-Express), in which they could just put in one of their normal graphics cards. So this might lend some credence to my supposition that you may be able to slap together some cheap hardware and boot up OSX.
Basically, if there is going to be a 32bit version and a 64bit version of OSX on x86 hardware (as Corbin seems to indicate), then we have at least one item covered... sort of.. There are some huge hurdles, like the linker, codegen ABI tweaks, executable format, VCL, IDE, etc. As for x86-64... well I think we all know how high that hurdle is going to be...
So why am I so optimistic in the face of all these challenges? Simple. I see this as a good move for Apple. I think it will help boost their sales. And if they can become a true competitive force in the industry at large, then maybe Borland would have no choice but to turn some attention to that platform. So it remains to be seen and you can be certain that we'll keep an eye on all these developments as they continue to unfold.
Thursday, June 2, 2005
Friday, May 27, 2005
So I tasked some of my gnomes and elves to do a little more work on the problem of the editor gutter. I gave them all the feedback received from this post just to see what they would come up with. So here's the result:
Hmm.... Actually I kinda like it. Who says you can't teach old dogs new tricks! Of course this is still subject to change if my gnomes or elves start getting cocky..
Wednesday, May 25, 2005
So, yesterday, Steve Trefethen, stopped by my office and had asked whether or not I'd gotten any internal feedback on what to do about the left gutter in the editor. You see, we have an internal blog and an internal wiki that we use to communicate newsworthy items and to float around technical specs among the various teams. Because we have teams spread across the globe, development is happening on Delphi almost 24-7, so it is usually much easier to dissiminate information via the internal blog than to spam everyone's email box. The Delphi Welcome Page for developer's builds automatically points to the RSS feed for the internal blog so most folks don't miss the blog information. Oh, things like meeting minutes, new feature status, build breakages, etc... are all published there, but I digress. You're here for a discussion on the left gutter in the editor.
As Steve and I were talking about the dearth of feedback we'd gotten internally, we spent a few moments and brainstormed (OK. I did get one bit of feedback, thanks Jesper!). I think we hit on an epiphany. We determined that the main cause of “fear and loathing” regarding the Delphi 2005 gutter was that it was actually packed with too much information. It was cluttered which lead to the general feeling of being disorganized. Myself being somewhat ADD, that clutter is easily overlooked, or at least minimalized. I knew something just didn't “click” with it, but couldn't quite put my finger on it. So as we brainstormed, Steve hit upon an what could be characterized as a “duh!”. What if we only painted every 10th line number and then placed little dots for the lines in between? The same information is conveyed, but every 10th was too far apart to quickly see what lines were in between. I didn't realize how much I relied on the line numbers in the gutter until we started changing things. So we tried to paint only every 5th line lumber... nope, still too cluttered. At first we painted '-' characters on the lines between the numbers... ick.. that made it look like a ruler. So we went with the dots. That was better, but every 5th line was still too many line numbers cluttering things up. So, again, Steve, suggested we paint a '-' on the 5th line between the numbers and dots on all the rest. Wow! That is actually starting to look good. Here's what we've go so far:
That's far less cluttered, don't you think? The “-” character clearly deliniates the 5th line. With just a little more effort, we think it will quickly become second nature to be able to glance at that and see what line number a particular line is.
Now that the line numbers are not so prominent and “out there,” let's tackle the “overlapping icons” issue... The problem we're trying to solve here is that there is a lot of information we want to convey visually from the left gutter. Things like breakpoints, bookmarks, breakpointable lines, current execution point, etc.. All of this information takes precious real estate from the really important information, the source code. So we compromised and placed the icons over the line numbers and also tried to change the intensity of the line number to be less prominent. The problem with playing with luminance and saturation is that many times those value tend to wrap around and actually create a much brigher color. The reason for “dimming” the line number was an attempt at reducing the clutter I talked about above. So we disabled that “feature.” Now that the gutter is far less cluttered, lets look at what it would look like now with the infamous “blue balls.”
Hm.. That's getting there. The breakpointable line icon is clearly visible and easily overshadows the line numbers making them very visible. They also don't steal any more real estate. So what about bookmarks and the current execution point?
Notice that the breakpoint glyph doesn't overlap the bookmark glyph. However the excution point arrow does overlap. This is on purpose. Those are related items. The breakpoint glyph and the execution point arrow glyph are all about debugging. Notice that the blue ball is also covered up. Why continue showing that when it is clear that the breakpoint has been set there? You can still see the breakpoint under the arrow, so there is no need to take up more real estate. Notice that the line number has taken a complete back seat to all of this. They're not as an important piece of information as the bookmark, breakpoint and execution point glyphs are. Also since there are no line numbers painted on the adjacent lines, there is far less surrounding clutter to detract from where the real information lies.
Finally, lets look at what happens when the gutter is too narrow to display those two glyphs side-by-side without also spilling into the code folding information. At this point, the glyphs will begin to overlap, but only to a certain point so that all the glyphs will be at least partially visible. But we've rearranged the priority of them so that the bookmark is always on the bottom, then the breakpoint/breakpointable glyphs, finally the execution point is alway on the top.
As most source files tend to be more than the mere 30 lines we see here, the gutter will generally be wider and thus there'll be far less overlap between the glyphs. Hopefully we'll see some derivative of the above changes in the next Delphi release. Since this is only a start, I'm sure we'll be refining this even further, and since I have no delusions of pleasing everyone, I think we're on the right track.
Friday, May 13, 2005
I thought I'd take a moment to dispell any myth regarding whether or not we take the current (or past) Delphi survey seriously and they really don't end up in some black hole. In between Mods E and F here at the Scotts Valley, CA campus, there's an entire wall that is one huge dry erase board (whiteboard). Just yesterday, the latest preliminary survey results were printed and taped up on that board for all to see (internal to Borland that is). It is quite interesting to read over all the results. Now one item of note is that while we do take these surveys very seriously, they are just a part of the overall picture. We also take into account a lot of information from our field sales teams, the Product Line Sales Managers for the various regions, and customer site visits, etc... The following photos (taken with the now infamous phone cam...;-) are just the results from the Delphi 2005 users only, so there's a lot more data to mine. This was also only after the first day the survey was posted. No, I'm not going to provide higher resolution photos because we generally don't publish the results of these surveys. Mainly because of what I said above; they are only a part of the overall picture (no pun intended ;-). As we mix in data from all the other sources, things could vary substantially from the raw survey results. Besides, raw or cooked, internal marketing data is a critical business datapoint and should be held very close... why hand free marketing research to your competitors?
If you look closely at the picture on the left, you can see the written text “1st Day results...” Also, nevermind the tic-tac-toe game to the left ;-)...
Wednesday, May 11, 2005
Mark Russinovich, of SysInternals fame, posted this blog entry about the new Windows XP 64bit Edition. Why do I mention it? Well, for one thing, Mark mentions using Delphi 2005. Unfortunately, his reference to Delphi isn't too flattering.
“The Borland Delphi 2005 debugger has a more serious issue: when you launch a process under the debugger it believes that the process exits immediately when the process actually starts properly. A workaround is to attach the debugger to the process after its launched.”
This blog post was brought to our attention, so I posted a comment asking for some clarification and some steps to reproduce this problem. This was in addition to the internal flurry of emails and immediate investigation into the problem on one of the 64bit systems in the QA lab. However, based on the above description, we tried to reproduce the problem and found that we could not. Obviously, we're not trying to debug a 64bit application (Delphi isn't quite there, yet ;-). Mark responded quickly with more information regarding what he was actually trying to do. It turns out that he was trying to debug an MMC (Microsoft Management Console) snap-in written in Delphi. After another internal flurry of emails and work in the QA lab by a member of the QA team, we looked and found out that mmc.exe is in fact a 64bit application. OK... now the SysInternals guys are some smart cookies, and I could not for an instant think that Mark would make such a silly and obvious error. It turns out that there are two versions of mmc.exe, a 64bit version and a 32bit version.
So after I post a rather sheepish response (in which I inquire as to the “bitness” of mmc.exe... I was a little embarrased to even mention it) to Mark's explination of what he was doing, Mark responds with what is actually going on. Yes, of course, he's launching the 32bit version of mmc.exe from the Delphi 2005 IDE. But what happens is that the 32bit MMC then immediately turns around and launches the 64bit MMC and then exits. Ok this makes sense. But, he mentions that he's able to attach to the process after it is launched. This is easily explained as well as Mark states in his response comment:
“I've investigated further and its a Windows problem, not Delphi's: when you launch the 32-bit mmc.exe it launches the 64-bit mmc.exe and exits. If you are loading a 32-bit snapin the 64-bit mmc.exe launches the 32-bit mmc.exe again and exits.”
So the mystery is solved. And Delphi 2005 runs and debugs 32bit applications on the new Windows XP 64bit Edition. So thanks, Mark, for bringing this to our attention and being so proactive in figuring out this odd behaviour. And finally, it is really awesome to know that the folks at SysInternals use Delphi!
Follow up: It looks like Mark figured out the issue and how to launch the 32bit MMC. He explained in his comment:
“ Ah, I figured it out: you can launch the 32-bit mmc.exe directly if you specify its path (windowssyswow64mmc.exe) and include the /64 command-line option.”
Tuesday, May 3, 2005
When we look to hire a new junior/entry level engineer, there are several key qualities I look for in the candidate. The first and foremost quality I want to see, obviously, is talent. Do they really know the stuff they said that they did on their resume(CV)? Another quality that is one of the hardest to see in a short interview, although I have seen it come out in the really exceptional ones, is enthusiasm and excitement. Don't be afraid of being wrong. How else do you learn? A corollary to this one is teachability. How well do you respect both your peers and the senior developers?
Clearly, the most successful and talented engineers tend to meet those above qualities. I'd rather hire an engineer that was less experienced but was a fireball of energy and enthusiasm. Also they are ones that would be willing to charge ahead and take risks, even if it is the totally wrong direction. They are kinda like a pinball. The times when the game is the most exciting is when the ball is bouncing around in all different directions. And you can think of the senior engineers as the paddles. They are constantly redirecting and sending the ball back into play, which is how you score the most points.
Yes, that metaphor will break down at some point because eventually that pinball will need to become a paddle. My point is that an engineer may have memorized Donald Knuth's books but is so afraid of making a mistake or “not measuring up” in the eyes of their peers or the senior staff, that they are paralysed by this fear. Yes, they will complete a task... eventually... and it will be correct and relatively bug free. The problem is that you don't know when it will be complete. And sometimes, it may not get done at all. Someone who is willing to make mistakes and can take direction and critiques, will usually outperform someone who tends to be paralyzed by some fear.
Of course, this person can become a liability, but that is usually when they fail the final item in my initial list; teachability. So taken altogether, a junior engineer with the above qualities has the most chances for success. Coming onto the team with agendas, and preconceived ideas on how things should work, and refusing to accept that the more experienced team members may have already thought about all the various angles, is a sure recipe for disappointment and discouragement. In my direct experience of being on the Delphi team since its inception, I've seen both types come and go from the team. I'd have to say that for all the junior engineers that have come and gone on the Delphi team the ones that met the above conditions have contributed to the team far above some of the more reticent members have done. I've enjoyed watching some of these junior team members move up into the senior ranks. They are given larger, more critical tasks. They also don't require as much guidance and direction... but what is an interesting trait they tend to develop is they now actively seek out feedback and criticism from their peers and the top-staff members. They usually have spent a good amount of time thinking about the problem critically, and mulled over several solution scenarios. By the time they begin seeking feedback, all the “stupid” questions are out of the way and the real “meat” of the problem can be discussed.
Now before you start reading between the lines and think that I'm trolling around for new hires, this is just a few thoughts I've had recently and thought I'd get them out before they evaporated. Which probably explains why some of my metaphors are a little odd at times... then again when you consider the source... ;-)
Friday, April 29, 2005
So while I'm waiting for the latest new bits of Delphi goodness to be assembled into some machine readable goop... I figured I'd take a few moments to spew a few thoughts...
You know those little “X”s on the editor tabs in Delphi 2005? The ones that you either absolutely revile as the spawn of the devil, or on the opposite side, they're the Messiah's second coming. Quite frankly, I'm someplace in the middle... well maybe more toward the Messiah side... When we were considering putting them into Delphi (ie. the Galileo IDE), we looked at how these little images of controversy were handled in other environments. The first such environment, which was also the most logical, that we looked at was JBuilder. So we fired up JBuilder to do some research (such as it was). After playing around with them for a while, I found some usability issues with them, but overall Corbin and I really like the idea. (an aside: the Eclipse IDE has a similar feature as well) Here's a few that I found...
- It is easy to accidently click the “X” and close the tab.
- They increase the width of the tab, thus decreasing the total number of tabs visible (JBuilder also has a glyph next to the “X“ that shows the content type).
- If you want to close many tabs in succession and since the tabs were varying widths, you constantly have to shift the cursor to the new location of the “X“ on the next tab.
The first item is probably the #1 complaint among the “spawn of the devil” crowd. I, too, sometimes have found myself accidently clicking that little “X” when I don't fully pay attention to what I'm doing. I mean, I'm deep in the middle of a bug fix or some sort of feature work and I want to click over to some other tab, and bam! I just closed the tab. So now I just Alt-F,R,5... That's File|Reopen|5. . I've just gotten used to quickly doing that little dance. OK.. so that's the first problem.
The next one is... well... really hard to quantify. If you hate the “X”, then #2 is probably one of your supporting arguments for removing them. That's fine, but I also think it is a data point that also can stand on its own. Screen real-estate is a finite resource and needs to be carefully parceled out. Now that doesn't mean that we create butt-ugly UIs under the pretense of the almighty screen real-estate. It means that there needs to be a balance. I often hear folks, especially among the software engineering illuminati, “We don't need all that eye-candy!“ Riiiight... If that were the case then we'd all be driving Gremlins, Pacers, or Pintos. That's why I have a Monet print and an actual oil reproduction of a Monet painted by my mother hanging in my office (both from the Water Lilies series, for which Monet is very famous. And yes, Monet is one of my favorite classical artists). Right next to the cool 4ft (120cm) wide poster of an F-15E in flight... All of it is “eye-candy.“ Of course these posters all have their own stories themselves, which I'll save for another blog entry.
The last item is somewhat subtle. One of my first thoughts when I saw the “X” on the tabs, was “That's cool! I can now quickly close a lot of files without a lot of clicking or mouse movement.” Well.. not quite. So you would close the tab, and the tab to the left would slide over, but that tab is a different width that the one just closed, so now the mouse cursor isn't directly under the “X” and you have to move it to the left or the right and click again. Grrr... Of course, if you have a habit of double-clicking, you'd probably appreciate that the “X” didn't appear under the mouse cursor.... sometimes.
So with all these negatives, why the blazes did you put that in the product? First of all, it is just so dang useful and convenient. Also, we solved the #3 problem by having the tab to the right slide over, which would always put the “X” right back under the mouse cursor. It's also kinda like chocolate.. you know that too much of it isn't good for you, but in moderation it's pretty tasty.
So, now that we've shipped a couple of products with the “X” and have received some feedback from all the various factions out there. You know, the “spawn of the devil” folks and the “Messiah's second coming” folks. So we're considering a bit of a change. What if the “X” was at a fixed location? Say it was all the way over to the right side of the tabs?
That would solve the all the complaints I listed above. However it would introduce another problem. Since there is now only one “X”, you can only close the active tab. Which was one nice thing about the “X” on the tab; you could close an inactive tab by clicking on the “X” directly. I suppose we're at a point where a descision needs to be made. Right now, we're internally using this change for the next release of Delphi to see how folks like it. So far the response has been positive... well OK, not all positive since there are those that “want their 'X' back!” Now before you suggest it, no, I'm not going to make this optional. So we have to weigh the advantages and the disadvatages. So far, I'm inclined to think this is a reasonable compromise between both camps. Be warned, however, please keep your comments to the point and well thought out. Any comment I think is disrespectful and rude, I'll delete. Think critically about the problem, and consider each side regardless of your personal opinion. Yes, ultimately, the original decision was based on our (the developers and the overall team's) personal preference, and it still is. Yet, feedback is still key in how we form our preferences and opinions. Being, ourselves, developers we like to think of ourselves as advocates for the customers. Like all groups, there are the radical fringes, but you have to take the bad with the good.. and luckily, for the Delphi community, it is mostly good. It makes our job more enjoyable and satisfying.
With that, have fun... ;-).. And, hey, if this works out, I might try and address the “my glyphs are overlapping in the editor gutter!” (OK, Nick?) issues... Talk about a field full of landmines...
Monday, April 25, 2005
Friday, April 22, 2005
Brian Long, Delphi Consultant Extranordinaire, has some cool web pages describing all the various “Easter eggs“ that have been in Borland products over the years. I'm somewhat partial to this one in particular...http://www.blong.com/Undocumented/Delphi5.htm. In other words, the text file and project manager trick.
For the record, though, I did not put this one in the product. There was a period of about a year and a half where I played R&D manager in addition to having actual product deliverables for which I was responsible. It was done by two of my direct reports, specifically, Chris “debuggers 'r' us” Hesik and Dave “I don't have a blog” Wilhelm.
Tuesday, April 12, 2005
Someone in the Delphi non-tech newsgroup had posted this link to the NASA Goddard Space Flight Center Rapid Application Development Lab that explains their rationale for using Delphi in the creation of the Data Trending & Analysis System (DTAS)... uh.. whatever that is ;-). But hey, its written in Delphi! If you browse to the “Introduction” page (or follow this specific link), there is an excellent paragraph describing their reasons for selecting Delphi as the tool of choice. The best quote is “ (i.e., it placed no measurable limits on what we could develop).” That about sums it up...