d.code

Geeks in Pain - Overworked and Underpaid

Like many of my .NET-coding brothers and sisters, I have an affinity for all thinks geeky, and for me personally this means a somewhat unhealthy interest in visual effects.  I tinker with motion graphics in After Effects [Note: paid-for Academic Versions, I do NOT condone pirating software], play with modeling in Maya, and sketch out concept art, admittedly not very good, in Photoshop and Illustrator on my tablet.

It's a hobby, of sorts.  And I try to keep up with goings-on in that industry.  So I was a bit surprised to read the following article on Variety's site:

Blockbusters take toll on f/x shops.  It's not too long; please read it.

There are so many parallels here to the IT consulting profession, and even to coding on a staff for a large company.  Next, read this intelligent commentary from fxguide:

Killer Schedules: Behind That Variety Story

Just a few comments:  First, the vfx shops should have never, ever charged by the shot.  They should just quote a rate per hour.  I know it would be tough to change their business model now, at this point in the game, especially with all the perceived competition.  But they should.

In our business, you just have to achieve a certain skill level that enables you to turn down unprofitable jobs, because you have confidence that you can find a job that pays decently.  Don't know if our fellow geeks in the vfx industry have that option.

The next time you're on a deathmarch project, repeat to yourself:  If you're not getting a fat salary that justifies it, you should be charging by the hour.

Silverlight: The Good. The Bad. The Security?

Like a bolt from the blue, Microsoft drops Silverlight on an unsuspecting developer community!  Well, sort of.  We all have seen WPF/E and kicked the tires of XAML for some time now, but it wasn't until MIX07 that some fascinating details were brought to the fore, as it were, and now the pony is on display.  And there's lots of excitement and buzz around this oddly-named technology; the bandwagon seems about to bust from all the jumpers-on.

(On a side note, it has even had the remarkable effect of lurching me out of blog hibernation.)

But wait.  Before I start singing "Oh Hail All Ye Redmond" and get carried away on the Vector Train, I feel compelled to offer my own perspective on how this changes the life and times of a corporate software developer.  This view certainly isn't everyone's, but here's the dealio as I see it.

I really hate browser apps.  They suck on many levels.  Markup-script-css-based applications are a pain in the neck.  You've got state issues, browser compatibility issues, and maintenance issues.  I understand their use when creating public-facing web sites, of course, and the ease of deployment.  That deployment bennie is the drug that corporate management got hooked on. (And not just where I work.  This is a worldwide epidemic.)  Browser-based apps relieved some of the pain of deploying internal applications to the desktop.  But one of the problems I've been trying to deal with for the past ten years is that corporate management won't give them up, even though dll hell is a thing of the past, and we now have a good, stable deployment system with ClickOnce.  No, they want their browser applications, even for stuff completely inside the firewall.  <sigh/>  So for long years we developers have had to struggle with crappy underbaked technologies (the aforementioned markup-script-css), attempting to create rich interactive applications.  [Note: Let me say that ASP.NET was a huge leap forward, but even with code-behind and all the goodness of the Framework, RIAs were still too hard to create and maintain.]

With Silverlight, we can actually create that RIA in the browser. Management can continue with their deluded view that browser apps are better, and it won't be as painful for developers.  so now I have to re-phrase my stance that browser apps suck, and say that markup-script-based browser apps suck.

Silverlight applications will be a great fit for internal, intranet-type apps, where Active Directory and other Windows-centric security is firmly entrenched.  As long as everything is entirely on the inside of the firewall, party on.

Silverlight applications will be a great fit for those few-but-high-profile applications where all users are anonymous and all users are provided the same services and information.  If the transit authority wants to show bus routes, or the boys in London want to give you a vector-animated rendering of The Tube, that'd be easy peasy.

However, what I haven't seen, and what I'd like to see, is a best practices article from Microsoft on how to secure Silverlight applications for sensitive data in the wild.

Consider.  For a markup-script-based browser app, we use Https to secure the communication between the client browser and the webserver.  The webserver needs information from internal services, such as GetCustomerInvoice(CustomerNumber, InvoiceNumber).  From the webserver in the DMZ to the internal service inside the firewall, there are a number of things we can do to harden that channel of communication.  We all know this, and it's mission-critical that the right invoices get displayed to the right customers.

With Silverlight, the developer is extending that webserver-to-service call out into the wooly wilderness of the Internet.  The call is being made from the browser, then proxied by the webserver, relayed inside the firewall to your corporate service (which should be a Wcf call, but could also be a Sql database).  Should I be nervous about putting that code --- previously only available to those who can hack my webserver --- right out there on the client?  How important do user SessionTokens become now, eh? 

