What’s In a Version Number?

Leave a comment

Just saw a post that Firefox 7 was released today as part of the “rapid release” strategy and I thought it was worth a few minutes to type a little blog for this.

Firefox has basically adopted 2 things here.  One is the Google-sque version numbering convention for just updating it quickly for no apparent reason other than there is a new sprint, the other is  what essentially amounts to the agile software development cycle.

Realistically Firefox can call their browser what ever they want and give it what ever number they want…3.0, 3.5, 3.6, 4.0, etc, etc, etc.  However what people are basically losing sight of is what that number means to people.  As somebody in the industry when I see a major or minor version number change like the ones above, I am trained to expect is problems.  It means that somewhere in the system someone has made a change that might or might not affect my application.  This is where the Firefox strategy starts to fall down badly.  Arguably the changes are minor that are happening, but as this post explains “we might break something” so you need to test.  As a corporation running internal types of tooling, this just doesn’t work.  I have no real need to be updating everything every 6 weeks and retesting so that I ensure that everyone of my 100+ applications still work with the new version.  In reality, 99% of them will be fine, but that 1% creates havoc since now I can’t update the browser, which might mean I can’t update the OS and invariably at some point I will get a newer application that won’t work on the old version…havoc ensues.

What the browser companies need to do a much better job of is what MS actually does a pretty good job of and that is backwards compatibility.  It is fine to do releases every 6 weeks, it is fine to add features to those releases, but you need to achieve the goal of giving people a stable platform that won’t necessarily break every time you turn around.



Google is Evil

Leave a comment

Ah Marjory, my little pet nickname for Google.  It is still my favorite search engine although as I have blogged in the past it is starting to lose that standing.  However today the good article I read was about the Google business model.  Anybody around me will quickly note that I will say Google is Evil.

Why is this?

Well when it comes right down to it, it is the fact that what Google really does is gather information about you and sell it.  Realistically this isn’t that much different from likely several dozen other companies out there, but what truly separates Google from the pack is that they are good at it to a level that is down right scary.  From the way that Chrome stores all of the settings on the web to the google+ you must register as your campaign.  As consumers we think it is great that we are getting all of this great stuff for free, however there is an old Japanese saying; “Things that are free, cost the most”.

There is a great little summation Blog today that nicely sums all of this up.


And where Marjory comes from: http://en.wikipedia.org/wiki/Fraggle_Rock

We Don’t Need One Until We Do

Leave a comment

I was reading a post this morning about the utilization of state machines in code and how most developers don’t use them.  The main comment that I noticed was the title above “We Don’t Need One Until We Do”.

I have definitely found this to be true however that comment has several implications that are worth noting that go well beyond state machines and is a commentary on development in general.

1. Requirements – In the ideal world we would have perfect requirements that would have foresight at least 5 years into the future, but the reality is that it isn’t normally that “we need one”, it is the business that needs it.  However the business doesn’t really know what technology they need to do anything and will never fully understand the implications of those decisions.  As such it can be invaluable to have a technology person the understands the basics of the business to at least be able to point out where something maybe much bigger than the requirements indicate.

2. We just don’t know – Similar to requirements regardless of the foresight and the business, you never really know what is going to happen, the economy takes a downturn, you suddenly have legal changes which impact your application, your company signs a big client which is different than anything in the past.  These all come together in ways that you can’t possibly foresee even a couple of years in advance, let alone a decade (gasp).  I only point this out since even making the perfect decision at the point in time it is made, there will still be things you would have done differently if you had to do it again.

3. Currency (Technological Debt) – Finally, both of the above points above lead to a day of reckoning where the customized component you have created with become so large and unwieldy that it is impacting everything around.  Once you reach this point it is already too late.  Development takes longer, testing takes longer, deployment takes longer, everything is taking so much effort that you have to replace it, however it is also so late that the endeavor to replace it will not be a trivial task.  Meaning, lots of time and lots of money invested in something with a fairly intangible business value. As often as not, people are comfortable with “the ways things are” and although might see a need to change, don’t think it is that bad.

Unfortunately the 3 items above tends to lead to “go big or stay home” syndrome.  Every little item gets wrapped up in a giant process and architectural exercise requiring review and signoffs and everything else under the sun.  Ultimately driving costs through the roof.  The real key for us all is to be able to understand the business needs enough to know whether or not you need to go for the gusto and buy that big enterprise component, or whether it is a small enough side line item that rolling your own is perfectly fine.

At my company we have a few poster children for these things like this as I am sure we all do, but the best example of one is a document generation engine we built 10 years ago.  Effectively it started as a “find and replace” string parser, however 10 years later it is a very complex custom piece of software that takes months if not years for new people to fully understand what is going on in there.  This would all be fine if our primary business was “document generation”, but in reality it is a service that simply supports the application.

In the beginning would I have done things differently?  In the beginning, maybe a little, but probably not much, the component served its purpose quite well for 5 years.  However, after that we started to add features to the document generation that culminated into the current issues, which is basically a very complex custom piece of code, which is buggy at best.  There are lots of reasons for that (some in our control, some not) that are worthy of a different post, but suffice to say that currency has finally caught up and things need to change.

In the end the key for all of us, is the understand when we need to go for the gusto and when we don’t.  And then when we didn’t go for the gusto the point at which we need to bite the bullet and move to the better model, rather than just bolting on more of the same.