Saving Microsoft

The last few years have been trying times for Microsoft.  Late to jump on the web bandwagon, they've never owned that platform the way they owned the desktop.  Internet Explorer remains a decidedly un-sexy choice for web browsing, and Microsoft might never recover from the black eye that was Vista.  Office now faces some really credible online competition, and Bing is still light years behind Google in the search engine war.

But the most unkindest cut of all has to be watching Apple ascend to become the world's most valuable company.  I mean, it wasn't enough to watch the Mac chip away at Windows (many Windows developers, in fact, claim that Macbooks are the best portable Windows development boxes).  The iPod never even flinched when the Zune came along, and the iPhone, of course, completely decimated Windows Mobile, which was already under heavy pressure from Palm.  The coup de grâce might just be the iPad, which now has some declaring the death of the traditional PC.  While it remains to be seen if (or when) PC's are really dead, there's no denying that there's already been a noticeable impact on PC sales, and it's very possible that this was a factor in HP's decision to get out of the PC business this week.

Will the last one to leave Redmond...

So is that really the end for Microsoft?

Not necessarily.  I don't think we're ever going to see the heady days of near-monopoly that Microsoft enjoyed in the early 90's, but Microsoft is still huge, they make a lot of money, and you can still find their software on most business computers.  The Xbox is doing well, Bing refuses to give up, and the newly-reborn Windows Phone 7 seems to be winning fans every day.  Microsoft's Skype acquisition could give WP7 another shot in the arm.

But there's no mistaking the fact that "business as usual" isn't getting the job done for Microsoft.  The Windows folks are now hard at work on Windows 8, but early discussions about HTML5 support in Windows 8 has caused quite a lot  of anxiety among Silverlight developers, who fear they're now stuck on a legacy platform.

Mark my words:  If Microsoft's Windows 8 strategy causes more developers to flee to the iOS or Android platforms, you can go ahead and cue the fat lady.  You see, since the very earliest days of Windows, it's been the growth and productivity of Microsoft's development platform that's attracted developers, who built the applications, which attracted the users.  Ballmer had it right way back in 2000 - they're in big trouble without "developers, developers, developers."

What developers want

Despite the momentum of iOS and Android, neither of these platforms can touch Visual Studio for developer productivity.  All things being equal, this should make Visual Studio the automatic winner, and when Windows ruled the desktop, it was.  Now that Windows is no longer the gorilla it once was, though, VS can't win on productivity because you can't use Visual Studio to produce apps that run on all the devices you want to support.

That's the "aha" moment.

Forget Windows vs. WPF vs. Silverlight.  Visual Studio needs to support development of applications that run on all those platforms, plus iOS, plus Android.  There's no reason Microsoft can't deliver this functionality in Visual Studio, and nothing short of this will be remotely close to good enough.

Don't take my word for it

About a week ago, Charlie Kindel announced that he was leaving Microsoft to go do his own thing.  Charlie was the GM of the Windows Phone Developer Ecosystem, and before that, he led the Windows Home Server team.  Although this background admittedly makes Charlie a little biased, in an interview on Geekwire, Todd Bishop asked Charlie an interesting question about mobile platform development:

If you build an app for your new company, which mobile platform will you target first?

Kindel: Hypothetically, if my new company were to build mobile apps, we’d target WP7 first. You know the old saying “Code Talks”:  I know I can build a beautiful and functional WP7 app in a fraction of the time it would take to build an iOS or Android app. Startups are about executing quickly. But I’m sure we’d quickly take what we learned there and apply it on all the popular devices.

Right there, you have the value proposition for a cross-platform development tool, because although I think Charlie is right about the productivity gains on Visual Studio, I'm skeptical that most startups are really going to target WP7 ahead of iOS or Android.  In fact, we're now on the  verge of HTML5 being that go-to platform, and right now, HTML5 development tools are so immature that Visual Studio just doesn't have a productivity edge vs. anything else.

This is a big image problem for Microsoft now, and as more business apps need to target multiple platforms, it's going to start costing Microsoft more market share and more profits from its last real stronghold: businesses.

So, what do I want to see?

