none
How do you think Microsoft manages its products RRS feed

  • Question

  • Hello All,

    I was wondering how Microsoft manages its tools, for example let us consider "word". We know that this has been around for long time now and was most likely developed in C++, so you think Microsoft is still developing latest versions of word in C++ if not how do you think they did manage to migrate to a new environment.

    Or in other words how do you think one can use latest technologies for age tools which were designed and developed in primitive languages and not designed for latest technologies.

    I know of course one way would be to srap the whole and develop from scratch but sure enough requires lots of effort.

    Thanks

    Wednesday, April 7, 2010 8:48 AM

Answers

  • I'm not convinced about that either.

    If a product grows and grows almost uncontrollably then you can find that the overall design is full of compromises and fixes.  There can come a point where nobody understand how swathes of it really work.  These are good reasons for a rewrite.

    If, on the other hand, the product is carefully designed and split up into understandable chunks of some sort then that's a different case entirely.

    Similarly you might find that a rewrite is required for some other reason.  Like you have a windows application designed for windows 3.11 using controls you bought off some vendor long went out of business and you need it to work on macs via the web.  When your boss brings you in the office to discuss this change is when you explain that z86 assembler ain't going to work.

    Incidentally.  My friend didn't sit writing assembler pushes and pokes all the time.  He had a library of routines did all the low level stuff and most of the code he would write looked like some sort of an odd 3GL since it was all function and subroutine calls.  A bit like classic ASP really.  If you start from scratch then writing a classic asp based page is a nightmare.  I have talked to people still prefer classic asp over asp.net because they have all their libraries sorted out and they still have the low level control.

    • Marked as answer by RadiumBall Friday, April 9, 2010 12:38 PM
    Wednesday, April 7, 2010 2:08 PM
  • Although I do all my new work in C#, I still maintain a few old C++ programs for clients.

    If they work, there is little reason to change. C++ is still a mainstream language with many devoted programmers. If the program consistently needs new functionality, then changing platforms becomes feasable. In many cases, the old software has been poorly maintained (i.e., new features are hacked on instead of modifying the architecture design to accommodate them), and the original architecture has not held up well; this makes fixing bugs and adding functionality increasingly difficult.

    One approach that I have done on some small-scale projects is based in unit testing: if you can create unit tests for the existing functionality, then they act as a sort of functional documentation. When this is complete, you have a starting point for defining what the program actually does.

           -Steve


    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ
      and How to Implement IDisposable and Finalizers: 3 Easy Rules
    Microsoft Certified Professional Developer

    How to get to Heaven according to the Bible
    • Marked as answer by RadiumBall Friday, April 9, 2010 12:38 PM
    Wednesday, April 7, 2010 5:36 PM

All replies

  • I know that visual studio has recently been rewritten using WPF, no idea about word.

    I'm not convinced that "primitive" languages are a bad thing.  Whatever you write in a higher language is still bits and bytes at the end of the day.

    Some years back I knew someone who was a games developer and an assembler expert.  He wrote a system designed for a particular type of business.  Hairdressers I think.

    At that time I was using vb and access and these are higher level, newer.

    His system looked really cool.  Great graphics, highly responsive, controlled till opening and all sorts of clever stuff.

    Newer isn't neceessarilly better. 

    Wednesday, April 7, 2010 9:34 AM
  • Oh yeah I fully agree with you that newer isn't necessarilly better, but are surely more reliable, easier to use and maintain.
    Wednesday, April 7, 2010 1:10 PM
  • I'm not convinced about that either.

    If a product grows and grows almost uncontrollably then you can find that the overall design is full of compromises and fixes.  There can come a point where nobody understand how swathes of it really work.  These are good reasons for a rewrite.

    If, on the other hand, the product is carefully designed and split up into understandable chunks of some sort then that's a different case entirely.

    Similarly you might find that a rewrite is required for some other reason.  Like you have a windows application designed for windows 3.11 using controls you bought off some vendor long went out of business and you need it to work on macs via the web.  When your boss brings you in the office to discuss this change is when you explain that z86 assembler ain't going to work.

    Incidentally.  My friend didn't sit writing assembler pushes and pokes all the time.  He had a library of routines did all the low level stuff and most of the code he would write looked like some sort of an odd 3GL since it was all function and subroutine calls.  A bit like classic ASP really.  If you start from scratch then writing a classic asp based page is a nightmare.  I have talked to people still prefer classic asp over asp.net because they have all their libraries sorted out and they still have the low level control.

    • Marked as answer by RadiumBall Friday, April 9, 2010 12:38 PM
    Wednesday, April 7, 2010 2:08 PM
  • Good points. But I think that shifting to newer technologies has this ultimate advantage of greater support and larger programmer base.

    I ask this whole question worrying about my tool which is built using C++ which seems to run fairly good but often shows its ugly face in the form of sluggish performance, memory leaks/wasteful memory consumption leading to crashs. Athough it does have a good enough design/architechture fixing these issues could be a nightmare on existing platform. Scraping the whole thing and rebuilding could also be headache since the tool is in development from the 90's and who knows what requirements existed then and still could be in use.

    Wednesday, April 7, 2010 5:16 PM
  • Although I do all my new work in C#, I still maintain a few old C++ programs for clients.

    If they work, there is little reason to change. C++ is still a mainstream language with many devoted programmers. If the program consistently needs new functionality, then changing platforms becomes feasable. In many cases, the old software has been poorly maintained (i.e., new features are hacked on instead of modifying the architecture design to accommodate them), and the original architecture has not held up well; this makes fixing bugs and adding functionality increasingly difficult.

    One approach that I have done on some small-scale projects is based in unit testing: if you can create unit tests for the existing functionality, then they act as a sort of functional documentation. When this is complete, you have a starting point for defining what the program actually does.

           -Steve


    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ
      and How to Implement IDisposable and Finalizers: 3 Easy Rules
    Microsoft Certified Professional Developer

    How to get to Heaven according to the Bible
    • Marked as answer by RadiumBall Friday, April 9, 2010 12:38 PM
    Wednesday, April 7, 2010 5:36 PM