ryan norris managing software teams and delivering great results

19Feb/100

Looking at Google Buzz

I tried Google Buzz this morning. My general impression when it was first announced was like many others: I don't need another outlet for random thoughts.  I don't need yet another source for random socialization.  I use Twitter.  I use Facebook.

So when I posted an innocuous message questioning the value of the tool I had just used, I got an immediate response.  To me, this is the type of gratification that people get (or used to get) from setting their Facebook status.  Or Tweeting.  Social media, from the consumer's perspective - is virtual screaming.  Just without the caps lock key.  It's everyone's way of saying look over here, it's me, I like politics and I love books and I have a cold and does anyone want to grab a drink tonight? What Facebook realizes increasingly (and Twitter, always resistant to changing their innate simplicity, has gave a moment's thought to) is that eventually you have so many contacts, so many friends, so many followers, so many people who follow you that the signal to noise becomes unbearable without some sort of filter.  All of the conversations, statuses, likes, fandoms, retweets, hashtags, and groups eventually just become an incessant buzz, and we stop paying attention to a lot of it.

The immediate response was a result of having all of 14 people paying attention.  Compare that to the 150 people I'm connected to on Facebook.  Or the paltry 80 or so followers I have on Twitter.  My satisfaction with the experience with Google Buzz at that moment was purely a result of it's infancy. But the buzz grew immediately louder.  I then noticed that the buzz had gotten into my GMail inbox.  To a guy who likes the mantra of Inbox: 0, this was distressing.  Part of the deal with Twitter which elevates it appeal over Facebook is that it is a pretty passive social media.  Direct messages infect your inbox, but those are fairly rare.  Simple replies to your tweets or even mentions can just fade to noise.  But now that there was a level of replication between ubiquitous social exchange and my more formal communication in email - Buzz had taken the most invasive and distracting part about Facebook and actively decided to emulate it.

At least Google Wave, while useless for my everyday interactions (though potentially useful elsewhere) lived out on an island that I could blissfully ignore.

I think that Wave, Buzz, and GMail eventually need to work out whether or not they're the same thing or different things.  Facebook is looking to build a "GMail Killer," and so it seems there is some idea out there that people don't like email and would rather live in a world where the overwhelming noise of social media permeates everything.  It's clear that for Google, taking email and putting eyes on the inbox with greater frequency will lead to more exposure to advertisers and inherently, more ad revenue.  But Facebook has ALWAYS had this model and hasn't been able to consistently demonstrate that users will give advertisers the chance through all of the other noise.

It's tempting to say that people will ultimately reject this model and the invisible hand of the market will demonstrate that when the inbox becomes too busy, people will just tune it out.  Google has provided options for getting Buzz out of your inbox.  But given the potential upside, particularly in Google's business model, I'm also unconvinced they won't try to force this particular feature right down their user's throats.

22Jan/100

No, You Can’t Override JavaScriptObject.equals() in GWT. Not Yours.

Sigh. For reasons that may or may not be sensible, equals() and hashCode() are finalized in GWT's JavaScriptObject.

15Jan/100

Common Java Idiom, Lousy GWT Bug

I have to get around to shipping this one to the GWT committers, but this one bit me hard.

5Jan/101

Technology Grudges and the Cult of Building Your Own Software

It has come to pass that in my travels, I have been introduced to or worked with people with certain grudges in the technology realm.  Myself included, it is pretty simple to run into a problem in an experience that sours you on a particular tool.  Hell, my father-in-law held a pretty decent grudge against Honda automobiles until the early 90's.  The reason's for his slight towards the maker of the Accord was a bit different from the people I come across who hold technologies in low regard - the people who roll their eyes at Java, the religious fanatics who loathe all things Microsoft, the experienced programmers who will never touch Perl.  We tend to be shaped more by our poor experiences than our positive ones.  The technologist "grudge" is the burden some people carry with them for a lifetime after a poor experience, and while it's understandable and to an extend prudent to adopt a once bitten, twice shy perspective, it is more valuable to take that experience and either improve the subject technology (particularly in the instances of community software) or evaluate alternatives that exist.

But some of the weary techies I've worked with (particularly middle-management types, for some reason) go off the deep end.  I like to say that when you encounter a technical challenge - there's likely someone else who has also needed to solve a similar problem.  In the instances where that isn't the case - you're in a pretty good position to gain something from solving it yourself.  But truth be told, there are very few large problems out there that people aren't solving.  And yet IT organizations continue to re-invent the wheel - even when economics and time tell them that they should look for an off-the-shelf solution.  This only leaves one real driver for making the build decision when the buy decision is so apparent: politics.  And often it's the politics of the grudge.

I firmly believe that every shop I've walked into that has rolled their own MVC framework, or RIA framework, or rules framework contains an individual who truly believes that the cost of supporting, maintaining, and continuously developing that software is still less than the cost of taking a turnkey solution - either one that is commercial or open source.  I recently had a manager tell me that there was an increasing drive through the IT management structure that the enterprise should own the source and rights to all of the systems that it supports.  This was a crazy notion - are their boundaries to this doctrine?  Will we be writing our own application servers?  RDBMS?  Messaging systems?  Where does this cult draw the line?  And with a little more digging, and without much surprise - I found that this manager had spearheaded a campaign to adopt a particular Javascript framework for client development that ultimately failed and cost the company several millions of dollars.  His dogma seemed crazy, and it was. But it was completely motivated out of fear that technology selection, no matter where the accountability lay - was an avoidable cost of enterprise IT, even if it meant adopting the more extensive cost of building all solutions from the ground up whenever the need arose.

I guess the moral of the story is really that as an IT manager, it's important to recognize the power of the crowd (the community if you will) and the value it can add at virtually no cost to your organization.  That it's important to understand why a 3rd party tool has been selected.  That it's general limitations are known early on.  That your organization is prepared to adopt the tool as if it were it's very own.  This means hiring experts who have used those technologies.  And above and beyond anything else, that when you fail - the goal must be to marginalize the cost of that failure.  You can hedge your bets, you can reduce risk.  But when the dust settles and a selected technology has failed the organization - be sure to take a good hard look in the mirror and be open about where the selection process has failed.

Sometimes it is the captain, and not the ship.

13Dec/090

RPC Objects in GWT Now MUST be Serializable

Okay, so maybe it's always been this way and I've just not been paying attention - but it appears that GWT 2.0 now requires one to make RPC objects that will go across the wire explicitly implement java.io.Serializable.

A bland RPC implementation that was based on past work I've done was barfing all over me at GWT compile-time today:

Rebinding com.ryannorris.staffing.client.project.ProjectCreatorService

Invoking com.google.gwt.dev.javac.StandardGeneratorContext@9b32fe

Generating client proxy for remote service interface 'com.ryannorris.staffing.client.project.ProjectCreatorService'

[ERROR] com.ryannorris.staffing.client.Action<T> has no available instantiable subtypes. (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR]    subtype com.ryannorris.staffing.client.Action<T> is not instantiable

[ERROR]    subtype com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

[ERROR] com.ryannorris.staffing.client.project.ProjectCreatorAction is not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' or 'java.io.Serializable' nor does it have a custom field serializer (reached via com.ryannorris.staffing.client.Action<T>)

I can't say I ever had the pleasure of dealing with this bit of attention to detail from the GWT Compiler in the past.  And while I will readily admit I haven't read every change to the underlying architecture that comes with 2.0, this would seem to be a piece that might be worthy of some special mention.

It is, of course, nearly common sense to make sure that your RPC objects can go across the wire in the proper way, and thus simply respecting the semantics of java.io.Serializable the same way we would in EJB per se, is pretty reasonable.  Just a little more heads up would have been nice.

Update 1: There seems to be some mention of fixing compiler feedback around RPC serialization here.  But this defect doesn't suggest changes that might have actually altered behavior or requirements of the compiler since 1.7.

Tagged as: No Comments
27Nov/091

A Simple GWT Validation Framework Using Great Design Patterns and MVP

I've been writing a bit about Google Web Toolkit lately. It undeniably is disrupting traditional browser-based RIA development. But it does lack some features out of the box that most developers have grown accustomed to from frameworks like Flex and Ext. Field validation is one such feature. While the gwt-validation project exists to solve this very problem, an approach leveraging a good chunk of the existing GWT infrastructure can give you a robust, test-driven, and MVP-friendly approach for validation.

20Nov/091

Does GWT Harkon the End of Javascript?

Javascript isn't going away. But neither are 1's and 0's.  But one has to wonder what type of project or team that was looking to grow and build web-based, rich-client applications would actively choose to use Javascript on it's own now.

For my part, there's only so much patience I have taking on the burden of supporting multiple browsers and dealing with performance issues.  Particularly if I'm Agile, and I'm focusing on delivering so much value so quickly, it's very hard to explain to a client that the underlying technology creates significant overhead that adds drag to the project.  This is an even tougher sell - particularly when you're open with your client, when alternatives that meet the non-functional needs exist.

For your standard web applications that aren't as client-centric as today's RIA applications, it's certainly true that you are barking up the wrong tree with GWT.  Rails, Grails, and Zend can all give you the non-enterprise delivery tools that accelerate development from the server-side and leave the Javascript problem to be solved in a less holistic, more tactical way.

But it's hard to argue now that anything short of the compilation semantics of GWT is useful in the RIA realm (without the need for a intermediate runtime, of course.)  Javascript is too costly and too brittle in large-scale applications to be subject to human hands.  If you've hired a contractor to build you a web-based RIA and they're not using GWT - it's well worth your wallet to ask them why.

13Oct/090

Revenge of the Compiler – The Era of GWT and the Birth of Flash on the iPhone

For a while now, interpreted languages have reigned.  They were fast to develop in, cheap to build teams around, and were less strict about the rules of the road than many of their more strongly-typed brethren.  But as the modes of web application delivery have changed - indeed, as the modes of any sort of software delivery has changed - the era of the interpreter is likely in decline.  As platforms are stretched to their limits and developers look for new ways to deploy high-performing, scalable web and mobile applications - an old friend emerges from the fog of battle to demonstrate why it was such a valuable innovation 50 years ago.  Compiled software is back - this time to once again relegate a past generation of development platforms to the same museum as assembly.

14Aug/091

Integrating Your QA Staff with Engineering in SCRUM

As much as I love automated testing, I have come to live with the fact that teams migrating from waterfall approaches to development to SCRUM often try to maintain the team structures they are familiar with.  At times, this typically means an engineering staff that sucks at writing tests, and a QA staff that is still very much attuned to the finer grained edge and corner cases.  Each of these parts of your team adds value to a SCRUM project.  Integrating them to avoid bottlenecks, stay lean, and deliver with quality is a clever trick.

16Apr/090

An Omniscient Learning Approach to Mock-based TDD

I recently posted about why I think mocks are simply the easiest way to get the most bang for your buck in automated software testing.  But integrating it as part of a process is hard, and teaching it is even harder.  Young developers seem to have a hard time grasping the idea of testing isolated units of code.  I'll confess - for a long time, much of my unit testing involved setting up the appropriate test environments - Spring containers for persistence units, test databases, you name it.  It's expensive to test this way, and there are only so many situations when integration tests are valuable.  On lean, agile teams - code coverage isn't held in as high regard as having working software.  On lean, agile teams - tests are a driver towards design, but they do need to be rooted in some level of initial thought on how a problem needs to be solved.