<CharlieDigital/> Programming, Politics, and uhh…pineapples

31Jul/08Off

“Stupid Should Hurt”

Posted by Charles Chen

I caught this phrase scrawled on Woody Paige's blackboard last night on Around the Horn (one of the few television shows I watch somewhat regularly).


I love it.


Glenn Campbell on "stupidity":



During our childhood, we are given a certain amount of protection from reality. Our parents dole out rewards and punishments that are often detached from the conditions we must eventually face. Some parents, for example, may reward their children no matter what they do. This sets the stage for stupidity in adulthood, as the subject expects the outside world to hand him the same unconditional reward.


The habits of stupidity can be terribly difficult to change, especially in others. This is why we label some people "stupid" as an overall systemic condition. They are never going to "get it" because they have made a fundamental philosophical decision not to. Their emotional needs are so great and cause them so much internal panic, that they can never accept reality the way it is.


The worst thing you can do for a stupid person is protect them from their mistakes. Maybe stupid should hurt. If it doesn't, then they're going to get even more stupid, and they will be totally unable to deal with life when the protection finally collapses.


When you have a boss, client, parent, spouse or adolescent child like this, that's when you find out what a tragic and terrible disease stupidity is. You clean up one stupid mess, but then there's another and another. There's never going to be an end to it until the stupid person touches reality himself is able to directly experience the results of his actions as they occur.


Smart people, by definition, learn quickly from their mistakes, but stupid people don't. They may have to hit their head against a wall many times before they realize, "Hey, this isn't a good idea." Even then, it's only that particular wall they've learned about. If you put up another wall, they'll insist that it shouldn't be there and repeat their mistakes all over again.


This last paragraph is particularly relevant in software development.  I wouldn't call anyone stupid (you have to have above average intelligence to make it anywhere in software development; more like misguided or unmotivated), but many times, people just don't learn from pain and mistakes.  They settle into a methodology or a style and build up mental inertia.  No matter how many times you try to tell them that there is a better way, a more efficient way, a better tool, they refuse to adapt and expand their boundaries.


It's not that "smart developers" are infallible -- everyone makes goofy design decisions from time to time (especially when "The Big Picture" is not a known quantity), but that they can adapt quickly and learn from their mistakes.  They look for ways to ease the pains of the development process.  They are curious about how to make processes more efficient and less error prone.


Just a random Thursday lunchtime rant ;-)

18Jul/08Off

Lessons From The Mythical Man Month

Posted by Charles Chen

Fred Brooks' The Mythical Man Month is one of my favorite software engineering books.  I first read it in my senior software engineering class at Rutgers.  From time to time in my daily routine of software implementaion, I flash back to bits and pieces from the book and from the class.

One of the most relevant issues that Brooks' touches upon is the issue of communication and how it impacts productivity.  Of this, Brooks writes:

The added burden of communication is made up of two parts, training and intercommunication.  Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work.  This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.

Intercommunicaion is worse.  If each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2.  Three workers require three times as much pairwise intercommunication as two; four require six times as much as two.  If, moreoever, there need to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet.  The added effort of communicating may fully counteract the division of the original task...

This issue seems particularly relevant today as teams are more geographically dispersed than ever (whether due to working with offshore teams or with developers working across the country). As you increase the number of developers working on dependent and communicating components, you dramatically increase the development time.

One of the most common approaches to working around this is to partition the work such that each developer is responsible for minimal cross component communications (each developer implements a full stack).

The approach works because there is less turnaround and less miscommunication between developers.  It reduces dependencies between one component and another, allowing a develper to progress as fast as she can implement the requisite bits.  Need to store an additional field?  No problem.  Add a column, add it to your data model, and then render it in the UI.  No need to ping someone else or write a change request; just make it happen.

The downfall of this approach is that it leads to a lot of duplicate code for common logic; it tends to work well for a very small team with geographic proximity, but breaks down very quickly as the number of developers or geographic proximity increases.  A developer writing data access for one component may have her own practices while another will abide by a completely different set of practices.  In the long run, this leads to code that's hard to maintain as well as adding much more complexity to the product itself.

