A Wii bit of fun and games... Or what does milk have to do with a Wii??

My wife sometimes actually reads my blog.  Of course I get a some of grief about it and a few chuckles at home.  I also get the random threat when I do something bone-headed at home where she tells me that “I should post a comment on your blog and tell people what you're really like!”  I'm sure many of you can relate :-).  My wife likes to tell her friends things like, “he deals with all kinds of high tech stuff and helps lead a team of equally, if not more, talented engineers... yet he can't even remember what night is trash night!”  Suffice it to say, my wife is not at all impressed with what I do here at CodeGear, which is actually something I like.  It helps keep me a little humble (yeah, right! ;-) and a little more grounded.

Last year I made this post talking about how CodeGear needs to take a page from the Nintendo playbook surrounding their brand new gaming console called the Wii.  Ever since then, I've been keeping and eye on the Wii and it's availablity over the weeks following it's introduction.  Sales are still going strong for the Wii, and Nintendo is reporting strong sales and equally strong profits.  While the PS3 and XBox360 are getting more press coverage about how they're not doing as well as the Wii.  The more I read reviews about it and then talked with our very own David Lock who actually acquired his Wii console by paying a premium on eBay, the more I thought that this is actually a game console I'd by for myself.  Of course there are several PS2s, a GameCube, an XBox, PSP, NintendoDS at home, but they've all been purchased by and/or for my kids.  I've never really cared to have my own gaming console.  The Wii actually changed my mind.

So last weekend, I'd heard that some of the local purveyors of video game consoles were to get a fresh shipment of Wii consoles on Sunday morning.  So I got up and headed out to score my very own Wii console.  Didn't work out.  I was a little too late and the vouchers had all been handed out an hour before the store even opened!  Oh well...

So I come home a couple of days ago to find a couple of brown paper wrapped packages sitting on the counter. My wife and some of my children were in the kitchen when I came in.  Apparently these were some belated Christmas presents (since we ended up returning my main present due to it being defective had not replaced it).  So I opened them.  One was a huge bottle of Tums (an antacid)... gee thanks, I guess I could use those for all the stress here at CodeGear ;-).  The next package was a huge box of instant oatmeal packets that I keep in my office that I eat for breakfast when I get into work in the mornings.  Thanks, I can certainly use that too.  As you can imagine, I figured something was up...  So my wife then drags out another even larger package with the same brown-paper wrapping.  By this time, I was figuring it was another goofy gift as I've become used to being the butt of many jokes at home... I shaked it... nothing rattled too much.  I squeezed it... it was firm... must be another box.  Then I opened it.  I was shocked!  It was a Wii!  Apparently it was a very serendipidous event that she was even able to locate someplace that wasn't sold out.  We do a lot of shopping at the local warehouse club/big box/bulk store Costco, which is similar to the Sam's Club stores that dominate the mid-west US.  Anyway, she was grabbing some various items like food and other consumables, when as they were loading up to head back home, one of my sons who was helping noticed that the box of milk was leaking (only in America can you go to a store that sells milk and 60” HD plasma TVs!).  So they headed back into the exchange the milk, when they noticed one of the workers rolling out a brand new palette of Wii consoles!  SCORE!!

So it's been a couple of days that I've been able to play with this new toy, and so far it is everything and more.  I'm not one to sit down an play a game for hours, especially some Action Adventure, FPS, or MMORPGs since they really require a lot of time and investment.  However the Wii, with it's motion sensing wireless controllers, has enabled a new generation of “get off the couch and move” games.  So now I can go in and play a game of bowling, or tennis, baseball, golf or even boxing.  And that's the only investment I've made.  The whole family can get together and play a game.  They've even suggested that with this new generation of motion sensing controllers and more immersive and interactive gameplay, video games no longer have to be the pudge-inducing, lazy couch potato creating, bane of modern society.  Hm... maybe I can use the excuse that I need to shed a few pounds to wrestle control of the TV away from the kids and play some  games.

How can you raise an "Out of Memory" exception when you don't have any?

Or, “How to take a simple problem and create a complex solution.“

