Tuesday, June 27, 2006

It's Obvious...

I usually steer clear of controversial subjects such as the notion of software patents, mainly because I am somewhat conflicted on the subject myself since I've filed for patents here at Borland.  On one hand, one should be able to gain patent protection for a new and unique invention (or in the case of software, a process).  On the other hand, with the seemingly whacky patents that have been granted over the years for what many agree are obvious uses of existing technology (can you say, OneClick?).  Well it seems that the U.S. Supreme Court is actually going to hear a case and possibly rule on what should be considered "obvious to a person of ordinary skill in the art."  This article on ArsTechnica outlines this case.  There's also some links to the actual petition.  What is really interesting in this case is that the petioner actually won their case in the U.S. Court of Appeals!  However they felt that the court didn't rule on the premise of their argument which is based on a 1952 federal law regarding the obviousness of an idea or invention.

Regardless of what side one falls on the whole notion of whether or not software should be patented, the fact of the matter is that software is patented.  So if you refuse to file for patent protection on your new and unique ideas simply on principle, you may find that that is all you've got to fall back on when someone becomes wildly successful based on your idea.  Or even worse, comes after you with an infringement suit because they patented the idea.  Until the current U.S. patent system is reformed or at least clarified, your only choice is to take a defensive stance and try and patent as much as you can.  In many cases the best you can hope for is a stalement if someone comes after you with an infringement suit.  If you have your own portfolio of patents, chances are the person filing suit against you may be infringing on one of yours.  So the only recourse you have is to cross-license the patents.  If you had nothing in your portfolio, then you could be liable for major damages including on-going license fees.  The really nasty kicker is that if the plaintiff can show that you had prior knowledge of a particular patent and infringed anyway, you could be liable for triple damages!

Whether or not this case presented to the U.S. Supreme Court has any affect on the patent system remains to be seen.  It does, however, look to be a step in the right direction.

Friday, June 16, 2006

What a Week... OLE'!!

I must say that this has been a quite a week for DevCo.  It started off with Nick Hodges arriving on campus, signing his offer letter, getting a new email account and ordering his new machine.  It's all good.  I mean we have a new key hire... it's been a good week so far. 

Then early this afternoon, Steve Shaughnessy stopped by my office beaming and smiling... "Jens just signed!  He's in Mike's office right now!"

Immediately after my jaw was retracted from the floor, and my eyes were firmly back in their sockets, I said, "WooHoo!!!  That's fantastic news!!"

So who is Jens?  Well I'm referring to Jens-Ole' Lauridsen (usually pronounced as "Yens").  Steve Shaughnessy and Jens-Ole' were the dream-team behind the JDataStore product.  For many years Steve and Jens developed and maintained that product.  They also produced a .NET version called, for lack of a better name, NDataStore which was shown in preview form at the 2004 BorCon.  Later in 2005, Borland decided to end-of-life the JDataStore and to stop development of the NDataStore product... a sad day indeed.  As I'd explained in my introduction to Steve, Jens had also left Borland last year.  In fact they both went to work for the same company.  So I'm pleased to announce that we now have the dream-team behind the JDataStore and NDataStore products now in charge of the BDS database/connectivity pieces.  What does this mean for JDataStore and NDataStore?  Well... basically Nick will now be helping us decide that.

