I had a great conversation the other night while at the Seattle Web Analytics Wednesday (#waw) with Carlos (@inflatemouse) and a dozen others.  @inflatemouse brought up the idea that an analytics provider using the cloud, increases or at least possibly increases the risk of security breach to the data.  This is, after all a valid point, but because of the inherent way web analytics works this is and is not a concern.

Web Analytics is Inherently Insecure

Web analytics data is collected with a Javascript Tag.  Omniture, Webtrends, Google, Yahoo, and all of the analytics providers use Javascript.  Javascript is a scripting language, which is not compiled, and stored in plain text in the page or an include, or passed into the URI when needed.  This plain text Javascript is all over the place, and able to be read merely by looking at it.  So the absolute first point of data collection, the Javascript tags, is 100% insecure.

The majority of data is not private.  So this insecurity isn't a huge risk or at least should not be.  If it is, you have larger issues before you even contemplate using an on-premise and cloud solution to bump up your compute and storage capabilities.  Collecting data that needs to be secure via web analytics is an absolute no.  Do NOT collect secure, private, or other important pieces of data this way.  If you have even the slightest legal breach in this context, your entire analytics provision could have this data scraped, possibly used in court in a class action suite, or in other ways even.

For the rest of this write up, I will assume that you?ve appropriately encrypted, or enabled SSL, or otherwise secured your analytics or data collection in some way.

Getting that Boost on Black Friday

eE-commerce has gotten HUGE over the last decade.  The last Black Friday sales and holiday season saw the largest e-commerce activity in history.  Omniture, Webtrends, and all of the other web analytics providers often see a ten fold increase in web traffic over this period of time.  Sometimes, for some clients, this traffic is handled flawlessly by racks and racks of computers sitting in multiple collocation facilities around the world.  However, for some clients that have exceedingly large traffic boosts, data is lost.  (yes, ALL the providers lose data, more so during these massive boosts)  The reason is simple, the machines can?t process in time or handle the incoming traffic because the extra throughput isn?t available to scale.

Enter the cloud.  The cloud has vastly more scalability, almost an infinite supply by comparison, to any of the infrastructure available to the analytics providers.  Matter of fact the cloud has more scale available than all of the analytics providers.  This is actually saying a lot, because Webtrends (and maybe some of the others) I know does an amazing job with their scalability and data collection, arguably more accurate and consistent than any of the other providers (especially since many of them just sample and "guess" at the data).

So when you extend your capabilities to the cloud for web analytics do you really increase your security vulnerability?  Most of the providers of web analytics have their own array of security measures, that I won't go into on levels of security.  However, does introducing the cloud change anything?  Does it alter the architecture so significantly as to introduce legitimate security concerns?

Immediately, from a functional point of view, assuming good architecture, intelligent system design, and good security practices are in use already, introducing the cloud should and is transparent to clients.  For the provider it should not increase legal concerns, functional concerns, or otherwise pending the aforementioned items are taken care of appropriately.  But that is just it, every single current provider has legacy architecture, various other elements that do not provide a solid basis for a migration to the cloud for that extra bump of power and storage.

So what should be done?  What if a provider wants that extra power?  Can the technical debts be paid to use the awesome promises of the cloud?  Is the security really secure enough?

Probably not.  Probably so.  But . . .

This provides a prospective opportunity for a new solution for web analytics to be provided.  It provides a great opportunity for a modern cloud based solution, that provides more than just a mere Javascript tag and insecure unencrypted data to be collected for analysis.  It provides the grand opportunity to design an architecture that could truly lead the industry into the future.  Will Webtrends, Omniture, Unica, or someone else step in to lead the analytics industry into the future?

At this point I'm not really sure, but it definitely is an interesting thought and a conversation that I have had a lot of people at #altnet meetings, cloud meetups, and with cloud architects, engineers, and others that have similar curiosities.  I await impatiently to see someone or some business take the lead!

The first two sessions on Sunday were Collaboration and why it is so hard and the following, which was a perfect following session was on Kanban.  While in that second session two online Saas Style Tools were mentioned; AgileZen and Leankit.  I decided right then and there that I would throw together some first impressions and setup some sample projects.  I did this by setting up an account and creating the projects.

Agile Zen

Account Creation

Setting up the initial account required an e-mail verification, which is understandable.  Within a few seconds it was mailed out and I was logged in.

Setting Up the Kanban Board

The initial setup of the board was pretty easy.  I maybe clicked around an extra few times, but overall everything I needed to use the tool was immediately available.  The representation of everything was very similar to what one expects in a real Kanban Board too.  This is a HUGE plus, especially if a team is smart and places this tool in a centrally viewable area to allow for visibility.

Each of the board items is just like a post it, being blue, grey, green, pink, or one of another few colors.  Dragging them onto each swim lane on the board was flawless, making changes through the work super easy and intuitive.

The other thing I really liked about AgileZen is that the Kanban Board had the swim lanes setup immediately.  One can change them, but when you know you immediately need a Ready Lane, Working Lane, and a Complete Lane it is nice to just have them right in front of you in the interface.  In addition, the Backlog is simply a little tab on the left hand side.  This is perfect for the Backlog Queue.  Out of the way, with the focus on the primary items.

Once  I got the items onto the board I was easily able to get back to the actual work at hand versus playing around with the tool.  The fact that it was so easy to use, fast and easy UX, and overall a great layout put me back to work on things I needed to do versus sitting a playing with the tool.  That, in the end is the key to using these tools.

LeanKit Kanban

Account Creation

Setting up the account got me straight into the online tool.  This I thought was pretty cool.

Setting Up the Kanban Board

Setting up the Kanban Board within Leankit was a bit of trouble.  There were multiple UX issues in regard to process and intuitiveness.  The Leankit basically forces one to design the whole board first, making no assumptions about how the board should look.  The swim lanes in my humble opinion should be setup immediately without any manipulation with the most common lanes;  ready, working, and complete.

The other UX hiccup that I had a problem with is that as soon as I managed to get the swim lanes into place, I wanted to remove the redundant Backlog Lane.  The Backlog Lane, or Backlog Bucket should be somewhere that I accidentally added as a lane.  Then on top of that I screwed up and added an item inside the lane, which then prevented me from deleting the lane.  I had to go back out of the lane manipulation, remove the item, and then remove the excess lane. 

Summary

Leankit wasn't a bad interface, it just wasn't as good as AgileZen.  The AgileZen interface was just better UX design overall.  AgileZen also presents a much better user interface graphical design all together.  It is much closer to what the Kanban Board would look like if it were a physical Kanban Board.  Since one of the HUGE reasons for Kanban is to increase visibility, the fact the design is similar to what a real Kanban Board is actually a pretty big deal.

This is an image (click for larger) that shows the two Kanban Boards side by side.  The one on the left is AgileZen and the right is Leankit.

• The two main concepts of Kanban is to keep the queues minimum and to maintain visibility.
• Management/leadership needs to make sure the Kanban Queue doesn?t get starved.  This is key and also very challenging, being the queue needs to be minimal but also can?t get too small during the course of work.  This is to maintain maximum velocity.
• Phases of the Kanban need to be kept flowing too, bottlenecks need removed ASAP when brought up.
• Victory Wall ? I dig that idea.  Somewhere to look to see the success of the team.
• The POs work in Rally or other tools for some client management, but it causes issues with the lack of "visibility" ? a key fundamental ideal & part of Kanban.
• One of the big issues is fitting things into a sprint, when Kanban is used with Scrum, but longer sprints are wasteful.
• Kanban work sizes are of a set size.

At this point I got a bit side tracked by the actual conversation and missed out on note taking.  Overall, people doing Kanban and Lean Style Software Development I would say are some of the happiest coders around.  The clean focus, good velocity, sizing, and other approaches that are inferred by Kanban help developers be the rock stars and succeed.

This is definitely a topic I will be commenting on a lot more in the near future.

Below are the notes I made in the REST Architecture Session I helped kick off with Andrew.

• RSS, ATOM, and such needed for better discovery.  i.e. there still is a need for some type of discovery.
• Difficult is modeling behaviors in a RESTful way.  ??  Invoking some type of state against an object.  For instance in the case of a POST vs. a GET.  The GET is easy, comes back as is, but what about a POST, which often changes some state or something.
• Challenge is doing multiple workflows with stateful workflows.  How does batch work.  Maybe model the batch as a resource.
• Frameworks aren?t particularly part of REST, REST is REST.  But point argued that REST is modeled, or part of modeling a state machine of some sort? ?
• Nothing is 100% reliable w/ REST ? comparisons drawn with TCP/IP.  Sufficient probability is made however for the communications, but the idea of a possible failure has to be built into the usage model of REST.
• Ruby on Rails / RESTfully, and others used.  What were their issues, what do they do.  ATOM feeds, object serialized, using LINQ to XML w/ this.  No state machine libraries.
• Idempotent areas around REST and single change POST changes are inherent in the architecture.
• REST ? one of the constrained languages is for the interaction w/ the system.  Limiting what can be done on the resources.  - disagreement, there is no agreed upon REST verbs.
• Sam Ruby ? RESTful services.  Expanded the verbs within REST/HTTP pushes you off the web.  Of the existing verbs POST leaves the most up for debate.
• Robert Reem used Factory to deal with the POST to handle the new state.  The POST identifying what it just did by the return.
• Different states are put into POST, so that new prospective verbs, without creating verbs for REST/HTTP can be used to advantage without breaking universal clients.
• Biggest issue with REST services is their lack of state, yet it is also one of their biggest strengths.  What happens is that the client takes up the often onerous task of handling all state, state machines, and other extraneous resource management.  All the GETs, POSTs, DELETEs, INSERTs get all pushed into abstraction.  My 2 cents is that this in a way ends up pushing a huge proprietary burden onto the REST services often removing the point of REST to be simple and to the point.
• WADL does provide discovery and some state control (sort of?)
• Statement made, "WADL" isn't needed.  The JSON, XML, or other client side returned data handles this.

I then applied the law of 2 feet rule for myself and headed to finish up these notes, post to the Wiki, and figure out what I was going to do next.  For the original Wiki entry check it out here.

Last week I posted the "Techie Land Silly Questions" and promised a response.  So here it is.

Question #1:  If you did not have to work, had a few dollars stashed away so that you could live comfortably and do whatever you wanted, what would you do?  Would you still code?  Would you still create?  What would you create?  Would you be able to stay idle?

I would create fun SaaS style web apps running in the cloud.  Probably a few phone apps too.  If I made tons of extra money, ya!  If not, oh well.

I would also setup time to drift, hard core style, probably own at least 2-3 S13s, 1 370Z for road trips, and possibly either an R34 or R35 GT-R for time attacks.  The catch of course is IF there was that much money to live on.

The other bits would be to, if possible, have a country house far away from others in a tranquil and awesome place were I could think and be away from the world once in a while.  The other would be to have a modest, 1000-1400 sq ft loft or condo of some sort in an urban environment in a preferred city (like say New York, Seattle, Portland, or some place of that sort) that would allow me appropriate parking or access to transit to get to my parking for the above mentioned vehicles.

Last but not least, I would love to write tons and tons of music until forever.

So put simply, I would absolutely NOT stop coding, but I would work on a LOT of other things without a regular 8hr daily gig.  The thought is fun, but even then I'm sure one of the above things would become a "job" of sorts.  Something always is the daily job.  : )

Question #2:  Based on whatever you did with your free time, what would you title yourself?  Chief Potato Masher, Pencil Pushing Writer o? Stories, or Coffee Endeavorer o? Tastiness?

Cowboy is one I like lately.  Cept' not in the "Modern Country Cowboy music hick", but in the honest, by the earth, live by the seat of my pants, keep the holster filled with a loaded 6 shooter type of Cowboy with integrity.  Yeah, that I dig.

I suppose the other one I go by is ok, Agilist Mercenary has cool ring to it.

Within Webtrends Insight one has the ability to check out the story, an automatically generated feature that gives a written overview of the activity on your site.  I really like this feature as it gives verbal perspective.  Below is a screen capture of my blog as of today for the last 7 days. Click on the image for a larger image for readability.

The other really great looking bit is the Visits Overview Report.  All Web Compliant, and I'd show you the page, but you have to have a Webtrends Analytics Account.  :P

That is it for this week.  I am out on vacation next week, so the blog will be nice and silent.

Ok, it is time for an off the cuff, random, oddball, just for fun blog entry.  Two questions for the readers in Internet Land.

Question #1:  If you did not have to work, had a few dollars stashed away so that you could live comfortably and do whatever you wanted, what would you do?  Would you still code?  Would you still create?  What would you create?  Would you be able to stay idle?

Question #2:  Based on whatever you did with your free time, what would you title yourself?  Chief Potato Masher, Pencil Pushing Writer o? Stories, or Coffee Endeavorer o? Tastiness?

There are a million possibilities, I would love to know what you would call yourself, so please do leave a comment or three. I will have my answers later in the week.  So stay tuned and help me out with some comments.  You can bet it will include something along the lines of what I already do, but I'll keep it a secret until then.  : )

I was listening away to some ear blistering metal, as I often do, and an ad really jumped out at me.

If you can?t see what is written in the HTC ad to the right, click on the image.  What is displayed is a cross-correlation of several points of analytics data.  Before I jump right in and start explaining each point, think about what is going on with this ad.  This is by no means just some simple ad, there are a number of things going on here.

First data point.  Sprint & HTC, or whoever it is that put this ad together, has retrieved my listening favorites from Pandora.  Just looking at the bands listed shows that to be self evident.  This also seems to be the most obvious piece of data they could have collected about me, since I am logged into Pandora.  This is probably achieved by some web services or other API that Pandora provides advertisers.

The second data point is not immediately noticeable.  I am still at a loss to explain where they retrieved this data point.  What is it?  Concert dates for bands.  Each of the bands listed in the HTC app that is displayed is a coming show.  Matter of fact, it almost seemed like they had shown me my own HTC, except I don't own one.  :)

Now my location data, I am suspecting probably came from Pandora too, but it is the third point regardless.  All together the ad utilizes geo-positional location, my Pandora music preferences, and pulls local concerts from another source (maybe a Pandora listing too?).  This is a perfect use of preferences to display things that are truly relevant to me.

In addition, they may have just helped to sell me on a new phone for my personal line.  I am up for a replacement and anything that runs Google Droid seems cool, but I?ll admit, with the sneak peaks at Windows 7 Mobile that I've seen and the proposed ability to use Silverlight ? I WILL BE switching from the iPhone when that is released.

Again, conversations give me a zillion things to write about.  The recent conversation that has cropped up again is my various viewpoints of the Agile Manifesto.  Not all the processes that came after the manifesto was written, but just the core manifesto itself.  Just for context, here is the manifesto in all the glory.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Several of the key signatories at the time went on to write some of the core books that really gave Agile Software Development traction.  If you check out the Agile Manifesto Site and do a search for any of those people, you will find a treasure trove of software development information.

My 2 Cents

First off, I agree with a few people out there.  Agile is not Scrum for instance.  Do NOT get these things confused when checking out Agile, or pushing forward with Scrum.  As David Starr points out in his blog entry,

"About 35 minutes into this discussion, I realized I hadn't heard a question or comment that wasn't related to Scrum. I asked the room, How many people are on an agile team that is NOT using Scrum?

5 hands. Seriously, out of about 150 people of so. 5 hands."

So know, as this is one of my biggest pet peves these days, that Scrum is not Agile.  Another quote David writes,

"I assure you, dear reader, 2 week time boxes does not an agile team make."

This is the exact problem.  Take a look at the actual manifesto above.  First ideal, "Individuals and interactions over processes and tools".  There are a couple of meanings in this ideal, just as there are in the other written ideals.  But this one has a lot of contention with a set practice such as Scrum.  There are other formulas, namely XP (eXtreme) and Kanban are two that come to mind often.  But none of these are Agile, but instead a process based on the ideals of Agile.

Some of you may be thinking, "that's the same thing".  Well, no, it is not.  This type of differentiation is vitally important.  Agile is a set of ideals.  Processes are nice, but they can change, they may work for some and not others.  The Agile Manifesto covers the ideals behind what is intended, that intention being to learn and find new ways to build better software.

Ideals, not processes.  Definition versus implementation.  Class versus object.  The ideals are of utmost importance, the processes are secondary, the first ideal is what really lays this out for me "Individuals and interactions over processes and tools".  Yes, we need tools but we need the individuals and their interactions more.

For those coming into a development team, I hope you take this to mind.  It is of utmost importance that this differentiation is known and fought for.  The second the process becomes more important than the individuals and interactions, the team will effectively lose the advantages of Agile Ideals.

This is just one of my first thoughts on the topic of Agile.  I will be writing more in the near future about each of the ideals.  I will make a point to outline more of my thoughts, my opinions, and experience with the ideals of Agile and the various processes that are out there.  Maybe, I may stumble upon something new with the help of my readers?  It would be a grand overture to the ideals I hold.

Recently the question came up from a close friend of mine, "will my PhD help me attain a higher income in the north west?"  I had to tell him, that it might get him a little more, but it won't get him in the top income brackets for the occupation.  Another time, a few days later, someone else asked this too.  Then again, I see a job posting that requires a Bachelors Degree and some other nonsense.  The job posting even states they want "A-Game" talent.

I am almost shocked at how poorly part of this industry doesn't realize how unimportant a degree is to getting real top tier, a-game talent.  (and yes, I get a little riled up about this matter)

You Can't Make Good Software Developers.  No college out there is going to train someone to be in the top 10%, and absolutely not to be in the top 5% of skill levels.  Colleges can NOT do this.  It is up to the individual, and the individual alone.  If top tier talent seems to come from a college, one should check their premise and look at the motivations the individuals have to go to that school.  There is most likely a reason that top tier talent appears to be made there.  The college however, can only guide or assist, but I repeat that "top tier talent is a very individualistic endeavor".

Some might say, well a group is needed, support is needed, this and that are needed.  True, an individual needs a support system and a college can provide that, but it generally ends there.  The support group helps, provides a sounding wall, and provides correlation to good ideas for the a-game top tier geek.  But again, the endeavor is the individuals desire.

top tier talent is a very individualistic endeavor - Me

Hiring Top Tier, A-Game Talent

There are a few things when trying to hire this level of game player.

1. The first thing is to not require a degree of any sort.  Sure, it looks good, but it won't dictate anything other than the individual was able to go through the regimented steps of college.
2. List the skills and ideas that you would like to find in an individual.  Think of two people meeting for the first time, what do you want to know about the other individual.  Team fit is absolutely fundamental for top tier talent.  That support group that I mentioned above, top tier talent works best with a solid group of players.
3. Keep your technology up to date, moving forward, and don't bore your top talent if you manage to get it.  If the company slows down, they will leave.  The more valuable they find out they are, the lower tolerance they'll have for this.  For managers, directors, and leaders in an organization this is THE challenge for them.
4. Provide opportunities not just for advancement, but ways for them to advance their knowledge such as training, a book budget, or other means.  Even if some software they want to use isn't used ton the project, get it for them (within reason of course ? couple $100 or even a few $1000 for a good software license to MSDN, Tellerik, or other suite of software is ideal).
5. Don't push them to, and don't let them overwork themselves into burnout.  This, as a leader in an organization is easy to do if one finds themselves actually hiring top talent.  Because top talent just provides results and more results.  But they are human, they will break, don't be the cause of that or you'll lose your talent.

For now, that is it from me on this topic, back to the revenue, code, projects, and pushing forward.