In the early days of developing Delphi we pondered that very question.  How can you allocated an exception object on the heap when the memory manager has already just told you “Hey the memory's not here man.”?  The answer to that turned out to be remarkably easy and once we realized that, there was a big “DUH!” moment on the team.  Before I reveal the ultimate solution, let's talk about the stops along the way.  I want to highlight this early solution to demonstrate that simplicity is very often the right approach.  If you find yourself layering ever more complicated logic and architecture to solve some rare edge condition case, maybe you should first stop.  (the first step in getting yourself out of a hole is to stop digging ;-).

The original approach to this problem involved creating a separate heap that was reserved at application startup and would hold these “special case” exception object instances.  So when the memory manager would detect that it is unable to satisfy an allocation request, a runtime error would happen which is trapped by the SysUtils unit's exception hook and translate that error into an exception that it then raised.  The problem is how do you allocate a class instance on a different heap?  This is where the class function NewInstance was introduced.  If you override that virtual class method, you can control where and how the object's instance memory is allocated.  The corrollary method is not a class method but is an instance method called FreeInstance, which as you can see would return the memory to the heap.  That looks simple, right?  Just override those methods on the EOutOfMemory exception class and you're sure to always be able to allocate an instance of that object.  In the early days, this was how it was done and it worked fine.

The problem was that we'd set aside this memory at startup, but the question was how much memory?  Enough for one, or two instances?  Ten instances?  Another problem was that it meant having another memory manager that would only manage memory from this small heap off to the side.  It was becoming clear that this solution, while it worked and seemed very clever, it was just too complicated.  What is interesting is that buried within this original complicated solution, was a better solution just staring us in the face.  Can you guess what that solution is?

It turns out that it was as simple as just pre-allocating the exception class instance... DUH!!!  No need to create a separate heap with its own memory manager, no need to override NewInstance and FreeInstance.  We really had no further need for those two methods so we could remove then, right?  Not so fast.  What if someone wrote an application that actually handled the Out Of Memory exception and was able to relieve the memory pressure (say, by freeing some easily recreated cached objects) and continue executing.  The problem is that you don't want to let the EOutOfMemory exception to ever be freed.  How do you do that when you cannot control the exception processing logic which will always destroy the currently raised exception object once the the handling “except” block exits?  Remember the NewInstance and FreeInstance methods from our overly complicated solution?  What if you just overrode the FreeInstance method and it simply did... nothing?  So now the EOutOfMemory exception instance will remain for the life of the application and can be used over and over again.

So why didn't we remove the NewInstance method and just leave the FreeInstance method?  This is probably best characterized as a classic case of serendipity.  It turns out that being able to control how and where an object type or a whole class of object type instances are allocated and freed can be useful in solving a very wide variety of different problems.  Rather than have lopsided methods, we kept the NewInstance and FreeInstance methods so that our ever industrious, always clever, customers would be able to do some new an interesting things.  It would have also meant a compiler change to the codegenerator to remove the call to NewInstance.  So the general usefulness of the feature along with not wanting to potentially introduce a whole slew of new codegen bugs, were a couple of reasons to leave it alone.  We did remove the mini heap manager since we were not using that anymore.

So there you have it.  A little bit more history about the early development of Delphi.  Many times the simplest solution is the right solution.  Having a complicated “clever” solution can come back to haunt you later down the road.

The year ahead...

Welcome to the new year!  A new year is a convenient opportunity for one to shed some of the negative baggage from the past year(s) and concentrate on doing better (personally, professionally, family, etc...) throughout the coming year.  My pragmatic and skeptical side tends to eschew such patently “false” and “self-delusional” things like new years resolutions.  I far prefer to be retrospective in December to see how I did, rather than setup up some “pie-in-the-sky” aspiration formed late on December 31st only to stumble and become discouraged or outright forget by January 3rd.  This is why I posted my year in review last week.  To be blunt about it, on January 1st, 2006, I had nearly no clue about what 2006 would hold.  I had reasons to be cautiously optimistic.  However, as we all know, some pretty big changes came about in 2006.

That said, I'm not going to let that stop me from making a few bold predictions and set a few goals for 2007 ;-).