Not only that, any given developer may not be suited for developing a given part of an application stack.  A UI developer will be much more proficient at and capable of designing an attractive, easy to use UI than a backend service developer.  An application developer may be capable of writing a much more cohesive domain layer and business layer than a database developer.

Service contracts are an oft touted solution.  The promise is that by agreeing on a service contract, each side can develop independently of a concrete implementation of the other, so long as the contract is followed to a T.  However, at least in my experience, this is usually far from the truth, especially if you work in a team where the contract itself is rarely stable for more than a day or two.  UI tweaks or new features can cause dramatic changes in the service (for example, requiring more data or a change to the model) which comes at a cost of time spent on change requests and communicating those changes to the other side.

For the time being, I've come to conclude that full stack development (hmm...maybe with the exception of the UI layer) is the best approach, so long as it's supported by the necessary tools, templates, and frameworks; it's all about making it easy to make the guts work (and to do so in a consistent manner) so that the implementation differences where it matters is minimized (for example, data access). Enter code generation,  automation, and application frameworks to the rescue.  Tools like MyGeneration, Spring, Smart Client Software Factory, and Enterprise Library are really the answer but I've found it quite difficult to get team members to buy into embracing these tools (it's one thing to use a framework; it's another, entirely, to embrace a framework or tool).  When properly wielded with a cohesive software architecture, you can get the best of both worlds: a coherent codebase with common patterns across component stacks while allowing developers to work with less dependencies.

What do you think?  How do your teams handle working on multiple dependent components?

15Jul/08Off

Deleting ExtensionData From JavaScript

Posted by Charles Chen

WCF DataContracts include an ExtensionData property which is a bit troublesome if you are trying to send a modified object back up to the service if it has no properties in Javascript.


So I wrote a little piece of Javascript to clean it up:


function DeleteExtensionData(obj) {
var keys = Object.keys(obj);

keys.each(function(key) {
if(!Object.isFunction(obj[key])) {
if(obj[key] instanceof Object) {
DeleteExtensionData(obj[key]);
}

if(key == "ExtensionData") {
delete obj[key];
}
}
});
}


It will recusively delete all ExtensionData properties from the object.  You can call as soon as you get the result from a completed AJAX request or you can call before sending an object parameter to a service.


Note that it uses constructs from prototype.


If you want to get fancy, you can also write a custom serializer.

Filed under: WCF No Comments
6Jul/08Off

Is There Any Food Sriracha Sauce Can’t Fix?

Posted by Charles Chen

While reading his article from the NY Times on The 11 Best Foods You Aren't Eating, my curiosity regarding sardines was piqued.  Like most people (I'm just guessing here), sardines aren't on my shopping list...ever.  So I had to google and figure out how these things are supposed to be eaten and what not.


This lead me to this article over at Chowhound and this choice quote:



My favorite sardine to date is Angelo Parodi sardines. They are carried at most Italian markets or delis.


I ate them plain, so can't help you there ... only hint ... if you get a can of sardines you don't like ... sriracha sauce will fix it.


For those Anglo readers who stumble upon this article, sriracha sauce is kind of like the Asian version of ketchup; every fridge should have a bottle of that stuff sitting around.  It's the perfect combination of spicy, savory, and tangy and goes with pretty much anything (okay, dessert dishes? not so much).


Seriously: is there any food that a little sriracha sauce can't fix?

3Jul/08Off

More Lotus Notes Suckage

Posted by Charles Chen

A colleague emailed me today regarding some information I had sent him previously.  Apparently, Lotus deleted all of his data which wasn't archived.  Why?  Who knows.

Anyways, I suggested that he simply ignore the company email system and use a GMail account.  To this, he replied:

If I could I would NEVER use Lotus email. WHAT A nightmare!!!

