Archive

Monthly Archives: September 2009

As many in the analytics industry know, Adobe has put up $1.8 billion for Omniture.  Several blog entries floating around out there;  More color on Adobe + Omniture by Eric Peterson, Webtrends encouraged by Adobe?s purchase of Omniture at the Oregon Live Site, Congrats to the Omniture folks! A Q & A with myself by Akin, Why Did Adobe Buy Omniture? by Anil Batra, Adobe buys Omniture:  What are they thinking? by SemAngel (Gary Angel) and many others.

Amid all the things written in those articles and entries, I will leave just as they are written without comment.  Everything written in these conversations are pretty much similar ideas, about how it is truly an odd purchase.  That is great from my perspective, I am a Webtrends Employee and I enjoy the work very much.  I find the competition growing and lively.  But there is one thing I want to comment on, and it is mostly a technical observation that I would love for non-technical people to take heed of.

The one thing I want to comment on is this mythic idea Microsoft may be or should be scooping in at the last second and bidding on Omniture.  There was even some statements that Microsoft should have bought Omniture.  The major issue with this is two fold;  Omniture & Microsoft are built, generally, on completely different technology stacks.  Microsoft uses, well, Microsoft‘s Technology Stack and Omniture uses a deluge of non-Microsoft Technology (with a few MS Products here and there, like their Excel Tools).  So even if that was a match, it would have been really bad for Microsoft, as the publicity for not dog fooding their own technology after this mythic purchase would have been huge.  The cost for Microsoft to rewrite the entirety of almost every tool Omniture has would have been overwhelming, even for Microsoft.  The cost, in the end, would absolutely not be worth it for Microsoft.

I won’t venture about our technology stack at Webtrends, nor Adobe & Omniture‘s Stack, other than to say from the technical perspective Adobe matches Omniture‘s Tech Stack far better than a Microsoft & Omniture stack.  Adobe has a fine history of taking disparate ? specifically non-Microsoft technologies ? and getting them to work together.

…and to a great 09′ and improving economy for everyone, Cheers!

Recently I have watched a couple of good videos on InfoQ regarding Agile Software Development.    Alistair Cockburn’s "I Come to Bury Agile, Not to Praise It", which ironically is a pro-Agile talk.  The other talk that I dug was Scott Ambler’s "Agile by the Numbers:  What People Are Really Doing in Practice".

[beware, random interspersed doses of sarcasm below]

After watching these two talks, I have decided on a new path I am going to take.  I am going to start mistrusting and hating agile.  You know, so I can fit in and stuff.

I recently watched a video presentation of Alistair Cockburn, who is a fairly major name in the Agile Development Community.  It pushed me to put this entry together for future discussion that I intend to kick off (at least on this blog & the few readers I have).  I have worked on the following Agile Projects:

  • My most recent project utilizing Agile Processes was at Webtrends for my stint in Engineering late 08 and earlier 09.  I worked on a team to build web services for Webtrends data access for customers.
    • The team consisted of three people, one being a team lead.  Our primary use of Agile was somewhat limited as it was a new process for the team.  We performed continuous builds via Team Foundation Server and test driven development when feasible.  We were limited in using TDD to some degree as a large part of the work was configuration based for server configuration and required a large degree of integration tests more than isolated unit tests.  In addition to TDD we also utilized user stories, burn down charts, and to some degree kanban style prioritization.  The project was a rocking success, and is now offered as a Webtrends offering and documented, discussed, blogged and continuously maintained and advanced.  Even though I am on a different team now working directly with customers to implement integrations with these REST based web services, the engineering team continues forward with more Agile practices being used daily, including paper prototyping, furthering the unit testing majority of the teams, and more.
  • After* and before* the Webtrends engagement I helped to initiate Agile in a development group of 4 people at Axiom Group (now Axiom EPM) to build a Excel UI to SQL Server for accounting data storage, manipulation, analysis, trending, and retrieval.  I helped get the group kick started, and the software that was released is now called Axiom Planning.
    • The team of 4, split into two pairs, and we did pairing & individual development.  Other agile software methods used were rapid learning, extensive test driven development, continuous integration (w/ TeamCity), unit tests in builds w/ good coverage (the logical kind), mocking (for databases), self organizing team, paper prototyping, and direct daily communication with customer representatives.  We also as pairs and as a team used refactoring heavily.  In addition heavy utilization of design patterns and domain driven-design was used in close collaboration with the customer.
  • In 06 & 07' I worked with Centerstance Consulting on a project which started Waterfall and moved to Agile during the course of the engagement.  We started off a team of 5 developers, grew to about 16 at one point, and shrunk down toward the completion of the overarching architectural design to about 8-12 again.
    • The teams ranged from 4-5 people per team with a team lead, to two teams with two sub-teams split with a team lead each doing their own respective stand ups (SCRUM style), a continuous integration was setup, unit & integration testing was eventually put into place across a wide spectrum of the code base.  Mocking, faking where appropriate, and general unit testing took place, with business analysts acting as customers.
  • For Ghallt Enterprises I served as CTO with a business partner, leading efforts among remote teams, utilizing Agile practices (yeah, remotely, I know, it seems crazy) to develop social media software.  Methods included continuous integration, build management, pair development, code review & refactoring on a regular basis, and other practices.  Even though this is a company that a friend and I started, it served to provide a catalyst for me to push forward extensively into Agile Processes.  The level of progress, quality of code, and other characteristics that are inherent to effective Agile Processes were of a level that left no reason to endeavor toward traditional style project planning or Waterfall style approaches.