I'm excited about Silverlight.  Coolness factor is off the hook. And honestly, I can't wait until I can say that the markup-script is dead.  (I'll settle for mostly dead, even though mostly dead means a little alive.)

And I'm confident that these security issues will be worked out to most people's satisfaction.  Looking forward that that whitepaper, Redmond.

Up the GZipStream Without A Paddle

Let me say that, despite the snarky title of this post, my experience with GZipStream has been very positive.  I had to find some obscure code to solve one of the issues, and thought I'd share that resolution and my overall findings here.

So I'm working on a web application where there is a huge amount of user-specific data; very, very, very granular detail about each user.  Anywhere from 60kb - 250kb worth of text per user.  Thousands of rows returned from the database.  Too much to store in session.  So - mostly as an exercise - I decided to (a) read the data in on login, (b) use GZipStream to compress this data, (c) store it in Sql, (d) retrieve it when needed for each user (based on a custom Authentication Ticket, and SessionID, etc.), and (e) decompress it for actual usage.  That way, it's not carried in session, and although RAM usage on the box is a bit higher than I'd really like, at least it's stable.

When you use GZipStream to compress data, all is good.  However, when you go to decompress your data, you have to know HOW BIG the original uncompressed data was.  I suppose I could have a column in Sql, "Uncompressed_Size" or something.  But how lame is that?  Then I discovered that when the data is compressed by GZipStream, the info I needed is written into the footer of the compressed datablob.  It can be extracted and used.  Very cool.

Also, I ended up rolling my own serializer-type code that used that old standby, delimited strings and (my friend and yours) the "Split" command.  Yes, I know, serializing objects is way cool, but in this case there's no reason to Serialize other than convenience.  I'm not communicating with disparate systems. And I know that if the object ever changes, I will have to handle that in a couple of places in the code.  Still, the difference is enough to warrant that. Here's the numbers:

Uncompressed bytes when Serialized: 94,688.
Compressed bytes when Serialized: 54,258.
    
Uncompressed bytes when character-delimited: 72,920.
Compressed bytes when character-delimited: 13,871.
   
So there it is; what can I say, other than "~" is your friend and delimiter. 

Compression code:

This code would be in the object, which I'm calling OriginalObjectType, that holds the data.  It returns a byte array that can be persisted to Sql.

Captain Black Turtleneck Rides Again

I really have to hand it to the boys from Redmond. At long last, they've come through for us corporate developers.  And not in small measure, either.

When Visual Studio .NET launched, back in the early days of this century, the designer that shipped was pretty woeful.  You know it.  They knew it.  I mean, Allaire's HomeSite, which had been out for a few years by then, handled design better.  Sure, sure, you could code purely in HTML, and that's what you really had to do with VS 2002/2003.  Or you could use DreamWeaver, which is what many did.  Of course, nothing beats Visual Studio when it comes to back-end coding, and as a corporate developer that's Job #1, but it would have been nice to easily do design work and set up web pages without having to sketch out a design on paper (how yesteryear) and then code to that in HTML.

With Visual Studio 2005, things have gotten much better.  You can drag tables around and resize stuff, and it's all getting better all the time.  Hurrah. 

. . . but then . . .

I downloaded Microsoft Interactive Designer, and whoa!  WPF is really the nuclear option of design.  XAML rocks, in an arbitrary-cool sort of way.  Microsoft has created some seriously freaked-out juicy goodness for the black turtleneck crowd.  I fully anticipate seeing hordes of atrocious acid-induced designs with this stuff.  RichTextBoxes all askew.  Kaleidoscopic gradients, fading in and out as you type.  There's all kinds of gnarly abuses that this will unleash upon the world. (Check out my own humble picture of RichTextBox gone bad.)  I think it's great.

Of course, it will be some time before enough users have upgraded to Vista, and have a P4 with 1Gb+ RAM and a blazing fragmaster video card.  Which is what seems to be the real-world requirement for running WPF apps. 

Well, as I go back to my seemingly mundane OO-laced coding lifestyle, with business objects and data tiers, Web Services and remoting, I now get to look forward to tinkering with some nifty designer toys.  At last.  Thanks, guys.

FTPOnline Needs A Shrink

So in typical magazine prerelease style, ftponline.com posted an article a while back dated July 14, 2005:  The Incredible Shrinking Programmer.

I've had some time to think about the contents of this article, and while most of it is platitudes and blather, there is a microspeck of . . . something in there, and that microspeck was probably intended to start a flame session, since it was a guest op, after all.  In fact, you could probably start ten different discussions on this, but to match the style of the article, I'll respond with my own de-focused vagaries.  'Cause I'm in that mood.

[Here's the link to the article.  You have to register on the ftponline.com site to see the last couple of paragraphs.  (You just know their database is flooded with junk data.  But whatever, the advertiser's are buyin' it, so load the junk up.  Like we all don't know about spamgourmet.com.)]

Okay, now for my own platitudes and blather.  The article mentioned above boils down, at least to me, to the following:  (a) Outsoucing is goin' on + (b) automated code generation diminishes programmer value = (c) programmers must adapt or face unemployment.  <sigh>

