There is much joy in programming. There is joy in analyzing a problem, breaking it down into pieces, formulating a solution, mapping out a strategy, approaching it from different directions, and crafting the code. There is very much joy in seeing the program run for the first time, and then more joy in eagerly diving back into the code to make it better and faster.
There is also often joy in hunting down bugs, in ensuring that the program runs smoothly and pre-dictably. Few occasions are quite as joyful as finally identifying a particularly recalcitrant bug and defin-itively stamping it out.
There is even joy in realizing that the original approach you took is not quite the best. Many devel-opers discover that they’ve learned a lot while writing a program, including that there’s a better way to structure the code. Sometimes, a partial or even a total rewrite can result in a much better application, or simply one that is structurally more coherent and easier to maintain. The process is like standing on one’s own shoulders, and there is much joy in attaining that perspective and knowledge.
However, not all aspects of programming are quite so joyful. One of the nastier programming jobs is taking a working program and rewriting it in an entirely different programming language or porting it to another operating system with an entirely different application programming interface (API).
A job like that can be a real grind. Yet, such a rewrite may very well be necessary: an application that’s been so popular on the iPhone might be even more popular on Android devices, and there’s only one way to find out.
But here’s the problem: As you’re going through the original source code and moving it to the new platform, do you maintain the same program structure so that the two versions exist in parallel? Or do you try to make improvements and enhancements?
The temptation, of course, is to entirely rethink the application and make the new version better. But the further the two versions drift apart, the harder they will be to maintain in the future.
For this reason, a sense of dread pervades the forking of one application into two. With each line of code that you write, you realize that all the future maintenance work, all the future revisions and en-hancements, have become two jobs rather than one.
This is not a new problem. For over half a century, developers have craved the ability to write a sin-gle program that runs on multiple machines. This is one of the reasons that high-level languages were invented in the first place, and this is why the concept of “cross-platform development” continues to exert such a powerful allure for programmers.
I hope I have helped in something. Until the next opportunity!