Microsoft has many, many enemies. Microsoft is threatened on the Internet front by Google, on smartphones by Apple, on developer tools by IBM Rational, on databases by Oracle, and on game platforms by Sony and Nintendo.

Yet the earliest Undesirable No.1 was Novell. Since the early 1980s, NetWare platform defined small-business local area networks. The software operating system was ubiquitous and reliable, but also expensive, difficult to create apps for, and required most businesses to use resellers and consultants to manage their LANs.

Microsoft saw an opportunity to offers a simpler solution, and Windows NT Server ate Novell’s lunch. Sure, Windows NT Server was less efficient and less stable than NetWare, but small businesses could manage Windows NT themselves (and that was huge) and could write their own server-side applications (which was also huge).

Write a Windows application or develop an NLM? Work with a NetWare reseller or buy Windows off the shelf? Use Netware’s IPX/SPX or use a network that spoke TCP/IP? Bye-bye, NetWare.

Since its long-ago NetWare-centric glory days, Novell has become a hodgepodge of technologies. It bought Unix Systems Laboratories and sold part of it to SCO. It developed GroupWise, an email platform that always seemed to have great promise, but which never could get a foothold and which was pummeled by Microsoft’s Exchange and IBM’s Lotus Notes. Novell also created Novell Directory Services, but that was taken down by Microsoft’s Active Directory. The company bought WordPerfect and created an office suite, but nobody even noticed.

Where Novell has excelled lately is with Linux, thanks to its purchase of SuSE in 2003. But jumping into Linux also put Novell squarely in Microsoft’s crosshairs yet again, as during that time Linux was beginning to make serious inroads against Windows Server, particularly for Web servers. The enterprise-class SuSE Linux was a much bigger threat to Windows Server than Red Hat or other Linux distros.

Now we learn that Novell is being purchased by Attachmate, best known for its mainframe terminal emulators and host integration systems. Okay, I’ll admit – I didn’t see that coming. Last week, if you’d asked me to name 25 potential acquirers of Novell, Attachmate wouldn’t be on that list. Heck, if I’d written a list of 250 likely buyers, Attachmate wouldn’t have made that list either.

Microsoft is simultaneously is buying intellectual property from Novell. The 8-K investment notification paperwork filed by Novell on Nov. 21 said,

Also on November 21, 2010, Novell entered into a Patent Purchase Agreement (the “Patent Purchase Agreement”) with CPTN Holdings LLC, a Delaware limited liability company and consortium of technology companies organized by Microsoft Corporation (“CPTN”). The Patent Purchase Agreement provides that, upon the terms and subject to the conditions set forth in the Patent Purchase Agreement, Novell will sell to CPTN all of Novell’s right, title and interest in 882 patents (the “Assigned Patents”) for $450 million in cash (the “Patent Sale”).

This raises many questions. It is unclear what those patents are – or what role, if any, Microsoft may have played in Attachmate’s decision to buy Novell, and if there are any side agreements between the two companies. (It’s unlikely that Microsoft would have been able to buy Novell itself, because this this would raise many, many anti-trust issues.)

It’s also unclear about what’s going to happen to Novell’s assets, other than those mysterious patents. Will Attachmate want them all? Will it sell some of Novell’s business lines to other companies (such as selling SuSE Linux to VMware, which appears to be a persistent rumor)?

Neal Sedaka wrote in 1962 that “breaking up is hard to do.” In this case, I suspect that Novell will be broken up into lots of little pieces. The big winner here is Microsoft, which will finally have seen one of its oldest enemies not merely defeated – but actually utterly destroyed.

Like many of my friends and colleagues, I’ve got two smartphones. One of them is an Apple iPhone 4. Oooh. The other is an HTC EVO running Android. Aaah.

Both of those smartphones are great to use (though it’s sometimes disconcerting when switching between them). Each is stuffed full of different native functionality and third-party applications that add to my productivity and are also fun to use.

But, like many readers of my blog, I’m not merely a consumer of smartphone technology. My 9-to-5 responsibilities include software development, IT management and business strategy. The Android and iOS ecosystems represent significant opportunities and unique challenges in each of those areas.

That’s where our iPhone/iPad DevCon and AnDevCon come in. We’ve created those events to offer you – and your colleagues – the best independent education available about those platforms.

AnDevCon, the Android Developer Conference, is coming to San Francisco on March 7-9, 2011. Phone/iPad DevCon is a month later on the other side of the country. Please join us in Boston from April 4-6, 2011.

Whether you’re building applications, deploying iOS or Android devices or managing mobile systems, these conferences are for you.