Emphasis his.  So please, if you're an IT administrator or a CTO, don't punish your minions by subjecting them to Lotus Notes (unless, you know, you're into that sort of thing).

Filed under: Lotus Notes, Rants 1 Comment
1Jul/08Off

The Impending Death Of Microsoft Office

Posted by Charles Chen

Okay, maybe "death" is a bit severe.  But certainly, I think in the next few years (if not months), Office will start to lose marketshare...significantly.


Now don't get me wrong; I love Office (okay, not really, but I work with it on a daily basis and the whole product strategy for my group revolves around the Office client and server suite), but there are some severe usability issues which have, amazingly, to this day, been pretty much unresolved.


The crux of the shortcomings of Office (aside from interoperability pre-12) is really document sharing.


Today, in the Office world, if you want to share documents (either with yourself (i.e. work on a different machine) or others), you really only have a few options:



  1. You can access your desktop remotely using a remote desktop client.  This sucks for a variety of reasons including responsiveness and the require setup to enable a remote access scenario.  It may not even be possible due to corporate firewalls.
  2. Email the document to yourself and/or collaborators.  This is what most people do today, I would gather.  It's one of the most annoying things that I deal with because I end up with a folder with a bunch of documents title "Spec rev.1", "Spec rev.2" and so on.  Not to mention what the clusterfuck that happens if I modify the document and rename it with "rev.X" and another collaborator does the same.  It sucks...but even I've been known to do this.
  3. Copy the document to a physical medium and pass it around.  This includes CDs, USB drives, external drives, etc.  I do this quite often when I travel and I know I will need to prepare a document.  But it sucks.
  4. Use a corporate SharePoint site to share your document.  This is a great solution...if your company has a SharePoint site.  What if you're not a full Microsoft shop?  What if you work for a small company?  It also means you'll probably need VPN access, which is generally annoying.  For the record, I've been using Office personally and professionally for more than 10 years now and I've never shared a document using this method.
  5. Use Office Live!  This is a relatively new offering from Microsoft who finally realized "Hey, maybe the rest of the non-corporate world would also like to share documents in a non-shitty way!" However, what sucks about this is that you still need to have the Office client...we'll touch on this point in a bit.
  6. Use some sort of remote file share (FTP location, network file share, etc.).  This has various perils as well in addition to the inconvenience of having to have a VPN connection.

None of these options are really appealing, but until recently, there really wasn't a choice.  Regardless of what desktop processor you use, you're pretty much constrained to the same set of options (you can replace SharePoint with whatever web platform your client integrates with).


This sucks, for the reasons listed above, but it also sucks because it means that you have to lug around your laptop everywhere you go to work on documents.  It's the reason why you see business people scrunched up in coach, contorting their bodies and praying that the person in front doesn't put their seat back so they can fold out their laptop.  The desktop document processor client makes us all slaves.


But the future is coming.  For personal use, I don't think I'll ever author another Word document in Office ever again.  Both Google Docs and Zoho offer what I need so far as basic document processing goes and I have the added convenience of being able to easily share documents with others.  There's also the absolute coolness of being able to edit the same document in a live session with your collaborators.  This alone is not enough to change how we work with documents.  The iPhone and the impending release of Android (along with the next generatin of smart phones) will leave the Office stack in the dust.

Connectivity is ever increasing. With cheap, unlimited data plans now and non-neutered mobile browsers, instead of doing the stupid shit listed above, you can just connect to Google Docs or Zoho and edit your documents directly. You can share your documents without having to have a SharePoint deployment (good for small business and non-Microsoft solutions deployments). You can have access to your documents from anywhere where you have a cell or WiFi connection (which for most business people, is everywhere).

Why bust out your laptop on a crowded plane (unless you have the luxury of sitting in business class) to review or make small edits to a document when you can do it on your wifi connected phone? Why lug your laptop around when 90% of the functionality that you need for day to day business can be accomplished on a phone? Android and the next generation of smartphones will cause a big shift in document processor usage in time, IMO. Microsoft has to start thinking heavily about a web based Office suite (or purchasing Zoho) or else they'll start losing ground in their bread and butter application suite.

For the time being, both Zoho and Google Docs are missing some core bits (mostly around security, but also integration of more complex "compound content"), but for a good percentage of document processing needs, Office has become irrelevant (this is not to say that it won't take a really, really, really long time before Office loses market share to any web based processor).

Filed under: Office 1 Comment