• CodeGear officially launches in Q1.
• CodeGear releases several new (as in not Delphi, C++ or JBuilder) products in 2007.
• Newly revised Delphi and C++ roadmap published.
• Overall CodeGear team grows throughout 2007.
• Increase the overall “fun-factor“ for those that work at CodeGear (hmmm.... maybe we need Nerf guns for all the engineers??)

There's probably more that I haven't thought about right now, but that should get things started. 

On another topic, apparently I completely missed being “tagged” by Nick.  Now it has come to my attention that Chad Hower (of Indy fame) has also tagged me...

So here goes:  Five things you (probably) didn't know about me...

• I have not piloted an F/A-18... But I do have a really cool picture of an F-15E on the wall in my office ;-).  I've had other engineers over the years offer real money for it!
• I started to build a robot when I was 13 and actually have working arms, base with motorized wheels, and body. It kinda looks like R2D2.
• Before CodeGear(and Borland), I used to design, prototype, build and program magnetic stripe encoders and access control equipment.  I had this job within 1 year of graduating high-school.
• I have a patent that is currently pending.
• My favorite SciFi book was Dune by Frank Herbert.  In fact all the machines I've had over the years are always named for something from those books.  The name of the machine I'm using right now is Atreides.  There is also Sardaukar, Feyd, and Shaddam in my office but many other names have been used over the years.

So that's it.  I guess I need to “tag” someone else now?  How about Marco Cantu and Dr. Bob Swart?

A year in review.

Officially, CodeGear (and Borland) are in the midst of a holiday shutdown.  This is because the week between Christmas and New Years is never a very productive week due to many people taking the time to spend it with their family and friends.  With the new year approaching, I thought it might be good to spend some time reflecting on all that has transpired throughout the venerable 2006.

January 3rd, 2006 - Met with Tod Nielsen for one of his 100 one-on-one's in 100 days.  I vaguely discussed the content of that meeting here.  One thing I did not discuss in that blog post was that the subject of spinning-off Delphi (and friends) into some kind of separate company or subsidiary was actually mentioned.  It was mainly couched in terms of “fantasy“ and “what would the world be like if.“  I related the many conversations among Gary Whizin, Chuck Jazdzewski, Anders Hejlsberg and myself where we would all wax poetically about this subject.  Little did I know ;-).

February 7th, 2006 - Received a phone call from Rick Jackson (then the acting VP of R&D at Borland) letting me know about an announcement about to go over the wire the next morning.  Began working on a blog entry to be posted immediately following the actual public announcement.  Didn't sleep very much that night, that's for sure.

February 8th, 2006 - Fly! Be Free!  This is a date that will stick in my mind for many years to come.  Borland announces both the acquisition of Seque Corporation, and their intention of selling the Developer Tools Group to a yet-to-be-named investor or entity.  I still believe that Borland pre-announcing the intent to sell the DTG was the best approach.  There is simply no way to keep something that big and involving that many people secret for very long.  The rumors and speculation would have been far more distracting and frustrating for everyone involved.  How do to even keep something like this from the rank-and-file employees when you're asking for information how to separate internal computing systems, divide up the sales and support staff, and all the hundreds of thousands of little details?  Wholesale acquisitions of a company can far easier be held close to the vest, but for the DTG business which has been so intertwined with everything in Borland, you just could not keep it sufficiently “under wraps” for very long.

February 23rd, 2006 - The first of my “DevCo” - XX days after announcement posts.  The intent was not only to keep the customers informed, but also to make sure everyone was aware that there are real people behind these transactions.  I also wanted to make sure there was some trickle of information to let folks know that, while the content and substance of all the “behind the scenes” work could not be divulged in detail, it was clear that work continues.  One statement I made in that post was that “Once the deal closes, we can remove the Cluetraining wheels.”  As we move into 2007, those training wheels are now off.

March 16th, 2006 - Things you always wanted to know... This is an interesting post not just because of the content but because the reference to “Ed” is actually none other than CodeGear's very own Ben Smith!  So now you know ;-).