The workshops, classes and speakers for AnDevCon are already posted – go check them out! We’re still finalizing the program for iPhone/iPad DevCon and will put the session descriptions online soon.

Hope to see you at one of those conferences in the spring – or maybe both. After all, how many smartphones are you carrying around?

I don’t know a single software developer who doesn’t process a commitment to quality – and who believes anything except that he or she designs, writes and publishes solid, secure applications filled with clean, efficient code.

I don’t know a single development team manager who won’t insist that his/her team writes great software – and who would be mightily offended if you suggest otherwise.

I don’t know a single IT professional who gets up in the morning and says, “I’m going to do a really lousy job today.”

Yet software has bugs. Platforms have vulnerabilities. Applications sometimes don’t meet requirements. Systems experience crashes, Blue Screens of Death, kernel panics. Hackers find a way to penetrate networks, servers, websites, applications and databases.

Clearly there’s a disconnect. Thinking about the great Watts Humphrey (see “‘Father of Software Quality’ Watts Humphrey dies at 83”) got me thinking about these issues. I hope this news got you thinking about quality, too.

The challenge isn’t that our teams suck. It’s not that we write crappy code. It’s not that our architects and designers don’t care about security and application performance; it’s not that our programmers are idiots; its not that our testers are asleep at the switch.

We don’t have bugs because we’re losers. It’s not because we don’t use the right agile methods, or because we don’t care, or because we don’t use the right software suites or “best of breed” solutions, or because we haven’t “built a culture of quality.”

There’s no silver bullet. The truth is that writing complex software is hard, and our modern platforms and protocols are very complex. No matter how hard we try, bugs, inefficiencies will always creep in – and in terms of vulnerabilities, there’s always something we haven’t thought of. So, for any non-trivial application, we’l always be fixing and patching.

Let’s say it again: There is no silver bullet.

What we need to remember, and what we need to communicate to our teams, is that we acknowledge that that quality is hard. So what? It’s our job. We must constantly find ways to do better, learn from our mistakes, stay responsive to our customers and their requirements, and keep doing the best job that we can.

It’s late afternoon on Thursday, Aug. 26, and today the Dow Jones Industrial Average closed below 10,000 again. Coincidentally, we’ve been sweltering here in the San Francisco Bay Area with a unusual heat wave (bring me lemonade, stat!), and I’ve been trying to help a young man find a software engineering job.

The young man – the boyfriend of a friend’s daughter – has an solid resume. Not bad, given that he’s only been out of college for a few years, with experience in software development, testing, quality assurance, second-level support and network operations. He’s versatile, too, skills in Java, C, C++, C#, HTML and Flash, and has been using both Visual Studio and Eclipse. Even more important he’s been programming Facebook Markup Language, and has worked with Google AdWords and Google Analytics.

How do you find a good, solid job with a background like that? He’s working all the social-networking angles, including Facebook and LinkedIn. Family friends (like me) are making introductions. He’s schmoozing every chance he gets.

It’s tough out there for people looking for employment, even if you’re a bring young software engineer in Silicon Valley. He’s thinking about doing some volunteer work to keep himself busy until the right job (or any job) in his field comes along.

My young friend isn’t the only one looking for work in the Valley. Another friend – a guy in his mid-50s – is also looking for work in technical marketing or product management. With a gold-plated resume, a winning personality and great references, he’s having trouble getting anyone’s attention.

What do you tell job-hunters in this economy, beyond advising them to meet people, meet people, meet people and meet more people?

Speed matters. With most agile development methodologies, the faster you can push new code out into the source-code management system, into builds and onto servers, the faster you can evaluate your progress and chart your next moves. From monthly builds came weekly builds, then daily (or nightly) builds. In some shops, those builds are used internally, with less-frequent deployments into the production environment. In other cases, the bits are actually pushed out to production servers daily.

Even the now-common daily/nightly build and deployment may not be fast enough to drive modern development, according to some proponents of ever-more-agile agile methodologies. That’s why thinkers like Kent Beck (pictured) are now advocating a move from Daily Deployment to Continuous Deployment.

Continuous Deployment is the topic of the first-ever SD Times Virtual Conference, which we’re holding on Wednesday, June 30, beginning at 1:00pm Eastern (10:00am Pacific). There’s no cost to attend this three-hour educational event, which I’ll be hosting.

Our three instructors are Kent Beck, founder and director of the Three Rivers Institute, and author of “Implementation Patterns,” “Extreme Programming Explained: Embrace Change,” and much more; Timothy Fitz, tech lead at IMVU and one of the creators of the Continuous Deployment movement; and Jez Humble, build-and-release manager at ThoughtWorks Studios, who is currently writing a book called, appropriately enough, “Continuous Deployment.”