I?ve worked with others to mentor and experiment with pair development, continuous integration, unit testing, and other processes to enhance and streamline the software development life cycle.

* I write after and before Webtrends because I left Webtrends in 08' to work the Axiom effort, upon kicking that off, I then headed back to Webtrends to work on the then new Web Services with REST Architecture Project.

Wow.  Today has been one of those, "go here, go there, do this, do that, quick hurry, finished, done, thanks, awesome, bang" type of days.  Getting a lot accomplished, but also so busy it is hard to see the finished efforts for all the new efforts coming by way.

Lunch 2.0

Today I did manage to make it to my first Lunch 2.0, saw some familiar faces and some new faces I haven't met.  One of these new people that I met was Eric M. Curtis, the creative director & interface designer for rgb Design Studio.

Business Development

I also had a morning coffee at a ridiculously early 7:10am today with some un-named sources.  We discussed some new upcoming analytics business opportunities that may be heading Webtrends way and the recent large event in the analytics industry, the acquisition of Omniture by Adobe.  This of course is on my mind as I have developed tons of Flash & AIR tagging solutions over the last few months, which now gives me pause.  Many in the industry wait with bated breath as to the path Adobe will now take with this acquisition.  As many in the industry have already stated, it is a somewhat strange pairing and not to jump on that bandwagon, but it does seem that way.

In Other News

I have a number of projects I am working on, all which will benefit Webtrends Analytics customers as well as people in the analytics industry in general.  A few blog entries (which you'll have to read on the Webtrends Blog or the Webtrends Developer?s Blog), and a whole bunch of awesome technical bits, code snippets, and other code based sundry.  So stay tuned, more to come.  :)

Alright Mr & Ms Developer.  This hasn't happened in a while, since most of my work as of late has been green field (i.e. brand new development).  But in the past, oh boy have I gotten some pure crap.  I am a bit arnery today, so just bare with me, I need to rant a bit.

When I am handed code to fix, maintain, alter, or read for any reason I would love to have unit tests come along with it.  If someone then promises to provide unit tests for the code they are writing that is being handed off to me, I expect the unit tests to run, execute isolated, and throw green lights across the board.  However there are a billion different things I run into all the time that frustrate me to no end.  If you promise me unit tests, do NOT . . .

[RANT ON]

DO NOT give me unit tests that take 13 steps to setup, fake data INSERTs against an un-configured or even pre-configured database.  That is NOT isolated and it makes them almost entirely useless to me.  It might be great for your own personal testing, but it doesn't help me understand the isolated unit of work, the separation of concern, or anything else about the actual code.

DO NOT give me unit tests that outright fail immediately.  If they all fail that means you have NOT finished your work.  It means your code doesn't work.  Please, make the tests work right, make the code work right before passing the buck.  Note:  I said please! :)

DO NOT write a unit test for something that checks the length of a string when you need to check the content of the string.  Don't check that something is a number when the method adds two numbers, instead check to see if the numbers are aggregated correctly.

DO NOT tell me you have 100% code coverage and then hand me tests that basically asset that a mocked method executes on an object.  OF COURSE THE METHOD EXECUTES, YOU ARE MOCKING IT!!!

DO NOT give me unit tests that test so far across boundaries that isolation is lost by so many degrees it would take many minutes, if not hours, to figure out what the test doesn't work.

[Rant Off]

In all honesty I would rather get code and just be told the truth;  ?X tests do not work anymore?, ?I could not figure out a way to test this so I did this dumb partial test thing?, or simply ?I was screwing around so I didn?t get full coverage, to make management shush up I did a quick assert fake to get the rest of the coverage?.  I'm a developer too, I will understand and probably have no problem at all that something is not completely done, partially done, or you hit a stumbling block.  I do it all the time, I also make a point to lay it out the way it is.  No point in beating around the bush.

Keep in mind, if your management thinks you need to slave away and be forced to lie about things, you can probably go work somewhere else within a few weeks.  Even in this crappy market there is barely any reason to allow bad management to treat develops like crap or to mismanage projects.  So don't take the bull and just make sure to keep things on the up and up with your fellow developers.  i.e. DON'T lie about your unit tests!  Cheers!

Follow

Get every new post delivered to your Inbox.

Join 3,273 other followers