When programmers change their tune

When programmers change their tune

Summary: In past blog posts regarding the difficulties inherent in crossing programming domains (Unix to Windows, say), some claimed that programming is universal, and any decent programmer should be able to cross development boundaries as easily as crossing the street. If they can't then they are stupid and should be fired (someone did claim that).

SHARE:
TOPICS: Windows
10

In past blog posts regarding the difficulties inherent in crossing programming domains (Unix to Windows, say), some claimed that programming is universal, and any decent programmer should be able to cross development boundaries as easily as crossing the street. If they can't then they are stupid and should be fired (someone did claim that).

That's silly, and it should be immediately obvious to anyone who has programmed for any period of time, whether or not they are on the open source or Microsoft side of the debate. However, seeing why it's silly can be difficult, trapped as we are behind our respective trenches, so the best way see the way clear is to use an analogy.

When I used my cake analogy in response to an article written by Richard Stallman, someone declared that Richard Stallman would rarely use analogies because they are intellectually lazy. Fine. But, in my opinion, analogies do frame the discussion in such a way that you see the same thing from a different angle, and that can be useful in better understanding the problem.

Consider musicians. Joe Keyboard is an expert at piano. He is really good at it, and starts to sell a slew of albums based on his ability to play piano. He has friends, though, who tells him that he should get into guitar playing, as guitar players have more screaming fans.

Joe Keyboard is musical, and reading and writing music is important in both piano playing and guitar playing. That doesn't mean, though, that he can just waltz into a bar, pick up a guitar and play like he's Eddie Van Halen. It takes time to learn guitar, just as it takes time to learn to play piano. He chose to concentrate on piano, and he became very good at it. That doesn't mean he can turn around and start playing guitar.

Expertise takes time to acquire. If you are an expert in Linux, you will not spontaneously be an expert in Windows, and vice versa. That's the reality of our industry. People must specialize if they hope to reach a certain level of facility, and that's why it's so hard to decide to pick up stakes and move from the Windows world to the Linux world.

So, I still think that the only way Linux is going to pose any threat to Windows is if they decide to co-opt more Windows technology. It's not enough to say "Qt and GTK are cross platform." Windows developers don't use Qt and GTK (or Java for that matter), so trumpeting their ability to write Windows programs is a non-argument. On the other hand, Windows developers do use .NET, so that seems a better way to attract them than trumpeting the merits of a competing API.

But that's just My Opinion.

Topic: Windows

John Carroll

About John Carroll

John Carroll has delivered his opinion on ZDNet since the last millennium. Since May 2008, he is no longer a Microsoft employee. He is currently working at a unified messaging-related startup.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