I'm also hoping that I'll be able to make an announcement concerning a new Delphi Compiler engineer within the next couple of weeks!  Once we have all the i's dotted and the t's crossed, I'm sure folks will be pleased with what we'll have to say!  (No, as totally fantastic as it would be, it's not Danny).

Yes, it's been a good week for DevCo.  We had a DevCo "all-hands" meeting here in Scotts Valley with Tod Nielsen following our weekly DevCo board meeting.  Things are progressing very well and the interest has been outstanding.  Of course I can't make any announcements, but I do know that we're very close to having some news to share.

So what could be better that a week like this?... OK, besides already having an investor selected and being a separate company...  Well how about taking a little respite?  Yep, I'll be out next week on vacation.  All the kids are going away to a house-boating and wake-boarding trip with a bunch of other teenagers out on Lake McClure.  So it's just me and my awesome wife without the kids!  As much as I like my co-workers and communicating with the wonderful future "DevCo" customers... I have to admit that spending a week of quality time with her is just a good continuation of an already great week.

See you week after next!

Thursday, June 15, 2006


Nick's now online on the Borland (soon to be the "DevCo") blog server.  Not much content, but then again he's only just begun!  Get your RSS readers out and drop in a new bookmark.  This one's going to be a must read.

Wednesday, June 14, 2006


Where do I start?  I guess I'll just blurt it out... The ever-present, Delphi champion extraordinaire, now ex-TeamB, Nick Hodges has just joined the DevCo team!  Nick will be performing his duties as the Delphi Product Manager.  This is an important position and one I'm sure Nick will perform in admirably.  He will be responsible for all the incoming ideas, requirements, and direction for the Delphi portion of the BDS product (we're still looking for a C++Builder Product Manager).  Nick will be working for Michael Swindell, the DevCo Director of Product Management, whose responsibilities have expanded to include all DevCo products.

I'm excited to get to work with Nick on a day-to-day basis!  I've had the privilege of working with Nick while serving on the BorCon Advisory Board for some past conferences.  I'm sure Nick will continue to be a prolific blogger and will be very active in soliciting feedback from the community about features, functions, and directions for the Delphi product.

So welcome aboard Nick!  Please join me in congratulating him and raise your glass as a toast for great things to come!

Friday, June 2, 2006

The Curse of the Code-Writer

After having seen a lot of software engineers, inspected their code, fixed their bugs and otherwise worked closely with them... I've determined that there a several types of software engineers.  Now I'm sure a lot of you are going to bristle somewhat at the fact that I'm categorizing people.  Face, we're all categorized all the time.  If you've ever filled out a census form... you've been categorized.  So agree or disagree, that's fine.  However I also think most of you will probably relate to this very well and have observed very similar phenomena.  None of these categories are absolute.  Most software engineers posess some blend or mixture of all of them.

The Code-Writer

The first type of engineer is what I call the "Code-Writer."  This engineer is probably the most dangerous type to have on your team.  At first, you're excited by having this engineer.  I mean, this person cranks out mountains of code very quickly and it actually works.  So what's the catch?  Version one of your product ships, gets great reviews, there's a few rough edges, but, hey, it's version one.  So you now start working on version two.  This is where the "Code-Writers" begin to show their true colors.  You now ask them to add a new feature to their code.  Whoops!  The first thing they do is come back and say "I gotta rewrite the whole subsystem!"  Not just refactor it, or tweak the design a little bit, bit wholesale drop the bits on the floor sweep them into the trash and start fresh.

The problem is this.  This person is just a Code-Writer.  They can't look at a chunk of code and fully understand it in such a way that they can effectively maintain and enhance it.  Even for code they wrote themselves!  This type of engineer is especially prone to do this for code they didn't write themselves.  More times than not, it is far worse to rewrite code rather than refactor and redesign.  This means that more time is spent, unit-test have to be redone, and QA is not confident and has to do a full regression cycle on the entire product.

The Code-Reader

This next type of engineer I call the "Code-Reader."  This engineer is probably the most useless type of engineer for a software production team.  As the name implies, this engineer is really good at reading and understanding existing code, whether they've written it or not.  Mostly not, because as the name also implies they don't ever really write code.  Oh sure, they may actually type some code into the editor, compile it and even have it working... only on their machine!  So either way (never really write code or simply never check it in), this type of engineer is an albatross around any software team's neck.  For the ones that actually write code but never actually check it in, this is typically a confidence issue.  They are afraid to check in because they may break the build, or someone will not like their code, or there is some other fear that keeps them from actually submitting code.  The former, the one never even writes code, is probably a lost cause... the latter is probably salvagable if you have a psychologist on staff and can figure out why their parents hated them...  Bottom line, you eventually stop assigning critial tasks to this person which tends to feed more into their insecurrities.  It can quickly spiral.

The Code-Designer

This final type of engineer, the "Code-Designer," is a wiley bugger.  This person interviews very well, and is usually hired on in a more senior capacity.  He impresses the managers and even the other engineers on the team.  The thing is, this person is a great thinker... and that's it.  Ask them to actually write the code behind their killer application design and architecture... well you may as well ask them to compose a Concerto in Dminor... Oh, they actually write code.. check it in... and it even passes the unit-tests.  But when you look at the code, it is hideous!  Poor and inconsistent formatting of the code is the rule.  It looks like 20 different engineer's wrote the code with no eye for a consistent or team agreed-upon coding style.  CS101 algorithms are about all you get in terms of implemenation details.  And finally, the actual code only peripherally matches the design.  So, on paper, the design is great and gives great Powerpoint... but when the rubber meets the road.. it's flat.

The Blender

So there's the categories.  The Code-Writer, Code-Reader and Code-Designer.  The good news is that most engineers are a blend of all three.  I'd say that the most valuable and generally useful engineers are the "Code-Reader-Writers".  They are good solid mid- to high-level engineers.  They produce the bulk of the product's code.  Most Code-Reader-Writers also will have a good amount of Designer in them as well which means that they can solve problems in very clever and robust ways.  They also have some level of leadership skills and are good mentors.  You need your team to have more of these engineers than the next valuable blend. 

The Code-Reader-Writer-Designer is the next most useful blend.  As the name implies, this is a senior-level engineer that also provides a high-degree of technical leadership while maintaining a good down-to-earth understanding of the day-to-day bits and bytes.  They can usually jump in anywhere in the product and be helpful and productive.  It is good to have a few of these on the team with the number proportional to the team's size and age.

Some teams may actually have a Code-Designer, but most folks call them the analysts or the architect.  Many times they never actually work on the code but instead prefer to live their life in Powerpoint, UML, Visio, and email.  This actually works for a lot of very large software teams that have huge numbers of Code-Reader-Writers and/or Code-Writers.

So there you have it... my personal, totally biased, non-scientific, probably irrational categorization of software engineers.