Ok, here's the todo list, Microsoft:

  • It's beyond ridiculous that WPF and Silverlight continue to be separate.  I understand that you can do more stuff on the desktop than you can do when you're deployed as an internet app.  Fine.  You don't need a whole other client framework for that.  Stop it. Now.  Thank you.
  • I want to use the VS2010 layout tools I'd use for Silverlight development to build an HTML5 application.
  • I want to have all the declarative validation I create using data annotations create Javascript for those HTML5 applications.  We've seen hints of this in MVC already.
  • While we're at it, I want to deploy the same application to the Windows desktop (or tablet) or a Silverlight client, or an HTML 5 client, or even a native iOS or Android client.  All of these clients use declarative, hierarchical UI layout frameworks, and all of them can support some form of .Net via mono.
  • Xbox, too -- HTML5 would be fine, but I want to run the same apps there, too.
  • If you can't (or won't) make Silverlight cross-platform on the client, then can it and double down on HTML5.
  • End the fractured development tool practices that have plagued Microsoft.  Silverlight vs. WPF is the classic example, but there have been countless examples of competing data access technologies and other frameworks, too.  It feels confused and disjointed, and it's not helping.

With these things in place, Microsoft would have a real shot at being the premier development platform for business applications for another generation.  I know that the position in the past has been to tie Microsoft development to Microsoft deployment platforms, but that fight is lost, and it's time to garrison the last thing that Microsoft still does better than anyone else on the planet.

With developers in-hand, there's no reason Microsoft can't fight to take back OS platforms on phones, tablets, and so on, but if they lose the battle for developers, the flow of apps will dry up, and there will literally be no way for stop the hemorrhaging.

 

Enhanced by Zemanta

Dangerous Generalizations

I read an article a couple weeks ago on ReadWriteWeb pondering, Are Indian Developers More Skilled Than Americans?, and I just couldn't help cringing the entire time I was reading the article.

This article was ridiculous on so many levels it's hard to count, but the two biggest problems I saw were (1) lumping all "American" and all "Indian" developers together and (2) assuming that "better at C" or "better at SQL" means squat when it comes to writing applications that meet the needs of users.

If you're in a position where an article like this might potentially influence hiring or management decisions, please be sure to apply your own "BS" meter to these ideas.   While you're at it, be sure to question whether someone listing a skill on a resume really means anything about what that person knows, and whether it's more important to know the latest framework or to have the grey matter to know if that framework makes sense for your business.  Oh, and by the way -- if someone lists every new technology you've ever heard of on their resume, you'd be wise to question how deeply he knows any of them.

Just sayin'.

Enhanced by Zemanta

Did you test that SQL?

Although IT is a relatively young field relative to accounting or finance, I think a pretty fair number of people have picked up on some of the "big picture" ideas that drive modern development practices.  Whether you're working with a waterfall process or a more agile process, for instance, most people understand that you just don't make code changes in live production environments.  We put testing environments in place, devote time from QA staff, and take care to plan installations for low-volume, low-impact times.

Yet how many of those same people are more than happy to let someone with a SQL window reach into their production database and fiddle with data to their heart's content?  Even though that's a big ol' loaded gun pointed straight at their foot, most people don't recognize it that way -- starting with the people with their fingers on the keyboard, and working all the way up to the corner office.

Really? A loaded gun?

How can a data change ever be anywhere near as dangerous as a code change?  Let's consider an easy example - you update a credit card code field to be "VS" instead of "VISA", and all your Visa orders fail.  "Nobody's going to make a mistake like that," you argue, and you'd probably be right.  But by the same logic, nobody's going to go into the code for a production server and write "if (cardtype = card.Visa) throw new Exception", either.  Real bugs are just a little bit trickier than that.

The data you're really going to change is much more likely to have lookup values, effective dates, disabled flags, and so on, but the end result of screwing this data up is exactly the same: your system becomes degraded in a big hurry.  And unlike changes to source code, you're very likely not to have a repository that'll show you the last umpty-seven changes with comments from the guy who made the changes.

Yet, because we're conditioned to think about code as the dangerous bits, and data as an innocent bystander, we tend to just gloss right over procedures that we wouldn't dream of bypassing for code changes.  It's a big mistake.