(a)  Yes, outsourcing is going on. For some businesses it is working okay, and some businesses are finding out that (1) outsourcing projects requires substantial internal overhead, management, and communication, (2) outsourcing companies are starting to require serious $$$ contracts, or else you get the rookie programmers, and (3) for outsourcing to work at all, the business-side of the house has to have detailed documented knowledge of exactly what they want, and (3a) be willing to wait for it.  Finally, (4) the businesses have to have someone knowledgeable to review the code submitted, because there are QA issues.

Most businesses vastly underestimate #1, and absorb soft costs.  Many businesses are starting to run into #2; even the mid-size outsourcing companies really don't want to take a contract for less than $1 million, and if they do, you're getting the rookies.  Number 3 and 3a is the real issue for most American businesses.  They can't articulate the end product six months out.  Business management has become accustomed to quick turnaround on last-minute changes that drastically affect project scope.  It's like a drug.  And in my humble opinion, I don't see them giving that away without serious consideration.

Here's a tip:  Most businesses that are successful at outsourcing software development set up their own offices in India/Russia/wherever.  And they only send projects over there that have been fully documented over here.

One last point on outsourcing is this:  IT Management is a hard job to get right. Managing business requests, the vortex of shifting priorities, measuring cost-benefits, justifying projects, dealing with reams of regulations and paperwork, not to mention managing groups of self-centered passive-aggressive people with hyperinflated egos (hey! I know those people!) . . . that stuff is dang hard to do.  Not every business is good at it.  If they all were, there wouldn't be statistics like: 'Over 35% of all 'large' IT projects fail.'  Now add to the difficulty remotely managing a large project....  That's why a significant percentage (I WISH I could get this number) of outsourced projects fail.  They might not fail in the sense that massive systems explode and go offline.  But there are cost overruns.  Missed deadlines, and more missed deadlines.  Then the CIO has a quite conversation with the CEO and CFO about modding the numbers to make it look not so bad, and then taking those lessons learned and making the next outsourcing project a "prototype." 

I know, I know, tens of thousands of jobs have gone overseas, and good software developers have been affected.  I'm not saying that outsourcing is not a real concern.  I'm just holding on to my belief that if you're very good at what you do, you will be able to find work.  Hopefully in a decent environment.

(b) Going to save this for a future post.  It's a good one.  He's not entirely wrong.  Just mostly wrong.

(c) I've been hearing this for years --- it's so much a part of this occupation that I don't even think about it anymore.  When employers pay for my services, they pay for my experience and also my ability to quickly assimilate whatever I need to know.

Okay, so that's the exhalation for today. Comment and tell me how you feel about the "shrinking programmer."

Required reading on multithreading.

Vance Morrison, who is the compiler architect for the .NET runtime, wrote a great article on multithreading for the August issues of MSDN Magazine.  You might read MSDN Mag regularly anyway, as you should, but this article is worth calling out.

I've worked on applications that sparingly used multithreading (mostly to kick off background threads for long-running procedures, and (of course) for UI stuff), but have not had the opportunity to work on enterprise-level multithreaded apps before.  Like most developers, I've tinkered with the samples and worked out the possibilities.  But working in the environment that I do, most of our stuff is single-threaded.

However, I had aleady identified multithreading as something to concentrate on in my next phase of personal development.  And then I ran across this article.

If you're interested, this article will get you on your way to the next level of code mastery.  I consider it required reading.

Commenting on Language Wars....

<sigh>

Patrick Meader, editor in chief of Visual Studio Magazine (and WSSM) posted the article: Is C# the Only Language the Matters?

In it he makes a few good points, and the comments posted to that article on the page say some of the rest.  Just wanted to clarify a couple of items:

(a) The article mentions that C# is gaining generics when Whidbey ships.  Yes, and so is VB.  Generics is a Framework-wide upgrade, not a language-specific upgrade.  Visual Basic programmers will be able to use generics, thank goodness.

(b) The article mentions that with Whidbey, “you can see some separation in the languages.”  This is true.  C# is progressing, under the strong guidance of Anders Hjelsberg.  VB, on the other hand, is introducing default instances. I'm inclined to think that default instances are evil in and of themselves, mostly because they promote bad programming practices.  Read more about default instances here, and there's some good points here on the Microsoft feedback page.

Anyway, VB was my first language, and like my first car it will always have a special place in my heart.  However, with the Whidbey implementation of VB, I am investing the time to learn C#.  The shop where I work still uses VB, of course. But Microsoft's decisions have convinced me that you need strong C# skills.

A blog gypsy pauses during the journey.

This is, like, my fifth blog site.  Thanks, Dave, for setting me up.  Like many, I had some less-than-optimal experiences with DotNetJunkies.  So I wandered, like a traveler who wasn't really lost, per se, just wandering for a while, not accomplishing much, waiting for a comfortable inn to appear on the horizon.  So DevAuthority is a comfortable inn on the roadway; don't know if it feels like home, but it will do for the time being. 

So thanks again, Dave.  Hope things work out.