March 21st, 2006 - "DevCo" - 5 weeks after spin off announcement.  This post caused a bit of a stir among the “bankers” involved with the whole spin-off.  Apparently my progress posts began to be the only real source of information for the press since our PR firm was regularly contacted for clarification about certain posts I'd made.  The main sticking point was the mention of BearStearns and their reactions ;-).  From this point on, when I'd walk into the room for a meeting and the “bankers who shall not be named” were present, I'd get the obligatory “No blogging about this meeting!”  It actually became a kind of running joke for many months... with a hint of seriousness tossed in.  One thing I will note was that Ben Smith, was a supporter and still is, of my blogging and rarely did I ever get a “you stepped over the line” from him.  I'll admit that I certainly did push hard on the line throughout that period!

March 24th, 2006 - "DevCo" - Ping....  This was one of the first posts to highlight that even during the whole spin-off process, we were committed to appropriately growing the team.  We'd just hired a new compiler engineer to help on the C++ compiler.

Aprin 1st, 2006 - "DevCo" - 1 year after spin out announcement... I'm certainly happy that we didn't actually go more that one year to get to CodeGear.  However, that didn't stop me from having a little fun at our own expense.  I will, however, point out that while I was having some fun with that post, there was some drama happening behind the scenes regarding how we're going to carve up certain shared technologies and services.  I just took the opportunity to poke some fun at the process.

April 17th, 2006 - One Intern, Two Intern... Red Intern, Blue Intern....  We like interns.  Especially the “Asok” variety ;-)  One thing to note here is that we did hire an R&D intern over the summer, and have now offered him a full-time entry level position.  So, if you're in the S.F. Bay area, are a C.S. or C.E. student, let us know.  CodeGear can use you and you can get some valuable real-world experience (at least as “real-world” as it is around here ;-).

May 4th, 2006 - Borland announces "DevCo" progress...  The first official word from Borland that the Developer Tools Group was an independently functioning entity within Borland.  This was also the first time I really felt like I was in a different company.  I mentioned the company (Borland) meeting and how I really felt more like an outsider than actually a part of Borland.  From this point on, that separation just became more and more pronounced.

May 26th, 2006 - Questions, comments, suggestions, smart remarks....  This was the start of the Developer Tools Group soliciting the customers and the general public to send in their name suggestions on what we should call this new company/entity.  CodeGear was actually born out of all the myriad of suggestions we recieved.  I don't think anyone actually mentioned CodeGear specifically, but there were a lot of CodeXXXX and XXXGear suggestions.  Michael Swindell simply culled through all the suggestions and came up with CodeGear.  There were about 4 other top candidates for the name.  Since we do own the domains for those other names, I'll not mention them here since we may actually decide to use them for other things in the future.  In an internal Developer Tools Group poll, CodeGear stood head-and-shoulders above the other suggestions.

June 14th, 2006 - Nick-alodean.  This was an excellent day!  We finally convinced the ever present, tireless, Nick Hodges to join the Developer Tools Group!  I've known Nick ever since he posted, arguably, the first “Open Source” Delphi component, TSmiley.  As a long-time member of TeamB, and staunch Delphi supporter, it seemed so natural to invite him to to the helm of Delphi.  Nick has never been one to shy away from controversy and attack the issues head-on.  Since joining the Delphi team, sipping from the proverbial firehose, and being tossed into the deep end of the pool, he's becoming a clear asset to the Delphi product and the team.

July 7th, 2006 - It's a little quiet around here...NOT!  This is one of my first posts in reference to entering a “quiet period” during the spin-off process.  This is merely a period imposed both internally and by the rules of a publically held corporation to ensure that the whole process goes as smoothly as possible.  As it was explained to me, we could not have any information from this point leak out through unofficial channels (and, yes folks, this blog is about as “unofficial” as it gets).  Those deeply involved wanted to be spending more time on the details of the actual process and not get distracted by having questions about some trickle of information.  This only serves to make all those involved nervous and distracts from the core of the transaction.  We could not even hint at how many and what type of interested parties there were.  Standard fare for these kinds of deals.

