Third party software development: what you don’t know

I don't agree with this article at all. If huge blocks of code need to be re-written for every new version of Windows/SQL server then there's a much more fundamental problem with the way this company develops software. If one uses platforms such as .NET you can be almost guaranteed your software will work on any OS supporting the version of .NET you coded your application in. We have very little problems with software coded many years ago in .NET (and even MFC) for WinXP/2000 when running them on Win7 64bit. And when it comes to tools such as SQL, proper software design should make any changes a minor problem.
 
Kevin Phillips is obviously just pissed that they have to upgrade their '98 software.

Seriously though, this is like saying that cars should never get new sound systems because it won't support older media. WTF so big companies must stop innovating and upgrading their systems because the poor little 3rd party developer has to do the same?

I am a developer. And this is a stupid article. It's about the consumer, not the developers.
 
I can't say new Windows releases have ever caused any trouble for me or my colleagues. Lots of stuff I wrote for 98 and XP in C++ still works today in Windows 7.

As double_n said, something seems very off if you need to rewrite code to support a new version of windows. I could see at worst case there could be some strange new oddball bug that you may need a temporary workaround for, but that's hardly a rewrite.
 
Yeap! This article is way off course. Develop properly and you'll be able to use your code for long times to come.
Bare in mind that big corporations is still using XP and SQL 2000. They'll only upgrade every 2nd or 3rd release of new software anyway.
 
Agree with the above. This article is full of crap. If you are building an ERP, the OS should have very little to do with the applications that run off of it. If it does, you've made some big errors. We have software running on XP, vista, server 2003 and 2008 and win7. All with the same code base... all running just fine. If you've been building custom code that relies on a special feature of IE6 (for example)... then naturally you've been an idiot, and deserve all the pain you get. Same with OS's.

If anything, the new OS's are rolling out too slowly. Where's Windows 8 already!
 
Were the article to be accurate, then the argument would equally apply to Apple, Microsoft etc, all of whom have a far greater investment in development effort.
 
double_n said:
I don't agree with this article at all. If huge blocks of code need to be re-written for every new version of Windows/SQL server then there's a much more fundamental problem with the way this company develops software. If one uses platforms such as .NET you can be almost guaranteed your software will work on any OS supporting the version of .NET you coded your application in. We have very little problems with software coded many years ago in .NET (and even MFC) for WinXP/2000 when running them on Win7 64bit. And when it comes to tools such as SQL, proper software design should make any changes a minor problem.
Click to expand...




I believe this is more the problem they are experiencing:

In order to optimise these for client usage, third party developers are forced to commit thousands of man hours towards recoding enterprise systems and plugins in order to offer the basic functionality of the updated software.
Click to expand...

Because of the frequency of updates, not everyone upgrades to the latest versions as soon as they are released

Client A is running software version 10.2.5
B has software version 10.3.7
C has software version 10.4.8 beta

with each upgrade comes a handful of new features. Of course everyone wants to be bleeding edge so the company adds/is forced to add the new functionality to their code.

It then becomes a bit of a battle to create patches to implement the changes, as well as keep track of who is able to run those patches and who cannot.

of course the solution would be to keep your own release cycle, as far as possible. We support and work with version 10.2 and will do so for a year, no matter how many wonderful features come out between now and then.
then in a years time we will move over to 11.8 etc.
 
Last edited:
ave said:
I believe this is more the problem they are experiencing:



Because of the frequency of updates, not everyone upgrades to the latest versions as soon as they are released

Client A is running software version 10.2.5
B has software version 10.3.7
C has software version 10.4.8 beta

with each upgrade comes a handful of new features. Of course everyone wants to be bleeding edge so the company adds/is forced to add the new functionality to their code.

It then becomes a bit of a battle to create patches to implement the changes, as well as keep track of who is able to run those patches and who cannot.

of course the solution would be to keep your own release cycle, as far as possible. We support and work with version 10.2 and will do so for a year, no matter how many wonderful features come out between now and then.
then in a years time we will move over to 11.8 etc.
Click to expand...

Yes... but that's more to do with software written by the vendor... in which case I agree with you 100%.