Here’s what we’re going to cover in the virtual conference – you can stay for the whole thing, or choose the parts that seem more relevant to you:

• The potential benefits of Continuous Deployment to your organizations.
• The technology required to implement Continuous Deployment.
• How to apply Continuous Deployment to your company’s existing IT systems.
• How to apply Continuous Deployment to the software you’re creating, both Web and client-installed.
• The social challenges of applying Continuous Deployment in your organization.
• The risks of doing Continuous Deployment wrong – and how you can avoid mistakes.
• The impact of Continuous Deployment on various job functions: testers, marketers, managers, programmers and other stakeholders.
• The prerequisites to Continuous Deployment.
• Practical advice and best practices to take steps toward Continuous Deployment today.

You can learn more, see the agenda and timeline, and pre-register at http://bzmedia.com/agility/ — please join us!

It’s almost time to unveil the SD Times 100 – the top 100 companies, project and movements that are demonstrating innovation and leadership in the software development industry.

This year, the SD Times 100 will be “officially” published in the June 1, 2010, issue of SD Times. It’ll also appear on that date on sdtimes.com.

However, continuing a new tradition begun last year, we will tweet out the SD Times 100, category by category, on Monday, May 31, starting around 11:00am Eastern, 8:00am Pacific. We’ll begin with the “Agile & Collaboration” category, and will tweet another category every 30 minutes or so, continuing through all 12 categories until we reach the biggest one: Influencers.

See all the action by following us on Twitter: www.twitter.com/sdtimes.

What is the SD Times 100? As we wrote in the debut 2003 awards:

The editors of SD Times identified the industry’s top leaders, innovators and influencers, and broke them out into 10 separate industry segments. Some companies lead in one category, others in more than one. In each category, one company has been spotlighted as a star deserving of special notice.

When choosing the SD Times 100, we carefully considered each company’s offerings and reputation. We also listened for the “buzz”—how much attention and conversation we’ve heard around the company and its products and technologies—as a sign of leadership within the industry.

The SD Times 100 looked for companies that have determined a direction that developers followed. Did the company set the industry agenda? Did its products and services advance the software development art? Were its competitors nervously tracking its moves? Were programmers anxiously awaiting its developments? Those qualities mark a leader.

Subjective? Of course. But leadership and innovation can’t be measured by stock valuations or analyst reports. The SD Times 100 represents what we believe to be the best of the best….

While you’re waiting for the 2010 SD Times 100 to tweet out next Monday, please feel free to peruse the debut 2003 awards and last year’s 2009 awards.

See you on Twitter!

Those of us in the technology world – call us nerds, geeks or software developers – expect a 1:1 ratio between personal email addresses and people.

I’m not talking about business or workgroup addresses. I mean your home, non-business address, which might come from your cable TV company, DSL or wireless provider, or from a free email service like Google’s Gmail, Microsoft’s Hotmail, Yahoo, India’s Rediffmail and so-on.

Many people (like myself) have dozens of personal email addresses. Some current, some legacy, some active, some dormant, some used for friends and family, some used for buying things online, some used for subscribing to newsgroups, some totally forgotten. So, yes, it’s not really a 1:1 ratio; it’s 1:many, but here “many” means many addresses, not many people.

For techies, you can safely assume that a personal email address is like a personal cellular phone number. All my personal email addresses are for me. My wife has her own personal email addresses. There are no shared addresses.

I would venture that most of you receiving this blog also view email addresses and email messages as personal, not shared. Yet I’m continually astonished at how many families share one personal email address, just like they share one home phone number. Jack and Jill Smith might use the shared address email hidden; JavaScript is required or email hidden; JavaScript is required or email hidden; JavaScript is required, and that’s the sole non-business address they have.

This seems to be a generational divide. My parents share one email address. I see a lot of shared personal email addresses in the directories of several non-profit organizations and even in my son’s school parents directory. The divide seems to be somewhere north of 50 years old:

• Over 70 years old, the spouses most likely share one address. It’s probably from AOL or their Internet service provider.

• Under 50 years old, it’s almost certainly not a shared address, and it’s probably not from AOL or the ISP. But I know many exceptions.

• Between 50 and 70 years old, it could go either way, but it’s more likely to be personal than shared, and is more likely to be from the ISP.

Why is this relevant? Many of us assume that a non-business address is a one-person email address, and therefore is suitable for receiving confidential information. That can be a false assumption — even with couples under 50 years old.

Also, what happens if both spouses try to create accounts on a website that uses an email address as the registration key? Registration systems increasingly rely upon the email address as an unique identifier associated with one, and only one, person.