Tuesday, January 19, 2010

Business Analysts and Software Developers

Of all the relationships within a software development organization, the one that seems to cause the most friction is the one between the business analyst and the software developer. I find this is often caused by a lack of understanding about who is responsible for what.

A BA where I'm currently working spelled it out best in a meeting a while back (Brian D). In our organization, the business analysts own the "who, what, why, where, and when" and the developers own the "how".

Not sure how this maps into other people's organizations, but it seems to be a good starting point. Very often I read requirements with a lot of "how" in them.

Examples of this sort of thing include:

  • Create a web service to enable validation of item information

  • Build a screen with 4 fields (create date, last modified date, historical cost, deleted flag

What I would expect, as a developer is something more like:

  • We need to be able to run the mainframe part validation routines against part data submitted from third parties

  • We need to display item information to our sales users... critical information they need to understand includes when the item was created, when it was last modified, what it cost before the last modification, and an indication if the item is currently able to be sold in our retail outlets

These examples are a little more verbose (thought they don't need to be), but also decouple the implementation (how) from the problem (why) and free the development team to explore alternative solutions. Perhaps instead of SOAP/WSDL web service, posting XML via HTTP is better... or maybe just FTPing a file is best... In the second example, perhaps it's best to just show an iconic indicator of if the item is active or not (versus a boolean flag). In addition, instead of simply naming the fields that should be displayed, the intent (why) and audience (who) of the page is better explained.

Monday, January 18, 2010

We're going crazy with all this service stuff

I heard this statement today and it stopped me in my tracks... It came from a developer who was trying to explain to me why it was a good thing to embed our job postings as static files in our main corporate website.

"After all, it only takes 15 minutes to get the new files and deploy the new version of the application" he continued. "After all, how often will they change?"

I had to resist the urge to say "sooner than you might think"...

At that point I should have realized that perhaps this guy was unreachable. I say that because when I attempted to explain my position he just waved me off and immediately stopped listening and started doodling on his notepad.

Upon reflection, a number of problems were evident:

  1. I have done a really bad job explaining the value of using reusable components or what a "service" is

  2. I have done bad job of explaining why decoupling the content of an application from the code is a good thing

  3. I have forgotten that I was 23 once and already knew everything there was to know about everything and that there was actually a time before I had to get woken up at 2:00am because a server stopped working.

  4. He didn't realize that spending 15 minutes a day for a year added up to roughly 1.5 weeks of work (BTW his 15 minutes are more like 1 hour)

  5. I didn't make it evident that every time we redeploy the app, we kick out users and risk screwing up our main corporate web site

I guess my lesson is to realize that some folks don't get the big picture and you need to be careful about delegating important decisions to them. I find it ironic that the very people who complain about the haphazard nature of our legacy applications, are continuing the tradition of not thinking through the solution.

Sunday, January 17, 2010


media cache (with caching)

I supposed the title of my previous post was a little bit misleading. The original (OK version 2) of that code actually didn't cache anything, but just acted as a reverse proxy to resize images.

I added some code to perform some rudimentary caching. You can now add


to have the browser cache the image on the local disk for 1 day. Similarly there are other combinations:.
To cache for 1 week add:


To cache for 2 hours:


What this means is that after the browser initially loads the image it will hold it on disk and not request it again for the amount of time that was specified. This doesn't apply if the user hits "reload", but works great for normal navigation.


This means users won't see a new copy of the image unless they explicitly hit "reload". You may need to use unique urls for changes to images once you start do this.

example (cache for 42days and resize to 256x256:

<img src="http://mediacache.appspot.com/mediacache/lh5.ggpht.com/_N8htlFAQOes/RiDF79J1dGI/AAAAAAAAAFU/qZfwdyr6O6o/s800/100_1342.JPG?size=256&cache=42d"/>

Saturday, January 16, 2010

App engine media cache

Ever needed resized images on your site but didn't really want to run batch resize operation?
Did you try setting the css settings to resize the image, but realize you where totally hosing your low bandwith users (or generally killing your user experience to begin with).

In response to these problems (and the general expense of tools like scene7) I began building a google app engine cloud computing service that will do this and ultimate enable caching. It is essentially an intelligent reverse proxy that will enable image transformation and caching via google app engine.

As an example, suppose you want to see the following image on your page

But you want it resized to 150px wide

One way (the css way) would be to apply style="width:150px" and you would get the following:

<img style="width:150px" src="http://lh5.ggpht.com/_N8htlFAQOes/RiDF79J1dGI/AAAAAAAAAFU/qZfwdyr6O6o/s800/100_1342.JPG"/>

You could use width AND height, but it won't maintain the aspect ratio.

Of course you're still streaming the entire 21KB image back to the browser and if you look closely, it really didn't do a good job of antialiasing the photo (the bucket in the back is just a strange white blob in the first one).

If you use the App engine image service, you instead stream back only 4kb to the browser, and it looks a bit better.

<img src="http://mediacache.appspot.com/mediacache/lh5.ggpht.com/_N8htlFAQOes/RiDF79J1dGI/AAAAAAAAAFU/qZfwdyr6O6o/s800/100_1342.JPG?size=150"/>

Obviously there is a lot more to do (like implement intelligent http caching), but I think this has a lot of potential. I'm sure there are other services that are cheaper than scene7, but I like the idea of leveraging google's infrastructure for this.

Saturday, January 9, 2010

The Road to Enterprise Cloud Computing

I'm at a company that has a number of fairly high traffic web sites. Essentially, there is a holding company that does the "IT Stuff" and there are a number of brands that we support. Problem is, all these brands want the same sort of stuff, but just slightly differently. For example, they all want a store locater, they all want to search for things by categories and attributes, they all want a movie player, new/blog service...

Historically, we'd get the request for a "rewrite" of a brand site. We'd spin up a project, start copy/pasting code from other sites and assemble a fresh new application from the pieces of the old ones.

This is good, we're at least reusing some things instead of simply recoding everything from scratch.... but, it's also bad. Why? Because we're creating independent copies of code that does the exact same thing (see copy/paste coding).

Our previous solution to this problem was to not really update anything after it's been released. Sure, we'd put some new imagery out there, but for the most part it was one for one swaps of things that where already there. In addition, if we DID decide to create a component, it was done via server integration. This meant that... sure we've got a jar file or dll that is a reusable runtime component, but we STILL needed to redeploy any updates across every site that needed it.

We've made an adjustment and are now going down a different path. We're now developing shared services that are URL addressable and can be linked into individual web pages by front-end developers (similar to google maps)

Our initial results are very positive, we've tried this out and have been able to reuse (at runtime) a service that folks have been clamoring for across the enterprise. Instead of copying a bunch of files from server to server, we embedded a bit of javascript in a web site and tada! we now have this new bit of functionality in other web sites.

This is modeled after how google maps allows you to embed a map in your browser. This is where the big money is to be made (or saved) for enterprise cloud computing and/or Service Oriented Architectures (SOA). Extract stand-alone services out so that they can be URL addressable and enable your front end teams to assemble novel and useful applications from a grab-bag of components that are available via the net.

For example, if I need a store locater service... I should be able to embed a link to a piece of javascript and have a store locater in my site. This can and should be done on the front end with no copying of files whatsoever. The back end server gnomes should be building these services... not necessarily so they can interact with each other (traditional SOA focus), but so that they can enable specific functionality in the enterprise.

So, SOA/ESB/ECC folks... stop worrying about creating monstrous infrastructure projects that may never yield results and start thinking about how to enable your enterprise developers to be more productive. For example, if you are a company of any size and you have a corporate hierarchy... build a service for the next project that needs "corporate hierarchy browse" that is completely stand-alone and anyone can use with only a one-line javascript link. Don't worry about Service busses, SOA blueprints, SOAP, ESB, other great big boondoggles being foisted on you by "arm chair architects". Worry about stuff that people need and use every day and make that really easy.

Monday, January 4, 2010

Leadership - Followership

Good leaders MUST be good followers. All to often people will get drunk on the idea of "being in charge" and forget that they're still part of a larger team. I've seen teams work on projects that are completely counterproductive to the objectives of the larger organization. You are a piss poor leader if you do not follow your leader.

Without followers you are not a leader. You might be "in-charge", but that doesn't necessarily make you a leader. Many folks make the mistake of assuming that having their name at the top of the org chart makes them the leader. This is not so and is a myth that should be dispelled.

Good followers are not necessarily good leaders. Perhaps the best example of the peter principle at work is to have people try and "groom" good followers into becoming good leaders. While this may work in some situations, there are people who are perfectly happy to follow and not take on the responsibility of leadership.

EGO will make folks bad followers AND bad leaders. The fact that a leader-follower relationship exists should imply that there is a team with shared objectives. When you are on a team, you must check your ego at the door, it's not about you, it's about the team.

Sunday, January 3, 2010

Information Architecture

Information architecture (IA) is a relatively new field that is absolutely critical for building effective information systems. The best definition I can find for IA is from www.interaction-design.org.
The goal of Information Architecture is to improve information access, relevancy, and usefulness to a given audience, as well as improve the publishing entity's ability to maintain and develop the information over time

This definition is OK, but it seems to be heavily biased toward software user interfaces and web design. Most folks, if they think of IA, want to know which button should go here and which field should be next to which other field. While this is an obvious and important application of IA, it is the equivalent of worrying about the order of the words in the title of a book, but ignoring the other 200,000 words INSIDE the book.

As a person who working on projects that exist almost exclusively in the mind, a large part of my time is spent trying to get people to work from a shared mental model. THIS is the important part of IA, NOT which widget goes where on the screen. Of course, getting people to realize this requires you to first try to get people to work from a shared mental model... and so on...

As a short example, I spent some time last week discussing how we should implement a piece of our software. There were three people in the discussion, two were "on the same sheet of music" and I was off marching to the beat of my own drum. I was insisting that using a decorator to markup the outside of pages would make things easier for the front end developer (in this situation), but the front end developer and the back end developer where both in agreement that this was NOT helpful. Unfortunately, they disagreed on how to make the composition of the pages work in the way the front end guy really wanted.

In the course of the conversation, it became clear that the front-end guy was expressing his ideas assuming we understood the terminology and mechanics of how templates are implemented in Django and how he used that in the past. Because neither I nor the other developer present had used Django extensively, he wasn't making a whole lot of sense. After switching from words to pictures and some hand waving, we started to break through to the fundamental idea.

The problem is that each of us were hung up on irrelevant details and not seeing through the problem to the core solution. In addition, there was no good way for us to comprehend each other's frame of reference to understand what mental model we used to arrive at our position.

While the definition above does address some of this, I propose a better definition for IA:

Information architecture is the art and science of designing and sharing mental models.


Saturday, January 2, 2010

T. Boone Pickens, Bill Gates, Warren Buffet, Steve Jobs, Eddie Lampert

I'm reading a book by T. Boone Pickens The First Billion is the hardest and I heard the same old story repeated. Mr. Pickens, as well as the others mentioned above are similar in that they are all fairly wealthy; but digging deeper, they are hard workers who take big risks and subsequently have reaped great rewards.

When you look at the sorts of things these guys do, it's striking that they are in different industries and have different techniques for success within their industry. A few are crappy leaders (of people), they've all made various and arguably large mistakes. More importantly, however, they also all observe the world around them, seek out opportunities, take calculated risks, and succeed where others are not even looking.

None of them "got rich quick", they moved forward at what some might actually consider a snail's pace. Each tiny step forward, however, built upon previous successes and failures. When studying these guys, the 80's movie The Secret of My Success almost seems to be a legitimate blueprint for success. Michael J Fox's character realizes an opportunity, not because someone approached him and said "here's a great opportunity", but because he dug in and found value and didn't take "no" for an answer.

work hard, take chances, seek value