The argument in the article: "The reality is that each iteration of an operating system, word processing tool, or server management mainframe requires the continued efforts of third party developers to keep up with the pace. Every time a major developer releases a new version of its software, third party developers for niche sectors are forced to commit considerable resources to rewriting code which accommodates this."

For OS's, I do not see how this should be the case. For SQL Server also, I do not see this being a huge deal as they are for the most part backwards compatible, while allowing for new features (Spatial Extensions for example, which is old already). As for Word and Excel etc, that I have no experience in, but fail to see how that affects an ERP.

For the record, server management software is where I have to agree with the article. Anything that has to be intimately linked to the OS will be cause for concern. In an ERP however, I would imagine that you would be using your own security frameworks and the like, and only interfacing with tools like active directory for a small portion of the system.'

Do people really use that much of the OS that upgrading is difficult? Am I missing something here?
 
“There have been sixteen versions of Windows and SQL released in the last four years alone and our software has to support all of them. Eventually, as a third party developer, we are forced to encourage clients to purchase new software because eventually we cannot support every new addition”.
Click to expand...

It would appear that Mr Phillip's software is experiencing the problems, not the entire market ... :)

It would also appear that he hasn't heard of version control ... :) :)

I am not sure that I wouldn't be terribly reluctant to be one of his clients ... :D
 
rrh said:
It would appear that Mr Phillip's software is experiencing the problems, not the entire market ... :)

It would also appear that he hasn't heard of version control ... :) :)

I am not sure that I wouldn't be terribly reluctant to be one of his clients ... :D
Click to expand...

But don't you know that MY problem pertains to EVERYONE on the WHOLE interwb? :D :D
 
Can we down-vote this "article" as a piss poor example of writing? Changing from VB6 to C#/VB.Net must have been a very very scary experience for these guys
 
PsyWulf said:
Can we down-vote this "article" as a piss poor example of writing? Changing from VB6 to C#/VB.Net must have been a very very scary experience for these guys
Click to expand...

to be fair, I wouldn't say that the actual writing is bad at all, just wrong :P
 
I'm a Microsoft developer, this is an absolute load of bull.

sixteen versions of Windows and SQL released in the last four years alone
Click to expand...
WTF? Would love to see the list.
 
Shred said:
I'm a Microsoft developer, this is an absolute load of bull.

WTF? Would love to see the list.
Click to expand...

Pro,Starter,Enterprise,Datacenter etc seems to count as entirely disparate software versions
 
Shred said:
I'm a Microsoft developer, this is an absolute load of bull.

WTF? Would love to see the list.
Click to expand...

They are probably counting variants:

Like Windows 7 comes in "Home", "Ultimate K", "Ultimate N", "ultra awesome", "semi basic", "for noobs"
Sql Server "Developer", "Standard", "Enterprise", "Really Scary super duper version", "Lite", "Very Very Lite", "Random Build 3125" etc

EDIT: Psy beat me to it.
 
double_n said:
I don't agree with this article at all. If huge blocks of code need to be re-written for every new version of Windows/SQL server then there's a much more fundamental problem with the way this company develops software. If one uses platforms such as .NET you can be almost guaranteed your software will work on any OS supporting the version of .NET you coded your application in. We have very little problems with software coded many years ago in .NET (and even MFC) for WinXP/2000 when running them on Win7 64bit. And when it comes to tools such as SQL, proper software design should make any changes a minor problem.
Click to expand...

+1. The writer of the article obviously never developed using the latest .Net platform or ever heard the term: "Backward compatibility". Maybe he should read up on the new Silverlight technology which can run in or out of browser (like any Windows Forms app) on any version of Windows or SQL. Honestly, if you don't do MS development every day using a platform like Visual Studio 2010, please do not write articles like this.
 
Last edited:
Sounds like Idu has some serious issues to iron out.

Perhaps they've been trying to code in assembler for way too long...
Maybe their products are at fault here and in need of a major rewrite because it's been dragged along kicking and screaming with only years of workaround fixes and no proper updates?
 
Last edited:
I agree. If you did regular maintenance and made sure the code base was future proof, well maintained and commented in a proper way, catering for all these 'versions', with whatever minor differences they might have, would not have been such a big issue. I can see however that this can be a pain for the support team trying to pinpoint every new anomaly in the system and then for the developers to setup a similar environment and track and trace the issue to fix.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X