Blog O Sparky

Delphi team member and expert Flamenco guitarist extraordinaire, Adam, has been posting some true gems about Live Templates and some other little nuggets.  Be sure to stop by and tell him how much you appreciate this information (assuming you do actually find the information useful).  Just need to keep him interested in continuing to blog on a regular basis.

Who is this?

An interesting blog:  http://www.subliminal.com.  But the question is.. who is it? Hmmm... ;-)

Recap..

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
untapped.

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.

-Danny Thorpe
Engineer, Google.

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.

First Customer Ship

Looks like Borland Developer Studio 2006 has started arriving at customer sites.  There's now some talk beginning in borland.public.delphi.non-technical, so looks like there'll be some information about it start to flow.

Opening session demo now available

Looks like David I has gotten the video edited and available that shows the last half of the opening session at this year's developer conference in San Fancisco.  I got to demo the live templates right after David I does a C++ demo.  Then Michael Swindell did a cool ECO demo just following mine.

Is quality a destination or a journey?

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.

 

We're taking a risk...

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.

 

Borland Developer Conference presentation.

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.

Defect reporting etiquette.

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!

Preconference day one..

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.