Software Porting Is Evil?

September 27, 2005 by
Filed under: Uncategorized 

Tom Yager wrote a piece in the September 19th issue of InfoWorld that was titled “Software Porting Is Evil” – just the heading was enough to wind me up! [The article isn't on the InfoWorld site yet, as far as I can see.]

I was responsible for a porting team back in 1992-94; the objective was to have Hewlett-Packard‘s X.400 email server “OpenMail” running on 20+ UNIX platforms concurrently. Yes, it was like spinning plates at times – take your eye off one plate/platform for a minute and it could come crashing down – but after a short while we had a pretty stable basis that meant the addition of a new platform was achievable quite quickly.

So when someone says that something I spent two years doing (and it would have been more if the company hadn’t been bought out and almost everyone laid off) is “evil”, obviously it causes me to sit up. Fortunately I read more than just the first few lines of his article, because some of the points he made I actually agree with:

  • commercial software vendors are “lazy about re-targeting their code”
  • “there are far too many fat client applications”
  • “developers … become addicted to methods that exist only with the OS and tools they used to write their code”

Taking these points in order: it’s obvious that many vendors are lazy about porting their code – unless you’re running the latest version of Windows, there’s a good chance you’ve said “if only it ran on [your platform]“. Equally, if you’re on an old version of Windows there are lots of applications that only run on the “latest and greatest”. There are many neat Mac-only applications too that I, as a primarily Linux user, would like to see ported.

Of course this is a catch-22 situation: vendors will only port their products if there is enough demand, which means only the popular platforms stand any chance, but how can a platform become popular if there isn’t the breadth and depth of applications available to attract users? I can see how Open Source developers will migrate their code because of interest, the technical challenge, the chance to play with something new, etc. but Yager’s point was about commercial vendors; unless there’s a good business case to do so, they will not (and should not) spend time & money porting their applications.

Often the only solution is for a customer to pay the vendor to port their application to their favourite platform; the customer should make sure they get some sort of profit-sharing element written into the contract though, so they can share in the benefits reaped from producing something other people want.

To a user there is little noticeable difference between a fat client and a thin client – in fact I suspect most don’t even know what those terms mean, nor do they care, so the requirement for greater emphasis on thin client design must come from the technical community. Unfortunately many developers follow Microsoft’s lead, and that is not going to take us down the right path; as hardware continues to advance, many developers fail to see the need for their applications to perform well – if it’s a bit slow, just throw more memory at it.

Universities and schools also have to shoulder some of the blame – if you teach our future-programmers that it’s OK to hack everything out in Visual BASIC then that’s how they will see all software development. Even though there was no technical need for it, one of the courses I took at university insisted that we write our programs on coding sheets, submit them, pick up the punch cards, submit the job, and then wait a day or two to collect the output. The painfully slow turnaround made everyone think about how they designed their code, how they handle non-critical errors, and how to extract the most information for debugging. I’m sure that everyone came away from that course a better developer because we had to think, to plan, to design and to code carefully. Nowadays it’s simply a matter of sitting in front of a screen, banging away at the keyboard until it appears to work.

If the tools that they are provided with focus on the GUI, then that’s where people will concentrate their efforts – does it matter if the back end is inefficient if it looks pretty? Instead of making it work better, just throw up a progress bar.

How many applications on your Windows PC are truly client-server? Very few, I bet. Even those few probably began life as a fat client and evolved. The same is true for the PC – it was a personal computer long before it was networked with its peers and eventually to servers, so it’s no surprise many applications still run in that manner. UNIX started life as the server end with users connected via dumb terminals – everything was focused on the back end with rudimentary user interfaces. There needs to be a hybrid – fast, efficient, robust server software with a user-friendly GUI; it can (and has) been done successfully.

Unless software designers and developers adopt the client-server approach, we are doomed to forever update our PCs while the servers gather dust.

The third point was that developers become addicted to OS-specific tools; unless they are made to think of the bigger picture, developers naturally think about solving the problem they’re given, ideally with the minimum of effort, and then they move on – little (if any) thought is given to maintenance, let alone portability.

Of course it’s not fair to blame just the developers for this problem – almost everyone involved in the development project shares the responsibility. The managers and designers should be thinking beyond just churning out a solution; they should be considering the long-term future of the product: How can it provide future revenue? (Enhancements; wider platform support…) How can we minimise ongoing support costs? (Make it simpler to fix!) How can we re-use elements of this project elsewhere? The answer to many of the questions that should be asked relies on modular, well-designed, portable, well-documented code. Just because you can’t see another use for a particular module now, if you design & develop it correctly then, when you do discover a need in a few years, it will be there, ready to use, even if the programmers are long gone.

By having the entire development team think about the future, the coders will have to use tools that don’t tie the product to a particular operating system or to other products. They will have to code to open standards (e.g. the X/Open Common Applications Environment Portability Guide), to corporate standards (e.g. naming conventions), and against well-documented Application Programming Interfaces. The product’s internal APIs will provide a level of plug-and-play if a module needs to be added or modified, and of course will make testing more efficient.

Initially the accountants will see that developing in this way is more expensive than the current method, but they should also see the savings in the maintenance phase and future projects which benefit from these good practices.

Yager ends his piece by saying “If a vendor makes application porting and validation painful, it won’t lock developers in. It’ll get the vendor locked out.” I think he’s right on the mark … assuming customers see the benefits. Unfortunately, while Microsoft continue with their monopolistic and anti-competitive practices, and other companies see how successful MS are, there will be the temptation to continue the “lock them in” mentality.

Of course, if we all toe the Microsoft-only line that so many companies have, then we’re just feeding the monster – why do we need to port applications if there’s only one platform?

Tags: ,

Comments

One Comment on Software Porting Is Evil?

  1. andysoft on Tue, 27th Sep 2005 8:59 pm

    2. This is why I hate microsoft VB, a lot of people never even bothered with anything else and they think they know everything about coding while they drag and drop textboxes around. While RAD tools are nice to have, beyond prototyping they are not so great usually. It’s kinda like building a house, you can either have it done fast or well. Good old times when we counted cycles for each ASM instruction to see if we can cut a couple of ticks here and there, while that’s another extreme, it teaches you a lesson that efficient coding pays off in the long run.