Legacy code is any code that a software developer "inherits". i.e., the developer didn't write the code, but is in charge of maintaining it.
TDD is also called analysis. It forces the developer to think about the requirements and how to verify the implementation meets the requirements. Unfortunately, this is bad testing, because the goal of software testing is to verify that the software is incorrect. This is why it has been well documented that someone other than the developer should write and execute the tests. It's hard for the developer to take off the white hat and put on the black hat.
Choosing Windows is already an indicator of lower intelligence. Using Windows OTOH is an unfortunate consequence, for most PC users, of Microsoft's anti-competitive monopoly practices.
Interesting. I can see the table in my VAC++ help files as well.
This is all rather off-topic to the reason I responded to your post in the first place.
The poster you responded to stated, "Just imagine what would have happenend if IBM had decided to put a proper fight in the desktop war. We would have a far more advanced OS by now."
To which you replied, "Actually sadly we'd just have Vista, the replacement for OS/2 XP."
My response was, "OS/2 and NT are two totally different operating systems."
Everything else we've posted has not contradicted my response or shown your original statement to be true. You have demonstrated some familiarity with OS/2, which makes your original response even more puzzling.
Yes, "a total rewrite", or more accurately a 32-bit replacement that was meant to retain some compatibility with 16-bit OS/2 APIs. It also included compatibility for POSIX APIs, so why don't we call it POSIX XP?
16-bit Presentation Manager might have run on NT, but I seriously doubt anyone ever tried to port 32-bit PM to NT. 32-bit PM was solely written by IBM, and neither IBM or Microsoft had a reason to port it. Microsoft wanted the Win 3.x user interface to be the look and feel of Windows, and IBM wanted OS/2 to become the market leader. (well... some of IBM did.)
The APIs had common ground, because they were originally developed jointly. They quickly diverged, especially as Microsoft wanted to break OS/2's Win 3.x compatibility subsystem.
The Design of OS/2 by Dietel and Kogan provides history of the split and is also good reading on OS design.
Reimmersion time is actually 15 minutes in the Peopleware (DeMarco and Lister) quoted studies. This applies to all interruptions, email notifications, phone calls, IM, co-workers/bosses, etc. What I found funny about the article was that it was advocating technologies like IM as somehow being less intrusive. It was also concentrating on people consciously checking email rather than actually being interrupted by it, which means they probably weren't being too productive in the first place.
Well, the information on wikipedia is subject to the competence of the provider. IBM has absolutely nothing to do with the development of eComStation. The only participation IBM has is in providing bug fixes based on the level of support contract that Serenity has for OS/2.
eComStation isn't an operating system; it is a distribution of OS/2, like Redhat, Ubuntu, or Debian for Linux. The OS/2 kernel, PM shell, and many other parts are still closed source belonging to IBM, and as far as I've heard, IBM doesn't want to make the source available even under a development contract, where Serenity could create a branch of (for example) the kernel.
You can't put the money into OS development on OS/2 when you don't have access to the source code.
Resources are being put into putting the OS/2 GUI onto another OS, ala Mac OSX. Wasted effort in my opinion, because it won't perform as well. Another effort is to try to recreate OS/2 from scratch.
OS/2 and NT are two totally different operating systems. Microsoft retained some OS/2 compatibility in NT, because they had previously sold OS/2 to their customers and wanted to try to move them to NT.
Of course, you aren't alone in showing your ignorance. The majority of the posters don't have a freaking clue as to what they are talking about, but then again this is Slashdot.
The eComStation owners don't own the source code; they just license the binaries from IBM for resale. If they had access to the source code, then they would be upgrading and maintaining it.
> "I'm no Microsoft fanboy or anything, but"...... I just LOVE everything they've done! %-6
You'd have a little more credibility if you'd gush less over all their other products and state what Silverlight has done better than it's competition.
This isn't unique to IBM. A number of large corporations in the USA try to mandate innovation by placing intellectual property production requirements on their employees. This never results in more valid IP, just more work for corporate legal. The real way to increase valid IP production is to build enough slack time into your schedules to give employees enough time to explore alternative methods.
As far as being a clever way of fighting patents, I think you are giving IBM's (or any other corporations) management too much credit. This falls under the same category as mandating 60 hour work weeks and expecting an increase in quality production output. It is the "whip them harder" fantasy that management can't ever seem to learn will only lead to failure.
The technical lead can let the user of the PC drive. Most of the time this is the best idea so the owner of the PC learns more and actually pays attention to what the lead is taking them through but sometimes this is not possible when the lead is seriously overworked. In my experience technical leads often are. Sounds like your experiences have been environments where code is valued over documentation and heroic efforts are considered cause for praise. It also sounds like the technical lead is surrounded by less capable personnel or inexperience quite often. I would not want to work in such a place, but I have also found that sometimes technical leads try to promote such an environment.
This completely ignores that editors can also come with script engines to allow users to greatly enhance their own productivity. Changing editors can often cause the loss of many other valuable tools. This had not occurred to me but it is also one more reason why teams should standardise on a single IDE. There is no duplicated effort of creating these tools for different editors since more than one person on the team will probably have a need to do similar tasks. If these tools are so valuable why develop them twice? Exactly my point.;-) The new developer may be bringing in things that he/she has found to be more productive that might not exist in the new company or be possible on the standardized IDE.
Now we're going to rule out the possibility of improvement and elevate the lead to prima donna status?!? Sorry, you seem to have completely misunderstood my point. I was saying that when a new developer joins a team he will initially be fairly unproductive compared to other more established members. This is not ruling out improvement, this saying that they will improve with time, but that time has not passed yet. You misunderstood my point on improvement. I'm saying the new developer can bring the improvements. Of course if the technical lead has carefully constructed a mantle of godhood, then a new developer bringing improvements will be cause for alarm.
In regard to the lead having prima donna status I have no idea where that came from, It is possible to hire someone with domain knowledge and experience. Granted, there will be some learning curve, but it might be very small.
You also mentioned that I ignored all data on software productivity. Can you post a link or provide any more information on this data you are talking about? I presume it was from some sort of recent workplace study so I am genuinely curious to the methodology used. I am referring to the studies that have shown a 10x to 20x difference in software developer productivity. You really don't want to drive away the top developers, and editors are often a religious subject. These aren't recent studies. You can find data in Peopleware by DeMarco and Lister or The Mythical Man-Month by Brooks. If you haven't read those, I highly recommend them.
Why would one force a developer to use a specific editor? The main reason I can think of from the top of my head it if the technical lead needs to show you something quickly on your PC. The technical lead can let the user of the PC drive.
If you have a team of 15 developers who all use different IDE's it can get very difficult to see errors in code if the syntax highlighting is different for each since pattern recognition is often an important part of debugging. Then review the code with the editor you are comfortable with.
Another reason may be that the different editors deal with a mix of windows / unix carriages returns differently. Almost all editors allow this to be configurable.
The programmer is more productive with an editor (s)he is familiar with. Only for a few weeks. In a few weeks doing full time development you should be able to learn you way round any editor. This minor drop in productivity for a few weeks can be made up in no time in productivity gains by the team as a whole. This completely ignores that editors can also come with script engines to allow users to greatly enhance their own productivity. Changing editors can often cause the loss of many other valuable tools.
New staff should always be forced to use the same IDE as the lead developer. Partly so to make the leads job easier as his time is far more valuable and new staff are not expected to be very productive initially anyway. Now we're going to rule out the possibility of improvement and elevate the lead to prima donna status?!?
If the are truly unique in their skills set then they probably work at Google already. ... and insult the whole of the non-Google software developers?
The day of the antisocial programming geek ruling the market are over, most companies would rather hire less capable developers who can work well with their peers and relate to management more easily since technical skills are more easily taught than people skills. I know this is going to go down very badly with a lot of angry slashdot geeks, but you might as well learn this early in life when it is easier to change your outlook. Finally, we'll alienate the/. crowd, ignore all data on software productivity, and pretend to be an old sage (contrary to the bulk of the information posted). Are you a less capable developer or a manager trying to protect your bottom line?;-)
They need to find a way to make it less desirable for businesses to mandate IP from their employees. Many businesses make it part of an engineers yearly tasks to produce IP. This leads to a lot of (should be) unpatentable ideas being pushed into the stream.
Do your research. After the initial antitrust ruling against Microsoft's requirement to one license of Windows per processor, Microsoft tried requiring one MS Office license per processor. This was in response to competitive pressure from Lotus in the PC pre-load market.
MS has never stopped anyone from running any other office software, but they have used undocumented APIs to ensure that MS Office had a competitive advantage over other other office software. This is the kind of stuff that a monopoly position can provide an immoral company. The line from competitive advantage to immoral is unfortunately so thin that many companies cross it too often.
Read the findings of fact in the US DOJ vs. Microsoft case, and you'll find all kinds of examples of monopoly abuse.
1) Apple hasn't been found to be an abusive monopolist. 2) iPod has viable competition in the marketplace. 3) As you've already stated, there isn't any tying of (your assertion) monopoly position to usage.
#1 is the big issue here; without it, you're statement of unfairness would be true.
Err. I'm tempted to just label your post as clueless and move on. Microsoft has given up a number of rights by using anti-competitive behavior in markets where they hold a monopoly position.
You should really learn about the definition of a monopoly and how a monopoly can impact the market. We would be light years ahead in innovation if Microsoft (or some other abusive monopolist) wasn't present to stifle innovation. For example, I saw a recent quote from Bill Gates stating that speech interfaces were the future of computing. OS/2 Warp 4 had that included in it's release in 1996. It wasn't great, but consider where speech would be now if OS/2 had enough of a market share to drive active, high-visibility development.
If you believe that OS/2 failed to gain market share based on it's own merits or IBM's handling, then you need to read the findings of law from the US DOJ vs. Microsoft antitrust trial.
Microsoft having an abusive monopoly is unfair. There's nothing wrong with shipping useful functionality with your OS as long as it isn't leveraged to stifle competition. Microsoft has been judged to not be a fair player in the market.
The conclusions of law in the Microsoft antitrust trial laid out very clearly why the OS market won't change until some remedy is introduced to break Microsoft's monopoly. Unfortunately the remedy was hijacked by a change in administration.
Slashdot Mirror
Sorry, that's not true. The anti-trust finding was upheld, and only the remedy was overturned.
Legacy code is any code that a software developer "inherits". i.e., the developer didn't write the code, but is in charge of maintaining it.
TDD is also called analysis. It forces the developer to think about the requirements and how to verify the implementation meets the requirements. Unfortunately, this is bad testing, because the goal of software testing is to verify that the software is incorrect. This is why it has been well documented that someone other than the developer should write and execute the tests. It's hard for the developer to take off the white hat and put on the black hat.
Good management would have had a plan in place for maintaining the code to avoid having to throw a new person at it and expect them to be fungible.
Choosing Windows is already an indicator of lower intelligence. Using Windows OTOH is an unfortunate consequence, for most PC users, of Microsoft's anti-competitive monopoly practices.
Interesting. I can see the table in my VAC++ help files as well.
This is all rather off-topic to the reason I responded to your post in the first place.
The poster you responded to stated, "Just imagine what would have happenend if IBM had decided to put a proper fight in the desktop war. We would have a far more advanced OS by now."
To which you replied, "Actually sadly we'd just have Vista, the replacement for OS/2 XP."
My response was, "OS/2 and NT are two totally different operating systems."
Everything else we've posted has not contradicted my response or shown your original statement to be true. You have demonstrated some familiarity with OS/2, which makes your original response even more puzzling.
You should use the VER command rather than uname.
[C:\]ver
The Operating System/2 Version is 4.00.
uname ('u'nix name) isn't the supported operating system command for version information.
Yes, "a total rewrite", or more accurately a 32-bit replacement that was meant to retain some compatibility with 16-bit OS/2 APIs. It also included compatibility for POSIX APIs, so why don't we call it POSIX XP?
16-bit Presentation Manager might have run on NT, but I seriously doubt anyone ever tried to port 32-bit PM to NT. 32-bit PM was solely written by IBM, and neither IBM or Microsoft had a reason to port it. Microsoft wanted the Win 3.x user interface to be the look and feel of Windows, and IBM wanted OS/2 to become the market leader. (well... some of IBM did.)
The APIs had common ground, because they were originally developed jointly. They quickly diverged, especially as Microsoft wanted to break OS/2's Win 3.x compatibility subsystem.
The Design of OS/2 by Dietel and Kogan provides history of the split and is also good reading on OS design.
Reimmersion time is actually 15 minutes in the Peopleware (DeMarco and Lister) quoted studies. This applies to all interruptions, email notifications, phone calls, IM, co-workers/bosses, etc. What I found funny about the article was that it was advocating technologies like IM as somehow being less intrusive. It was also concentrating on people consciously checking email rather than actually being interrupted by it, which means they probably weren't being too productive in the first place.
Well, the information on wikipedia is subject to the competence of the provider. IBM has absolutely nothing to do with the development of eComStation. The only participation IBM has is in providing bug fixes based on the level of support contract that Serenity has for OS/2.
eComStation isn't an operating system; it is a distribution of OS/2, like Redhat, Ubuntu, or Debian for Linux. The OS/2 kernel, PM shell, and many other parts are still closed source belonging to IBM, and as far as I've heard, IBM doesn't want to make the source available even under a development contract, where Serenity could create a branch of (for example) the kernel.
You can't put the money into OS development on OS/2 when you don't have access to the source code.
Resources are being put into putting the OS/2 GUI onto another OS, ala Mac OSX. Wasted effort in my opinion, because it won't perform as well. Another effort is to try to recreate OS/2 from scratch.
OS/2 and NT are two totally different operating systems. Microsoft retained some OS/2 compatibility in NT, because they had previously sold OS/2 to their customers and wanted to try to move them to NT.
Of course, you aren't alone in showing your ignorance. The majority of the posters don't have a freaking clue as to what they are talking about, but then again this is Slashdot.
The eComStation owners don't own the source code; they just license the binaries from IBM for resale. If they had access to the source code, then they would be upgrading and maintaining it.
> "I'm no Microsoft fanboy or anything, but" ... ... I just LOVE everything they've done! %-6
You'd have a little more credibility if you'd gush less over all their other products and state what Silverlight has done better than it's competition.
This isn't unique to IBM. A number of large corporations in the USA try to mandate innovation by placing intellectual property production requirements on their employees. This never results in more valid IP, just more work for corporate legal. The real way to increase valid IP production is to build enough slack time into your schedules to give employees enough time to explore alternative methods.
As far as being a clever way of fighting patents, I think you are giving IBM's (or any other corporations) management too much credit. This falls under the same category as mandating 60 hour work weeks and expecting an increase in quality production output. It is the "whip them harder" fantasy that management can't ever seem to learn will only lead to failure.
Hmmm. Pretty soon all we'll need are these computers, let's call them "workstations", that have local storage for running applications faster and ...
;-)
Where have I seen this before?
Ask them if they know how to program in Executable UML.
They need to find a way to make it less desirable for businesses to mandate IP from their employees. Many businesses make it part of an engineers yearly tasks to produce IP. This leads to a lot of (should be) unpatentable ideas being pushed into the stream.
Do your research. After the initial antitrust ruling against Microsoft's requirement to one license of Windows per processor, Microsoft tried requiring one MS Office license per processor. This was in response to competitive pressure from Lotus in the PC pre-load market.
MS has never stopped anyone from running any other office software, but they have used undocumented APIs to ensure that MS Office had a competitive advantage over other other office software. This is the kind of stuff that a monopoly position can provide an immoral company. The line from competitive advantage to immoral is unfortunately so thin that many companies cross it too often.
Read the findings of fact in the US DOJ vs. Microsoft case, and you'll find all kinds of examples of monopoly abuse.
1) Apple hasn't been found to be an abusive monopolist.
2) iPod has viable competition in the marketplace.
3) As you've already stated, there isn't any tying of (your assertion) monopoly position to usage.
#1 is the big issue here; without it, you're statement of unfairness would be true.
Err. I'm tempted to just label your post as clueless and move on. Microsoft has given up a number of rights by using anti-competitive behavior in markets where they hold a monopoly position.
You should really learn about the definition of a monopoly and how a monopoly can impact the market. We would be light years ahead in innovation if Microsoft (or some other abusive monopolist) wasn't present to stifle innovation. For example, I saw a recent quote from Bill Gates stating that speech interfaces were the future of computing. OS/2 Warp 4 had that included in it's release in 1996. It wasn't great, but consider where speech would be now if OS/2 had enough of a market share to drive active, high-visibility development.
If you believe that OS/2 failed to gain market share based on it's own merits or IBM's handling, then you need to read the findings of law from the US DOJ vs. Microsoft antitrust trial.
Microsoft having an abusive monopoly is unfair. There's nothing wrong with shipping useful functionality with your OS as long as it isn't leveraged to stifle competition. Microsoft has been judged to not be a fair player in the market.
There's more than Linux out there to put on desktops. eComStation, Mac OSX, Solaris, etc.
Games and greeting card software are the only place users would be hurting for support, and those are probably represented OK on the Mac.
The conclusions of law in the Microsoft antitrust trial laid out very clearly why the OS market won't change until some remedy is introduced to break Microsoft's monopoly. Unfortunately the remedy was hijacked by a change in administration.