August 7th, 2006 - They're baaaack.... Even during the “quiet period” imposed about the details of the spin-off, we here at the Developer Tools Group (CodeGear) were anything but quiet.  This marked the release of the Turbo editions of the Delphi and C++ products that were part of the Borland Developer Studio.  We also introduced the Explorer Editions of the Turbo products as a freely available download.  To date, 100s of thousands of the Turbo Explorer editions have been downloaded and continue to be very popular.

September 12th, 2006 - Will the real "DevCo" please stand up.  I just couldn't pass this up.  As some collegues and I walked back from lunch, we saw this truck entering the campus parking lot through the entry gate.  As we walked around to get back into the building, I snapped this photo with my camera phone.

October 30th, 2006 - New Delphi Survey.  The annual Delphi survey is posted.  The results of this survey and many other sources have a very profound affect on our product plans and roadmaps.  One small change to the roadmap that has been hinted at since Nick Hodges presented it at a user group in Amsterdam, is the movement of Unicode support for Win32 to the release following Highlander instead of Compact Framework.  Other changes are coming, so stay tuned.

November 14th, 2006 - CodeGear := TCompany.Create;  Finally!  Yes, I know, I know.  It was not exactly what we'd planned on, but it is certainly close!  After having been allowed to “peek behind the curtain” throughout the whole spin-off process, I'm still excited and totally stoked about being able to control our own destiny.  Yes, I know that this isn't going to be easy.  Yes, there is risk.  And, Yes, I'm a little scared!  However, it is a motivating fear, not a paralyzing fear!  A little bit of fear is actually good!  When you mix a little bit of fear with confidence, you have a recipe for success.  Without the formation of CodeGear and all the other events over the last year, I scarcely cannot even imagine what state Delphi, JBuilder, C++Builder and InterBase would be in.   I choose to not dwell on such things and only remain thankful that we are where we are.

November 27th, 2006 - Cough... cough....  As the dust clouds began to settle and the initial reactions to the CodeGear announcement began to wane, I offered my opinions on what this all means.  The good thing is that we can all put it behind us, pick up what we've learned, and charge ahead into 2007!

Well, there you have it!  It's been quite a year and that was only the highlights.  I haven't mentioned that we've hired and re-hired a lot of new and established talent.  We've been very hard at work on the product roadmaps to better adjust and align them to customer demands.  The dev teams have remained focused and are working hard to meet the roadmap goals and milestones.  We all here at CodeGear are beginning to feel more in control and are closer to how we drive success.  The distance between our CEO and the rank-and-file CodeGear employee is a mere 3 steps.  Unlike Borland where it can easily be twice or more than that.  The CEO and our head sales VP sit up here on the third floor with all the developers!  In fact, Nick Hodges is sandwiched between them!  After the first of the year, there will be no Borland employee here in the CodeGear, Scotts Valley campus.  Sometime in Q1, '07 we'll be officially “launching” the CodeGear company.  In the meantime, our marketing team is hard at work getting ready for this event.  As a matter of fact, last week I attended a meeting with the marketing team and an outside “branding firm” that will be helping us get the message out about what CodeGear is and what it stands for.  I found in interesting that the head of this outside firm was actually part of the Borland marketing team during the heyday of the developer tools.  I think this firm may actually have a clue about developers.

I want to take the time to thank all of you who read this blog (all two or three of you ;-).  I've tried to be as forthcoming with information and my own insights as I can.  I've also appreciated all the comments and reactions over the last year, even the ones I don't agree with :-).  Happy New Year!  I wish you all a productive, successful, and enriching 2007!

Holiday wishes.

With the holidays approaching, let me take this opportunity to wish everyone a happy and exciting Christmas and new year.  2007 is shaping up to be an interesting year for all of us at CodeGear.  So be sure to keep watching for upcoming announcements about the official launch of CodeGear.  So stay safe and enjoy spending time with your families.

Delphi, from a fresh perspective...

