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.

 

DevCon...

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.

 

Progress...

One little motivating item that I see every day as I stroll down the hall for my daily jump start of bean-juice is a piece of paper taped to the wall outside the office of Tim Del Chiaro, one of the program managers on the DeXter project.  On this incredibly low-tech device is some Post-It(r) notes with a digit on each one.  They're arranged in two groups.  One group is the current number of defects that are so critical that they need to be fixed, if possible, before the next build and the other group is the number of defects considered “Must Fix“ before the eventual release.  It is really cool to see that number make significant drops from day-to-day as we fix/resolve the defects in the tracking system.  Tim updates this number throughout the day.  Sometimes even low-tech, seemingly insignificant little things can have a profound impact.