Software application development
This blog is intended to provoke discussion and exchange between like minded software application developers, engineers, architects, project managers - and keen hobbyists too.
Monday 17 March 2008, 3:39 PM
Hitting the exponential software growth curve hard
(Not because the company failed to think about them in the first place and had to rush them in for the update after user feedback of course.)
Then we get major re-releases and 2.0 comes along. Then 2.1 and so on – nothing new so far I know, bear with me please…
What the vendors sometimes don’t talk about with any specificity is the amount of code growth that goes on between the different phases of the application’s development. Is the same amount of growth going on between 1.1 and 1.2 – and does moving from version 1.0 to 2.0 represent the same as level of code update (and functionality) as the jump from 4.0 to 5.0?
'The reason I pose these posers is that I’ve been getting used to working with QuarkXPress 7.1 – my page layout designer on the other hand is using 6.0 and the thing is that the there has been so much change between the versions that we can’t simply share files between each other. I can read his files, but I have to export backwards (to the previous version) during my saves.
(NB for technical accuracy I recently had the chance to meet Quark CEO Ray Schiavone and he assured me this situation has been or is being fixed.)
So the discussion here is that we should look carefully at new release roll-outs and ask what kind of change (and how much of it) has gone on. Also, perhaps we should ask ourselves why the company behind the application has carried out such a big software upgrade. Were they too busy doing something else? Were they just pushing tired out goods into the market? Was there a genuine reason why they went back to the drawing board and performed so much re-engineering?
We can ask the same question of small changes of course – are they just being done for marketing purposes? Are they being done to create an impression among the customer base that they are using a constantly evolving product? Is the company about to host its annual user conference and they need a product to announce?
Or – just maybe we need better release notes?
PreviousComments on this post
As a follow up to yesterday’s blog - I asked a pal of mine called Mike Harrold for his thoughts on this subject. Mike has run the International Sybase User Group for a good while now so he’s pretty used to dealing with upgrades emanating from various corporate ivory towers and communicating their functions and usage to real developers and DBAs. I stress that Mike is not a Sybase employee, so - in my opinion - he’s a good impartial person to quiz on this.
Here's what Mike told me:
“Unfortunately, in a large number of cases nowadays, version numbers are dictated by corporate marketing and not engineering. The fact is that version numbers when applied in true terms -- major.minor.patch -- often mean little to the people purchasing the software.
That's probably why more companies are promoting their products using different methods. Microsoft's naming of its operating system and Quicken's tax software are two that immediately come to mind.
Contrast that to the GNU compiler, which after more than 20 years of extremely active and continuous development is today at version 4.3.0 because their engineering-based version numbers really mean something related to the incremental development of the software and the users -- developers -- recognise that.
I can understand that maybe 4.3.0 isn't sexy, but nowadays, “dot-Oh” releases (such as 7.0) are often interpreted by customers as a warning not to install, as the product is likely to be riddled with bugs. That can't be good for the revenue stream, surely? Maybe it is time to leave the version numbers where they belong -- Engineering -- and follow another method for product marketing entirely?"