Here it is December 10th and I guess I've been so busy helping build CodeGear and getting plans in place for Q1 '07 and beyond that I completely missed an excellent blog post by Steve Shaughnessy, the new Delphi database architect.  Steve outlines his experience in learning Delphi, the language, and the VCL framework.  I bring this up because as Steve states, he's been with Borland for 17 years and had somehow avoided ever having the priviledge of using Delphi (shock!  horror! oh, the humanity ;-).  I have truly appreciated his perspective, insight and fresh perspecitve.  A healthy team is always not only looking forward but is also looking back and re-evaulating past decisions and implementations.  While it is good to look at what can be improved upon, it is also very good to celebrate and highlight all those things that the team did right!  So I encourage you to read Steve's post and feel good about your decision to use Delphi.  And if you're evaluating Delphi, Steve's insights into learning Delphi after extensive experience with many other languages can be valuable.

Wii can learn something from Nintendo...

If you live in the U.S. (or nearly anywhere for that matter) and follow the consumer tech market even at a glance, you surely could not have missed all the goings on surrounding Sony's and Nintendo's recent release of new gaming consoles, the PS3 and Wii, respectively.  What is interesting is while all the crazy hoopla seemed to focus on Sony's frontal assault on Microsofts XBox 360, Nintendo [relatively speaking] quietly introduces the Wii, a much lower priced, less featured, not-nearly-as-good graphics, gaming system. 

On paper, the Wii, is a huge “why bother.”  However on further examination, there is some interesting genius at work here.  Sony and Microsoft are bent on being #1, owning the living room, and being a vehicle for all entertainment and media.  Gaming is beginning to take a back seat.  Nintendo, however, is emerging as being the one player in the console gaming market that clearly knows where it's bread is buttered.  They do gaming consoles, handheld game platforms, and have a much larger library of Nintendo produced games.  That's it.  They're not out to “be the do-all end-all media device.”  It is also worth noting that Nintendo seems to be the only one of the three that is actually very profitable (in the console gaming business).

What prompted this post was that I came across this interesting article in The New Yorker magazine.  What really struck me was this:

“A recent survey of the evidence on market share by J. Scott Armstrong and Kesten C. Green found that companies that adopt what they call 'competitor-oriented objectives' actually end up hurting their own profitability. In other words, the more a company focusses on beating its competitors, rather than on the bottom line, the worse it is likely to do.”

I guess the way I'm going to somehow tie all of this back to CodeGear is to say that, as a much smaller company with a single-minded focus we should really take a few notes here.  We must make sure we focus on what we're purporting to be all about.  We're going to have to have “developer-oriented objectives“, and not “competitor-oriented objectives.”  By doing that, I have little doubt that we can thrive and have a profound impact on the lives of developers.

To steal a line from the Nintendo Wii TV commercials, “CodeGear wants to play.”

Optionitis can kill if left untreated...

If you've been around these parts for a while you've probably heard the above reply to common feature requests. Many times these requests are at odds between several groups of users.  So their typical solution to this impasse is the ever so simple,  “Well, then just make it an option.”  I'm sure there have been those who've scoffed at my response and put me in the “closed-minded-dolt” category ;-).  Well it seems I may have gained a little vindication.  Apparently “Joel on Software” seems to agree.  One could certainly argue that development tools are targeted at a different level of user than Windows itself or your typical word processor or spreadsheet application.  To that I say, why?  Why do development tools have to have a million and one little options for this and that?  We already have different and keybindings, tabs on, tabs off, auto indent on/off,  code completion on/off, etc...  There are a lot of end user reasons to limit the options as Joel so deftly does in a somewhat comical fashion to that faceless team of individuals working on the “start menu.”

However, there are also a lot of practical development side reasons to limit the choices as well.  Many times, just the simple act of adding a single on/off boolean option actually can double your testing efforts!  Ok, that was probably a bit of hyperbole, but it will double a portion of your testing effort.  So now you have to test everything related to that option with it on and with it off.  Add another option, and you're quadrupling the effort.  Think binary here.  In practice there are plenty of relatively safe testing “shortcuts” and ways to minimize that impact.  My point here is that glibbly introducing an optional new feature because “those 5 people I talked with last week said it was a good idea,” is probably not the most responsible thing to do.  Sure, for smaller applications targeting smaller markets, you do have to try and cater to as many as you can.  However, I've seen many, many cases where a better and workable, non-optional solution to a problem (or more appropriately a class of problems) is born out of a whole aggregated class of similar problems.