Types of data

To begin with, it turns out that all data isn't created equal.  SAP R/3 classifies three different types of data: configuration data, master data, and transactional data.  In this usage, configuration data is limited to customizations to R/3 itself -- changing labels, terms, and so on.  There's an excellent chance that your system doesn't have any data like this.  Master data is the scaffolding that makes our systems run.  It's the customer types table and the status codes table and the rate plans table.  If you don't have any values in those tables (or the right values), your system isn't going to do squat.  Transactional data is the meat in the sandwich -- it's the reason you've got a system in the first place, but it's also much less interesting and dangerous than master data.

It would appear, then, that master data is the place to focus with respect to controlling change, and that's true to a large degree.  Your organization would be doing far better than average just by identifying its master data and putting procedures in place to manage changes to those tables, but does than mean that transactional data is completely inert?

Breakin' the law

Not so fast, cowboy.  Although the amount of damage you can do by messing with transactional data is small compared to master data, it's important to recognize that twiddling with transactional data with a SQL prompt is also an unnatural act.  For many lookup fields and references, your database should have foreign key constraints that prevent really bad mistakes.  The insidious bugs in this case come from the fact that you're bypassing business rules that exist in your online system.

If an order is intended to move from status 1 to statuses 2, 3, 4 and 5, for instance, you've probably got some state-machine logic somewhere that defines which transitions are legal, and more importantly, what stuff happens during those transitions (updating order line-items, refreshing inventory numbers, etc.).  If you update a transaction to a different status without regard for these rules, you can introduce all sorts of "interesting" downstream behaviors.

In fairness, I hope you wouldn't be considering SQL updates if your system was already operating exactly the way it should, so you probably have a pretty good reason for feeling that you've got to make changes to put the system back on the rails.  Fair enough.  Just be hyper-aware that you're taking chances with this data, and if there's a choice that gets you moving again with less manual intervention, it's probably the right choice.

SQL = WMD

Do you know what happens if you highlight the UPDATE part of an update query, leaving off the "WHERE" statement, and then run it?  'Nuff said, I hope.  You have the capacity to do a staggering amount of damage in a very short amount of time.

A better approach

If any of this stuff sounds like it applies to your organization, you might be wondering what you can do to bring a little law and order to your database management world.  Good news!  If you've made it this far, you've taken your first step: awareness.  Simply understanding that you need to exercise care when making ad-hoc data changes is a great place to start.

Next, try to understand which of your data is transactional and which is master data or configuration data.  This may be a large task, and you might find tables for which the answer isn't very clear, so start with some of your most visible or notable tables and work through the rest as you're able.

Once you've identified your master data and transactional data, fine-tune your processes for updating these tables.  You should consider making master data changes in a test environment and promoting these to production just as you'd handle a code change, but regardless, be sure to review how you're managing these changes, including tracking the content and context of any changes.

If your organization has any tips for managing master data, be sure to let me know!

 

Enhanced by Zemanta

FileHelpers flat-file library

A while back, I started doing some work on an application that does a lot of flat-file writing -- specifically, fixed-width (positional) ASCII text files.  Now, this isn't really exciting stuff, but like COBOL, it still makes a lot of businesses go round, but doing flat-file manipulation by hand seemed like about seven kinds of crazy, so I started looking for a better solution.

I found a project called FileHelpers.  It's a utility library to help .Net applications read and write structured flat files. Most of the library lives in a core assembly with a number of "engine" classes that are used to drive I/O along with attributes that are used to decorate record classes in your application.

Your code uses these attributes to define records:

namespace FileHelpers.Tests
{

	[FixedLengthRecord(FixedMode.ExactLength)]
	internal class FixedRec1
	{	
		[FieldFixedLength(10)]
		[FieldAlign(AlignMode.Left)]
		[FieldNullValue("n/a")]
		[FieldTrim(TrimMode.Both)]
		public String String10Field1;

		[FieldFixedLength(10)]
		[FieldConverter(ConverterKind.Date)]
		public DateTime DateField2;

		[FieldFixedLength(12)]
		[FieldConverter(typeof(MoneyFieldConverter))]
		public decimal MoneyField3;
	}

}