10 comments
Log in or register to join the discussion
  • Who said they had to be experts?

    No one claimed they should instantly know everything there is to know about another OS. But they should be able to switch and get "up to speed" in a relatively short time. As you said, expertise takes time. But if you are already a programmer in another language or OS, you have a head start on learning another language or OS. You can use knowledge gained from one and apply it to another.
    Patrick Jones
    • It is more than just work: it is economics

      There has been relative consistency in the development of tools within different islands of development on the Windows platform. Within VB, Access, C++, and so on. A lot of what .Net and Longhorn are doing, is bringing consistency and coherency across all these different islands of development, so that e.g. developing a help system, will not be that much different from developing a web service, or a client or web application. .Net already does a lot of this, by enabling developers to develop client applications, web applications, and web services very similarly. All of this will (and already does) significantly improve the productivity of Windows developers, since they are able to leverage their skills across application domains, as well as different Windows platforms (e.g. Windows client OSs, Windows Server OSs, and Windows CE).

      John Carroll is correct in saying that the burden crossing OSs when developing software deters Windows developers from crossing over to Linux. Sure, it?s mostly a matter of additional work that Windows developers have to endure, when making the transition, but this additional work is significant. What financial incentive does a Windows developer have to step out of e.g. .Net development when he can create a wide variety of applications in a relatively short period of time, for by far the largest application platform, using the MS development system? The burden John Carroll talks about is not just an intellectual burden, it is an economic one as well. Also, why should a Windows developer develop software for a platform, whose associated movement has a propensity to make ever increasing wider categories of software free? In other words, why would a Windows developer place his development efforts in financial jeopardy by embracing a platform that has a tendency to make more software which he develops, free?

      MS recognizes with developers, it is all about allowing them to enjoy the best returns on their development efforts. However with Linux and the OSS movement, it is much less about this, and more about developing software that people can freely use. This is a fundamental reason why Windows developers are more than a little suspicious about developing for Linux, and within the OSS movement. And this is one of the major obstacles for Windows developers who might consider crossing over to Linux.
      P. Douglas
      • Who mentioned economics?

        Not John and not me. This is about ability, per his analogy.

        Yes, there may not currently be much financial incentive to port a program to Linux, but that is more because of user base than the possibility of the program becomming free. I whole-heartily agree that it isn't in their best interest, right now. And yes, they can create more applications in a smaller time using what they know. I have first-hand experience with how a really knowledgable Windows programmer can whip something out in 10 minutes that took me 45 minutes.

        Do we really need to list all the companies that Microsoft has co-opted their software and included it in Windows, thus making their product free?
        Patrick Jones
        • Re: Who mentioned economics?

          [i]Who mentioned economics?
          Not John and not me. This is about ability, per his analogy.[/i]

          John's article is about the time and work needed for Windows developers to adjust to developing for Linux. However, this time and work penalty a Windows developer faces, has economic (as well as intellectual) consequences. That is what I meant.

          [i]Do we really need to list all the companies that Microsoft has co-opted their software and included it in Windows, thus making their product free?[/i]

          The software MS has rolled into Windows have been primarily utilities. Also, MS many times makes it a point to have only basic functionality in the utility software it includes in Windows, so as to ease the burden on utility software vendors. (This is one of the reasons people say several applications that come with Macintosh computers, are better than their Windows counterparts.) Further, MS tends to ameliorate the situation by providing opportunities for software vendors to provide plug-ins for its various Windows utilities and applications.

          A consequence of MS? (and many other vendors such as Apple?s and even Red Hat?s) strategy of incorporating more functionality into their OSs, is that it provides ever increasing value to the OS platforms, which helps the platforms to expand, which overall increases financial opportunities for software vendors. Therefore MS incorporating into Windows, functionality found in utilities, causes a significant net financial expansion of the Windows software market, which is overall better for everyone. Contrast this to the introduction of OSS software into various markets (e.g. Linux into Unix, Apache into web server), which tends to drive money out of those markets. Therefore the main difference between MS incorporating utility functions into Windows, and the OSS movement?s efforts to make more and more software free, is that MS? effort leads to an overall significant expansion of financial opportunities in the Windows market, while the OSS movement?s effort leads to (at the very least) less expansion of financial opportunities in the OSS market.
          P. Douglas
  • VBS,Jscript,Java,VBS.NET-What consistancy?

    John, I wish you had made this obvious concept known to Microsoft a decade ago.

    Consider the number of MAJOR enterprise API overhauls that Microsoft has presented to in-house developers to interface with each new major release of Microsoft Office, Access and client side Internet Explorer.

    Microsoft is now dropping support for the still widely deployed VB6, dispite the desperate pleas of developers...
    http://classicvb.org/

    Read Joel's [i]How Microsoft Lost the API War[/i]
    http://www.joelonsoftware.com/articles/APIWar.html

    And don't make the claim that after the move to .NET is going to improve that situation, because Microsoft is going to introduce yet another major paradigm shift with Avalon.

    Client side development on the Microsoft platform has become a decade long [i]Vendor Dependent Death March[/i].

    If developers have to retrain, why should they not move to a platform where they have the power to dictate at what pace they deploy new APIs.

    [b]READ[/b]:"[i]Vendor Dependent Death Marches VS Open Kaizen[/i]"
    http://slashdot.org/comments.pl?sid=137803&cid=11526222
    David Mohring
    • The Law of Intended Consequences

      [i]Client side development on the Microsoft platform has become a decade long Vendor Dependent Death March.[/i]

      The Law of Intended Consequences (not to be confused with the Law of Unintended Consequences) is that when a rational entity does something that can reasonably be expected to result in some consequence, it's a good bet that that consequence was intended. For instance, if a retailer adds a store a short distance from another store of theirs, they intend for the first store to lose some business (which reduces crowding, etc. -- it can be a good thing.)

      Well, Microsoft has been changing their APIs for a long time. There have been a lot of [b]official[/b] changes, but there have been even more [b]unofficial[/b] changes due to version-specific discrepancies etc. The result is that application developers have been continually stressed just keeping up, as you point out.

      Interestingly, this [i]could[/i] be seen as beneficial to Microsoft, in that application developers don't have time to do anything [u]but[/u] keep up with Microsoft. As a result we get columns like John's, where he sees the Microsoft APIs as a job in themselves -- he's so invested that being a Microsoft follower has defined his identity. Now multiply by millions.

      The fact that they don't have bandwidth to program for other platforms probably doesn't cause Bill Gates to lose any sleep either. Was this intentional on Microsoft's part? No way for us to know for certain. I refer you to the title of this post.
      Yagotta B. Kidding
  • The piano analogy is weak

    To go from guitar to piano is not very hard. The staff is the same. Going from piano to guitar is not very hard musically.. Thats why so many guitarists play piano and vice versa. In fact they can play the same roll in a band.

    To make a better analogy would be to say that the pianist isnt a pianist but a keyboardist and went form playing a moog to a Korg or roland and had to learn how to reprogram the samples.
    icorson1
    • Maybe the analogy is good after all

      [i]To go from guitar to piano is not very hard. The staff is the same. Going from piano to guitar is not very hard musically.. Thats why so many guitarists play piano and vice versa. In fact they can play the same roll in a band.[/i]

      Like Eric Clapton? Most of the really great guitarists actually learned classical piano as children. I gather that John isn't a musician.

      However, there are differences. I'm reliably told that experts can tell the difference between a piece that was composed on piano and played on a guitar and one that was composed originally on guitar. Apparently, the ones composed on piano have a "cleaner design" -- they're focussed more on the music and less on the mechanics of playing. Apply the analogy as you see fit.
      Yagotta B. Kidding
  • Expert in OS/2

    If Jose is an expert in OS/2, it implies that his main role is working with the nuts and bolts of OS/2. Nothing wrong with that, unless his deliverables are primarily an accounting package. If his output is supposed to be accounting packages and his efforts are primarily in nuts-and-bolts OS/2 [b]something[/b] is wrong.

    It may not be Jose. It could be that Jose's employer, or predecessors, or senior design, or whoever, have done such a lousy job of designing the accounting package that the programming staff have to spend their time hacking OS/2. Fair enough -- but that means that in the end Jose is going to be looking for a job, because that accounting package doesn't have a future against others that are better designed.

    When the day comes that Jose is out on the street looking for a job, he'd better have something to offer besides "I can hack OS/2 so that badly-designed accounting packages can hobble along."
    Yagotta B. Kidding
  • Is Mono close enough to "Windows" technology to qualify?

    [i]So, I still think that the only way Linux is going to pose any threat to Windows is if they decide to co-opt more Windows technology.[/i]

    I think the way you're going with that line is that Linux needs to attract people who are already Windows developers. Well let me throw this out there, because not being a programmer I'm sort of in the dark: Is Mono (or perhaps DotGNU) close enough to .Net to qualify? I know it's a work in progress (not vaporware, but not all projected features are implimented yet) but should they achieve their end goals would that be enough to attract Windows developers? Or is the style of programming still oriented for the UNIX programmers rather than Windows programmers?

    (I know GTK# is out there, but they way I thought Mono worked, or .Net for that matter, was that the programmer can use whatever language he likes so long as there is a Mono implementation, and Mono would would take care of the rest. So, unless I'm wrong, all Windows programmers would need is a Mono ported language similar enough to what they are used to and they'd be covered, whereas the GTK folk would use GTK#. Again, someone correct me if I'm reading into the situation wrong.)

    The reason I ask is because if Mono does achieve its goals and it catches on a bit, it would have all the positives QT and GTK would have as far as portibility, plus (assuming it is close enough to .Net) it may attract Windows developers.
    Michael Kelly