So when you're asked to “just add this little new feature,” and are inclined to make it optional, just step back and consider whether or not there are other problems within this particular class.  Is this new option worth the extra testing burden?  Is the feature useful to a wider cross-section of your customer base, so maybe it shouldn't be optional but always enabled?  Don't use the option as a “get out of jail free card.”  Sure, if customer X says they just can't stand that feature and you can reply with a simple, “Just turn it off.”  You sure dodged that bullet... or did you?  What if there was some use-case that that customer brought to the table that you had not considered?  Adding an option should not be used as an excuse to not have to thoroughly think through a problem.  Consciously or not, many times that is what is happening.

So for now, I'll still hold that “Optionitis can kill if left untreated.”  Now... at some point we still have to add that error message, “Programmer expected...”

Cough... cough...

Groundwork

Now that the dust is beginning to settle and some of the initial euphoric/shocking/stunned reactions are beginning to subside regarding the CodeGear announcement, I figured I'd weigh in with my perspective.  I specifically wanted to hold off till this point mainly because I wanted some time to fully digest and evaluate what this all means and how I think it will play out in the coming months.  To be fair, it is all still sinking in and there are still fair number of questions we have yet to answer.  Being as close to this whole process as I've been has given me a decidedly unique perspective.  First of all, being a technical kinda guy all my life with little to no desire to ever delve into “business” allowed me to take a kind of “layman” approach.  Now of course I'd also like to think that I'm no spring chicken and still possess a keen ability to analyze and verify a lot of the information I've been able to see.

If you've ever dealt with folks in the finance/business world, they have their own language and speak at a level of abstraction that tends to baffle most folks.  Wait... that sounds oddly familiar, doesn't it?  Isn't that exactly how everyone tends to describe us, in the high-tech world?  We have URLs, ASTs, QuickSorts, etc...  They have EBITDA, Rev-Rec and Cost-Models.  So?  The point I'm trying to make here is that many in the high-tech world tend to eschew all things business.  While this is clearly an oversimplification and probably too broad of a statement, I'm only trying to highlight that the reverse is not necessarily true.  The business side understands that there is value and a market for the high-tech side.  It's their job to recognize and figure out how to monetize and capitalize on those things.

Another aspect of the business side of things is that often maligned and thought of as only “for those other guys,” is marketing.  I guess one of the reasons for that is that marketing is actually about psychology.  I'm not saying that they aren't out there, but I don't know any programmers, software engineers, etc... that also have psychology degrees.  Human factors is close to what I'd consider human psychology mixed with technology.  Psychology is in many ways more of a meta-science than, say, physics, mathematics or biology.  This is probably one reason that marketing has really been misunderstood.  We all know when marketing is trying too hard, is just plain bad and misses its mark.  However when marketing is successful... the target audience doesn't actually feel like they've been marketed too.  The message is clear, resonates, and makes sense.  This is how CodeGear needs to handle marketing.

My Take

As I started this post, I wanted to make it clear that there is a lot of machinery behind this endeavor.  It is also not a “started in the garage” kind of venture.  So the first item is the CodeGear announcement itself and what it means.  During the months following the February 8th announcement of Borland's intention to divest itself of the Developer Tools Group (DTG), a huge internal effort began.  This all started with creating a credible and achievable plan for the next 3 years.  These plans not only included the existing products, but also plans for growing the business and moving into other developer focused markets.  Probably one of the hardest part was to determine what parts would go with the DTG, which parts are licensed from Borland, and how to handle the overall transition.  There were the obvious items, Delphi, JBuilder, C++Builder, InterBase, etc...  But there were also some technologies that had been spread across all the Borland product lines.  An example of this is the licensing.  I've read a bit about how some folks were nervous that they wouldn't be able to activate their legacy products.  I assure you that this was an item discussed all the way to the top.  It was imperitive that we, CodeGear and Borland, not allow that to happen.