To read or write files, then, one of the FileHelper engines works with the records you've defined to manipulate, format, and validate data:

var recs = new List<FixedRec1>();
recs.Add(new FixedRec1 { String10Field1 = "abc", DateField2 = DateTime.Today, MoneyField3 = 123.45M });  // show truncation of field 1
recs.Add(new FixedRec1 { String10Field1 = "abcdefghijklmnopqrstuvwxyz", DateField2 = DateTime.Today, MoneyField3 = 123.45M });  // show null translation of field 1
recs.Add(new FixedRec1 { DateField2 = DateTime.Today, MoneyField3 = 123.45M });  // show illegal value for field3
recs.Add(new FixedRec1 { String10Field1 = "abc", DateField2 = DateTime.Today, MoneyField3 = -0.00001M });
// To Write Use: engine.WriteFile("FileOut.txt", recs.ToArray());

You can extend FileHelpers by constructing your own custom attributes, such as converters to handle formats not natively provided by FileHelpers, but it's pretty handy to have source code for FileHelpers on-hand for debugging, because if you do any amount of heavy lifting with it, you'll end up wanting to walk through the code to see what's going on.

FileHelpers is open source software released under the LGPL. Source is available on SourceForge, but note that the released versions of code currently go up only to the 2.x release, dated 2007. If you're going to work with this library, you really want to go after the development source code, which is currently in a pre-release status for version 3.0, and compile the library on your own. You can find a subversion connection string on this Sourceforge page.

Don’t be this guy

I found this sort of amusing, though I'll be the first to admit that the humor will be lost on some people.  This is a clip from a web site that's promoting an infrastructure component that's supposed to be enterprise-quality and highly available.  While I'm sure this is true, it's also true that having a web page that doesn't load won't inspire tons of confidence.  Oops.

(yes, I blurred the text a bit -- no need to pile on for what's certainly an isolated problem)

Stored Procedure References

Last week, I did a little work to track down unused stored procedures in a large-ish SQL Server database.  Searching for references in source code was interesting all by itself, but I also wanted to see which procs were referenced by other procedures.  This is what I came up with:

select
	o1.name 'referencing proc',
	o2.name 'referenced proc'
from
	sysdepends d,
	sys.objects o1,
	sys.objects o2
where
	d.id = o1.object_id
	and
	d.depid = o2.object_id
	and o2.type = 'P'

Quora Blocks Startup Search Engines

According to an article on ReadWriteWeb, Q&A site Quora is blocking search engines from indexing its site -- all, that is, except for Google, Bing, and a couple other big players.  If this is true, this is a really chilling development for the competitive landscape of the Internet.

Image representing ReadWriteWeb as depicted in...
Image via CrunchBase

Google is plenty big enough all by itself -- just look at how difficult it's been for Bing to claw out any sort of market share at all.  I'd really like to think that the market is still open to someone who wants to build a better mousetrap, but this sort of behavior is going to make it just about impossible for a new player to break into search.

So take a look around -- this may be as good as search gets.

Enhanced by Zemanta

How *not* to help your users

I got an email this afternoon from "VMWare Communities."  You've seen emails like this, I'm sure -- here's your status, and some stuff you might be interested in, and so on.  Emails like this are generally intended to strengthen a connect with customers, which is great -- normally.

In this case, though, there was a section of the email entitled "Your Content":

Activity around content you've created or contributed to


When I saw this, I was pretty excited, because I'd forgotten (for the time being) about both of these issues.  I'd posted questions in VMWare's forums for a couple of issues, and I hadn't recalled seeing solutions for either of them.   According to the newsletter, though, there were updates available on both questions.  Happy day!

Until I went and read the forum topics.

It turns out that VMWare's little newsletter-writer counting tool was counting *all* views and *all* replies, so in both cases, it turns out that my post was the last one in the topic.  Worse, yet, my posts were six and nine months old, respectively (no wonder I'd forgotten about them).  So instead of reaching out and building ties with me, in this case, VMWare merely succeeded in reminding me that their open issues aren't being fixed, and that their support forums are effectively dead.

"You break up...call back in six months."