With all the late evenings and long weekends we came down to the CodeGear announcement that Borland intends to make DTG a wholly owned subsidiary called CodeGear.  My first thought was... “hmmm... OK... that's interesting.”  I remember meeting with many potential investors and going through all the long presentation sessions.  I did many follow-up diligence sessions.  I discussed the customers, the products, the roadmaps, the teams, the history, the good, the bad, and the ugly.  I must say that nearly all of the folks I met were cordial, engaged, interested and above all, shrewd and analytical.  So after all of that,  it did seem somewhat anti-climatic.  We had been diligently preparing for one specific outcome and something slightly different happened.  I remember early on in the beginning personally resolving to approach this whole process with an open and non-judgemental attitude.  Whatever the outcome, I was going to, as much as I'm able, do whatever it takes to make this a success.  It isn't every day that one gets to participate in the genesis of a new company, in whatever form.

So were the last 9 months a waste?  Absolutely NOT!  As a matter of fact, we're in far better of a position to be successful and run this business.  We have spent the last months shining a bright light on every deep, dark corner of the business.  We've questioned everything.  Quite frankly, we had to relearn this business in the operational sense, and I'm sure this is no real secret, it's been left to it's own for a very long time.  We also have to take into account market shifts and other dynamics.  The great thing is that we no longer have to sit on the sidelines and watch all the action.  Now we have the chance to get in on it.  What is that action?  Things like web development, dynamic/scripting languages, continuned traction in the Win32/Win64 native markets.  Let's not forget the whole .NET side of things as well.  There is the quickly maturing open source movement and a whole ecosystem surrounding Java and Eclipse.  We still have a lot to offer those markets in terms of experience, wisdom, and insights.  This isn't just a whole lot of “been there, done that,” but a chance to actively apply a huge amount of what we've learned over the years regarding what developers need and what.  This is a chance to help shepard in these new technological advances by making them more accessible to the average developer.  Over the coming months/years, I'm certain that the shape of our offerings in those spaces will be very different than they do today.

Balance

This is a hard lesson... for anybody.  Part of why I put this in here is that this is one thing I know developers struggle with.  While CodeGear is clearly focused on the developer, we also know that you can't be all things to everybody.  So in many ways, CodeGear will have to find the right “balance” as it comes out of the gate.  There is a time for whipping out the shotgun and blasting away at a market and hope that something will hit.  There are also plenty more times where the sniper rifle is far more effective.  So the balance comes from when you use which approach.  So, you will probably see some use of the shotgun and a good amount of the sniper rifle as well.

So while the landscape is not exactly how we originally envisioned it, it is very, very close.  CodeGear will be allowed to operate in near total autonomy.  We'll have control over what products we produce and when we release those products.  We also control how we approach new emerging markets/technologies.  We'll have control over our own expenses.  If something costs too much, we either do it differently or decided to not do it at all.  Pretty simple.  We get to decide where to re-invest the profits.  We get to decide with whom we'll form partnerships.

Many of you may remain unconvinced, and that's OK.  I have no delusions to think that we're going to make everyone happy.  A lot of mere talk isn't going to convince some people.  I know that.  So all I ask is that you watch carefully, be patient.  Things are going to begin to happen in the coming weeks.  This will be especially true for next quarter when we get all the nitty-gritty details of the CodeGear business arrangements settled and announced.  The great thing is that I've got more irons in the fire now than I've ever had while at Borland.  We're also at a point where it isn't a question of what direction to go and what to do because we know that it must fit with focusing on the developer.  We're certainly not at a loss for ideas and direction, it is just now up to deciding what to do first and when.  Much of that has already been decided as you'll see in the upcoming weeks/months.  For my part, I'll keep rambling on...  And please excuse the dust as we remodel.

CodeGear Borland, an example

How many times in the past (the Borland past, that is) has the director of IT actually posted a message in the newsgroups?  To the best of my knowledge, a grand total of ZERO times.  There was a thread over in the Delphi.non-tech group about the new CodeGear site and Mark Trenchard, the CodeGear IT director, actually posted a message!  Mark was recently brought on board and was previously with the networking group at HP.  This is certainly a good sign that things truly will be different here at CodeGear.  I will continue to encourage that all CodeGear employees interact with the community where appropriate.